This version is taken from arch/arm/lib/memmove.S in the Linux kernel.
BUG=None
TEST=Built and booted on Snow with memmove used for CBFS loading.
BRANCH=None
Change-Id: If2631172eef7517e669affba066a65ce4ca16151
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61075
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This is from memcpy_32.c in the Linux kernel. There was no copyright header
in the original file either.
BUG=None
TEST=Built and booted on Link using memmove for CBFS load. Checked that
firmware boot time was at least as good.
BRANCH=None
Change-Id: Id1d026e191bad5f021fb3499a9f4ae1f71f89747
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61074
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The options that keep track of whether there are arch versions of the standard
string functions shouldn't be in the arch/x86 directory since they apply to
all architectures. Move them into the higher level, shared Kconfig defaulting
to off. Then, in each applicable arch (currently all of them) they can be
selected to on.
BUG=None
TEST=Built and booted on Link and Snow.
BRANCH=None
Change-Id: I1711efa699ddf31d29ebc672bd3728b472c26bb7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61072
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Some kernel assembly code uses a W macro to optionally add a .w to
instructions that need to be 32 bit thumb. The gnu assembler doesn't seem to
need the .w and won't assemble if it's provided.
BUG=None
TEST=Built for snow with the kernel's implementation of memmove (which uses
W()), and used memmove successfully when loading from CBFS.
BRANCH=None
Change-Id: I3871217b1fcbc81de159c18eb718867b17dea6cb
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61071
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer
since it was defined in sandybridge. It is really
more of an x86 thing however.
I considered making this more general, since it technically
can apply to PTE-based systems like ARM, and maybe we should.
BUG=None
TEST=abuild
BRANCH=None
Change-Id: I93d2daa2eff06ddd8cd7cd2e9d5beb8208115506
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57219
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=none
BRANCH=none
Change-Id: I3979be4b1d67de27275bc7ba4f45131b09a276f0
Reviewed-on: https://gerrit.chromium.org/gerrit/59323
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
This is already called in ARMv7 bootblock_simple.c so we don't
want to do it twice
BUG=none
TEST=boot on Snow
BRANCH=none
Change-Id: I4e9e7c3a0a5e6c9a78cb71dc55c1b48ed8764867
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58472
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Currently, the exception handling code on ARM turns on alignment checks as an
easy way to generate an exception for testing purposes. It was leaving it on
which disabled unaligned accesses for other, unlreated code running later.
This change adjusts the code so the original value of the alignment bit is
restored after the test exception.
BUG=chrome-os-partner:18635
TEST=Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the RAM stage. Before this change, the
access caused an exception. After this change, the access completed
successfully.
BRANCH=None
Change-Id: Ic2584650bb8e01dfe2285af6e2896e8c87477f50
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59371
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The dmb should be executed before reading operations, and before/after writing
operations.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow; booted Snow.
BRANCH=none
Change-Id: I3405cd8bef35b5454c423790d1886c87509c0f28
Reviewed-on: https://gerrit.chromium.org/gerrit/58441
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
The code has been there for quite a while but was never enabled.
BUG=none
TEST=none
BRANCH=none
Change-Id: Ifc30e735e78f88ab2c84e374e2aa245b370c4e03
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57018
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
BUG=None
TEST=Built with the assembly versions of memcpy and memset turned on and saw
that we could boot after this change where we couldn't before. Disassembled a
function which calls memset and saw that it was using the blx instruction
which can change mode instead of the bl instruction which can't.
BRANCH=None
Change-Id: Ic3ef4faf17d3467b5042c944106b8743d517cce3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58728
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
It might be that you want an early console in romstage before RAM is up, but
you can't or don't want to support the console all the way back in the
bootblock. By making the console in those two different environments
configurable seperately that becomes possible.
On the 5250 console output as early as the bootblock works, but on the 5420 it
only starts working in the ROM stage after clocks have been initialized.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit with another change and an external tool, and was
able to get serial output. Built for snow.
BRANCH=None
Change-Id: Ie27ae7a7b22f336d23893618969efde4145fefd7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/57725
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
remove some unused code
BRANCH=none
TEST=none
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I048f111b4f4c7a6c987cc7404bd073848619e908
Reviewed-on: https://gerrit.chromium.org/gerrit/57017
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be
different (ex, Exynos 5250 may use a new BL1 with variable length checksum
header).
To support that better, define the real base address (and ROM offset) of boot
block, and then we can post-processing ROM image file by filling data / checksum
and any other information.
BUG=none
TEST=manual: emerge-daisy chromeos-coreboot-snow;
emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: I9b3ee083c2edac64a653d5d7dffc123d252878d7
Reviewed-on: https://gerrit.chromium.org/gerrit/58342
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
On x86 there is a 16-byte alignment requirement for the
addresses containing the CPU microcode. The cbfs files
containing the microcode are used in memory-mapped fashion
when loading new mircocode. Therefore, the data payload's
address/offset of a cbfs file in flash dictates the resulting
alignment. Fix this by processing the CPU microcode cbfs
file separately as it uses $(CBFSTOOL) to find the proper
location within the provided rom image.
BUG=chrome-os-partner:20100
BRANCH=None
TEST=Manually inspected cbfs layout:
CBFS @ Offset 0x00700000 into 0x00800000 ROM size
[0xfff00000] cmos_layout.bin type cmos layout (0x1aa) @ 0xfff00028,
0x48c (1164) bytes
[0xfff004c0] pci8086,0406.rom type optionrom (0x30) @ 0xfff004f8,
0x10000 (65536) bytes
[0xfff10500] cpu_microcode_blob.bin type microcode (0x53) @ 0xfff10560,
0x9c40 (40000) bytes
[0xfff1a1c0] config type raw (0x50) @ 0xfff1a1e8, 0x157f (5503) bytes
[0xfff1b780] fallback/vboot type stage (0x10) @ 0xfff1b7a8, 0x3ad3
(15059) bytes
[0xfff1f280] (empty) type null (0xffffffff) @ 0xfff1f2a8, 0xcd8 (3288)
bytes
[0xfff1ff80] fallback/romstage type stage (0x10) @ 0xfff1ffe4, 0xa001
(40961) bytes
[0xfff2a000] fallback/coreboot_ram type stage (0x10) @ 0xfff2a038,
0x15373 (86899) bytes
[0xfff3f3c0] fallback/payload type payload (0x20) @ 0xfff3f3f8, 0xd00e
(53262) bytes
[0xfff4c440] u-boot.dtb type unknown (0xac) @ 0xfff4c468, 0x1e4b (7755)
bytes
[0xfff4e2c0] (empty) type null (0xffffffff) @ 0xfff4e2e8, 0x51cd8
(335064) bytes
[0xfff9ffc0] mrc.bin type mrc (0xab) @ 0xfffa0000, 0x2d8b8 (186552)
bytes
[0xfffcd8c0] (empty) type null (0xffffffff) @ 0xfffcd8e8, 0x1e6d8
(124632) bytes
[0xfffebfc0] spd.bin type mrc (0xab) @ 0xfffec000, 0x200 (512) bytes
[0xfffec200] (empty) type null (0xffffffff) @ 0xfffec228, 0x13418
(78872) bytes
Change-Id: Icc676a1c76c368d77e48cf573c6f846301da42a2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58238
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
One of the most common hangs during coreboot execution
is during ramstage device init steps. Currently there
are a set of (somewhat misleading) post codes during this
phase which give some indication as to where execution
stopped, but it provides no information on what device
was actually being initialized at that point.
This uses the new CMOS "extra" log banks to store the
encoded device path of the device that is about to be
touched by coreboot. This way if the system hangs when
talking to the device there will be some indication where
to investigate next.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: interrupted boot with reset button and
gathered the eventlog after several test runs:
26 | 2013-06-10 10:32:48 | System boot | 120
27 | 2013-06-10 10:32:48 | Last post code in previous boot | 0x75 | Device Initialize
28 | 2013-06-10 10:32:48 | Extra info from previous boot | PCI | 00:16.0
29 | 2013-06-10 10:32:48 | Reset Button
30 | 2013-06-10 10:32:48 | System Reset
Change-Id: I6045bd4c384358b8a4e464eb03ccad639283939c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58105
This can be used to indicate sub-state within a POST
code range which can assist in debugging BIOS hangs.
For example this can be used to indicate which device
is about to be initialized so if the system hangs
while talking to that device it can be identified.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: emerge-slippy chromeos-coreboot-slippy
This adds new infrastructure that is not used yet.
Change-Id: I2f8155155f09fe9e242ebb7204f0b5cba3a1fa1e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58104
The CMOS post code storage mechanism does back-to-back
CMOS reads and writes that may be interleaved during
CPU bringup, leading to corruption of the log or of other
parts of CMOS.
BUG=chrome-os-partner:19980
BRANCH=none
TEST=manual: verify post codes in CMOS during suspend/resume test
Change-Id: I704813cc917a659fe034b71c2ff9eb9b80f7c949
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58102
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some code was previously removed regarding elf notes. However,
that code left a dangling comma under !CONFIG_MULTIBOOT
configs for inline assembly constraints. Instead, place the comma
within the #ifdef stanza.
BUG=None
BRANCH=None
TEST=Successfully built wtm2.
Change-Id: I805453ef57d34fbfb904b4d145d8874921d8d660
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56844
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
This stuff is not used, so let's drop it.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=boot tested on Link and Snow
Change-Id: Ib3f3eab653f87a75e9e1e6a0bcdd72a605f77e6c
Reviewed-on: https://gerrit.chromium.org/gerrit/56652
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
With only 19 source files it doesn't make a whole lot of sense to
create sub directories in arch/armv7, especially since the files
were distributed somewhat randomly.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow builds.
BRANCH=none
Change-Id: I0c3dafb5deb7d70955a8b08be062b3c9824525ff
Reviewed-on: https://gerrit.chromium.org/gerrit/56651
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Mainboards were defining their own SMBIOS type41
write function. Instead pull this into the generic
SMBIOS code and change the existing mainboards to
make use of it.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: emerge-{link,parrot,butterfly}
chromeos-coreboot-{link,parrot,butterfly}
Change-Id: I3c8a95ca51fe2a3118dc8d1154011ccfed5fbcbc
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56619
Reviewed-by: Stefan Reinauer <reinauer@google.com>
When modifying the page tables, use writel to ensure the writes happen, flush
the page tables themselves to ensure they're visible to the MMU if it doesn't
look at the caches, and invalidate the right TLB entries.
The first two changes are probably safer but may not be strictly necessary.
The third change is necessary because we were invalidating the TLB using i
which was in megabytes but using an instruction that expects an address in
bytes.
One symptom of this problem was that the framebuffer, which was supposed to be
marked uncacheable, was only being partially updated since some of the updates
were still in the cache. With this change the graphics show up correctly.
BUG=None
TEST=Built and booted on Snow. Verified that vboot screens were displayed
completely.
BRANCH=None
Change-Id: I9f3c3d3d1547b85d5b2d7035050a5107ead1f236
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55638
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
The page tables need to be aligned to a 16KB boundary and are 16KB in size.
The CBMEM allocator only guarantees 512 byte alignment, so to make sure
things are where they're supposed to be, the code was allocating extra space
and then adjusting the pointer upwards. Unfortunately, it was adding the size
of the table to the pointer first, then aligning it. Since it allocated twice
the space of the table, this had the effect of moving past the first table
size region of bytes, and then aligning upwards, pushing the end of the table
out of the space allocated for it.
You can get away with this if you push things you don't care about off the
end, and it happened to be the case that we were allocating a color map we
weren't using at the start of the next part of cbmem.
BUG=None
TEST=Built and booted on Snow
BRANCH=None
Change-Id: I13e28e015a3acf0dbb627aa5eff5f99bf4211ce6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55636
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock
- Don't initialize console twice in the bootblock
- remove printk in memory init that would mess up the UART
- unconditionally run console_init() in romstage, as it is
also unconditionally run in the bootblock.
BUG=none
TEST=boot tested on Snow, no serial garbage and no multiple UART
init in bootblock.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I3c203fa541ea5fffa2ae38943278d6358db45379
Reviewed-on: https://gerrit.chromium.org/gerrit/51497
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
There are some boards that do a significant amount of
work after cache-as-ram is torn down but before ramstage
is loaded. For example, using vboot to verify the ramstage
is one such operation. However, there are pieces of code
that are executed that reference global variables that
are linked in the cache-as-ram region. If those variables
are referenced after cache-as-ram is torn down then the
values observed will most likely be incorrect.
Therefore provide a Kconfig option to select cache-as-ram
migration to memory using cbmem. This option is named
CAR_MIGRATION. When enabled, the address of cache-as-ram
variables may be obtained dynamically. Additionally,
when cache-as-ram migration occurs the cache-as-ram
data region for global variables is copied into cbmem.
There are also automatic callbacks for other modules
to perform their own migration, if necessary.
BUG=chrome-os-partner:19342
BRANCH=none
TEST=Built and booted. Noted that CAR values are not read incorrectly.
Change-Id: Ie0104a6e24cc6430a575ee3691671900c36db0d9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51386
Reviewed-by: Stefan Reinauer <reinauer@google.com>
When starting the Exynos5250 port, a lot of unneeded u-boot code
was imported. This is an attempt to get rid of a lot of unneeded
code before the port is used as a basis for further ARM ports.
There is a lot more that can be done, including cleaning up the
5250's Kconfig file.
BUG=none
TEST=booted on Snow
BRANCH=none
Change-Id: I7581e9005e09ad264f85d57b6771f40faa2e63af
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51216
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Thread support is added for the x86 architecture. Both
the local apic and the tsc udelay() functions have a
call to thread_yield_microseconds() so as to provide an
opportunity to run pending threads.
BUG=None
BRANCH=None
TEST=Built
Change-Id: I9d65a8e67ffdee5fd813f7554ecafbdf37b93af0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51163
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The cooperative multitasking support allows the boot state machine
to be ran cooperatively with other threads of work. The main thread
still continues to run the boot state machine
(src/lib/hardwaremain.c). All callbacks from the state machine are
still ran synchronously from within the main thread's context.
Without any other code added the only change to the boot sequence
when cooperative multitasking is enabled is the queueing of an idlle
thread. The idle thread is responsible for ensuring progress is made
by calling timer callbacks.
The main thread can yield to any other threads in the system. That
means that anyone that spins up a thread must ensure no shared
resources are used from 2 or more execution contexts. The support
is originally intentioned to allow for long work itesm with busy
loops to occur in parallel during a boot.
Note that the intention on when to yield a thread will be on
calls to udelay().
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I980a6daf8ea3f0475124329253ace2695fc39aa7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51162
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This patch unfortunately incorporates a number of changes,
all of which are making future ARM ports easier.
- drop cruft that came in with u-boot
- move serial console from mainboard Kconfig to Exynos Kconfig
- factor out non-board specific wakeup code
- move generic bootblock code from mainboard to Exynos
- actually call arch_cpu_init()
- remove dead code
- fix up copyright messages
- remove snow_ prefix from a lot of code to reduce the noise
when creating a new mainboard based on that code.
BUG=none
BRANCH=none
TEST=boot tested on snow
Change-Id: Ibc56b5bf7ec60ee730b32180ad9ef415438fffaf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50911
Reviewed-by: David Hendricks <dhendrix@chromium.org>
... and drop the wrapper on ARMv7
BUG=none
TEST=boot tested on snow
BRANCH=none
Change-Id: Ib2b4315b664292653f8cb898fc5633fce421deca
Reviewed-on: https://gerrit.chromium.org/gerrit/50728
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1]
made romcc not choke on function prototypes anymore. This
allows us to get rid of a lot of ifdefs guarding __ROMCC__ .
[1] http://review.coreboot.org/2424
BUG=none
TEST=boot tested on Link
BRANCH=none
Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3216
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50723
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This option has not been enabled on any board and was considered
obsolete last time it was touched. If we need the functionality,
let's fix this in a generic way instead of a K8 specific way.
This was mostly a speedup hack back in the day.
BUG=none
TEST=not needed (inactive option dropped)
BRANCH=none
Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3211
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50722
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Since this parameter is not used anymore, drop it from
all calls to copy_and_run()
BUG=none
TEST=boot tested on snow+link
BRANCH=none
Change-Id: Ifba25aff4b448c1511e26313fe35007335aa7f7a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3213
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50721
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
it has been unused since 9 years or so, hence drop it.
BRANCH=none
BUG=none
TEST=boot tested on snow
Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3212
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50720
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
In order for the FIT entries to be populated in the table the
update-fit command needs to be done on the coreboot image. That
way the microcode entries are added to the table properly.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: I44595aee1ca710f4f04d482d8900cf95fbc1797f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50317
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The old approach was to invalidate the entire TLB every time we set up
a table entry. This worked because we didn't turn the MMU on until
after we had set everything up. This patch uses the TLBIMVAA wrapper
to invalidate each entry as it's added/modified.
Change-Id: I27654a543a2015574d910e15d48b3d3845fdb6d1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3166
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It is useful to be able to lock out certain address ranges,
NULL being the most important example.
void mmu_disable_range(unsigned long start_mb, unsigned long size_mb)
will allow us to lock out selected virtual addresses on MiB boundaries.
As in other ARM mmu functions, the addresses and quantities are in units
of MiB.
Change-Id: If516ce955ee2d12c5a409f25acbb5a4b424f699b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This adds an inline wrapper for the TLBIMVAA instruction (invalidate
unified TLB by MVA, all address space identifiers).
Change-Id: Ibcd289ecedaba8586ade26e36c177ff1fcaf91d3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3161
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.
Change-Id: If67b9b50081d21d505685a96d201c242e71b64f7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49746
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Utilize the static boot state callback scheduling to initialize
and tear down the coverage infrastructure at the appropriate points.
The coverage initialization is performed at BS_PRE_DEVICE which is the
earliest point a callback can be called. The tear down occurs at the
2 exit points of ramstage: OS resume and payload boot.
Change-Id: I623e55f19f9fb52492f288c620cc966cafd0ab71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49743
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It's helpful to provide a distinct state that affirmatively
describes that OS resume will occur. The previous code included
the check and the actual resuming in one function. Because of this
grouping one had to annotate the innards of the ACPI resume
path to perform specific actions before OS resume. By providing
a distinct state in the boot state machine the necessary actions
can be scheduled accordingly without modifying the ACPI code.
Change-Id: I298f0f1c1aa6ee62fee0067a53dc021fe07044dc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49742
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Many of the boot state callbacks can be scheduled at compile time.
Therefore, provide a way for a compilation unit to inform the
boot state machine when its callbacks should be called. Each C
module can export the callbacks and their scheduling requirements
without changing the shared boot flow code.
Change-Id: I6a4102cb9fac3f7980c28169430251651fddeb30
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49741
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).
Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
= udelay((N * 2) / (1.7 * 10^3))
The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))
There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.
Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add a microsecond timer, its declaration, the function to start it,
and its usage. To start it, one calls timer_start(). From that point
on, one can call timer_us() to find microseconds since the timer was
started.
We show its use in the bootblock. You want it started very early.
Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.
We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.
Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
It's better to recognize aborts when they occur than to mask them to
discover them later without knowing where they actually came from.
Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3065
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.
This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.
Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(®s->ch_cfg, SPI_CH_RST);
clrbits_le32(®s->ch_cfg, SPI_CH_RST);
In such cases the safe versions of readl() and writel() should be
used anyway.
Note: This also fixes two dubious casts as to avoid breaking
compilation.
Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The mainboard_interrupt_handlers() argument for the function
pointer was using void * as the type. This does not allow the compiler
to catch type differences for the arguments. Thus, some code has been
committed which violates the new interrupt callbacks not taking any
arguments. Make sure the compiler provides a type checking benefit.
Change-Id: I268ec8e16929080955751ef518d65b91895e4308
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48970
This adds $$(INTERMEDIATE) as a pre-requisite for coreboot.rom on
armv7. It is modeled after the $(obj)/coreboot.rom rule for x86.
BRANCH=none
BUG=chrome-os-partner:18734
TEST=Built and booted on Snow
Change-Id: I483a88035fa2288829b6e042e51ef932c8c4f23c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2095
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49280
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This adds condition codes when using the msr instruction. Although
described as "optional" in the Cortex-A series programmer's guide,
our experience with using the msr instruction in the payload suggests
that the condition code is not optional and that this only worked
in coreboot (and u-boot) because the processor comes up in SVC32 mode.
(credit to Gabe Black for finding this, I'm only uploading the patch)
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0aa4715ae415e1ccc5719b7b55adcd527cc1597b
Reviewed-on: http://review.coreboot.org/3037
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
