On x86, cpu_info lives at the top of stack. Make the arm do that as
well, as the threading model needs that and so will multicore support.
As part of this change, make the stack size a power of 2.
Also make it much smaller -- 2048 bytes is PLENTY for ram stage.
Note that the small stack size is counterintuitive for rom stage. How
can this work in rom stage, which needs a HUGE stack for lzma? The
main use of STACK_SIZE has always been in ram stage; since 2002 or so
it was to size per-core stacks (see, e.g.,
src/arch/x86/lib/c_start.S:.space CONFIG_MAX_CPUS*CONFIG_STACK_SIZE
and, more recently, thread stacks. So, we define the STACK_TOP for rom
and ram stage, but the STACK_SIZE has no real effect on the ROM stage
(no hardware red zones on the stack) and hence we're ok with actually
defining the "wrong" stack size. In fact, the coreboot_ram ldscript
for armv7 sizes the stack by subtracting CONFIG_STACK_BOTTOM from
CONFIG_STACK_TOP, so we replicate that arithmetic in bootblock.inc
Observed stack usage in ramstage:
BS: BS_PAYLOAD_LOAD times (us): entry 1 run 153887 exit 1
Jumping to boot code at 23104044
CPU0: stack: 02072800 - 02073000, lowest used address 020728d4, stack used: 1836 bytes
entry = 23104044
Which means we do need 2K, not 1K.
BUG=None
TEST=Build and boot and verify that cpu_info returns a correct value
BRANCH=None
Change-Id: I1a21db87081597efe463095bfd33c89eba1d569f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66135
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
There was no behavior defined for OP_DCCSW in dcache_op_set_way, so it
silently did nothing. Since we started using that to clean the cache between
stages and I have a change that enables caches earlier on, this was preventing
booting on pit.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit.
BRANCH=None
Change-Id: I3615b6569bf8de195d19d26b62f02932322b7601
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66234
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This merges the difference between the ARM version of cache.c and
cache.h for libpayload and coreboot.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=built and booted on pit
Change-Id: I246d2ec98385100304266f4bb15337a8fcf8df93
Reviewed-on: https://gerrit.chromium.org/gerrit/66120
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This cleans the caches without invalidating them between stages. The
dcache content should still be valid when the next stage begins, so
we should see a small performance gain.
(thanks to gabeblack for pointing this out)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=built and booted on pit
Change-Id: Ie18d163f3a78e2786e9fbc7479c8bd896b8ac3aa
Reviewed-on: https://gerrit.chromium.org/gerrit/66119
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This adds a wrapper for data cache clean (without invalidate)
by set/way.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=tested in follow-up patches
Change-Id: I09ee1563890350a6c1d04f1b96ac5d0c042e2af2
Reviewed-on: https://gerrit.chromium.org/gerrit/66118
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This patch implements the basic infrastructure required to use the USB
A-A firmware upload feature on Exynos5 processors with Coreboot. It will
require a corresponding host-side script that activates the feature and
uploads the correct image parts in the correct order to harcoded target
addresses, as described in the comments of alternate_cbfs.c.
Also fixes a bug in the Google Snow mainboard where it would not
correctly initialize the pinmux configuration for the SPI flash bus.
During a normal SPI boot the IROM would already do that for you, but
when booting from USB you have to do it yourself.
BUG=None
TEST=Manual
Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64875
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The SMP on Exynos 5420 requires setting a special page and entry wrappers in
firmware side (SRAM) so kernel can start cores (and to switch clusters).
BUG=chrome-os-partner:19420
TEST=built on pit and see 8 CPUs started.
Change-Id: I77ca98bb6cff5b13e95dd29228e4536302f0aee9
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64770
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
The ACTLR provides implementation defined configuration and control options for
the processor.
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit # success.
BRANCH=none
Change-Id: I74df1ed7887eb3f16a1b8297db998ec2f8b18311
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65107
Commit-Queue: Gabe Black <gabeblack@chromium.org>
To configure multi-processors, we need the intrinsic functions to get core ID,
put core into idle state, and to wake up cores.
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit # success.
BRANCH=none
Change-Id: I87a62dab6efd6c8bb0c8e46373da7c7eb7b16b35
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65112
This adds inline wrappers to read the L2 cache auxiliary control
register (L2ACTLR).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=it builds (tested more thoroughly w/ follow-up patches)
Change-Id: Iec603d7c738426232f7ce3a4a474d01c85fa3f2f
Reviewed-on: https://gerrit.chromium.org/gerrit/64861
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=None
TEST=Built and booted on pit.
BRANCH=None
Change-Id: I128e3ecc3773fe7c28616e93ef60b48c5862f302
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64839
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
On ARM, if the .car section is marked as NOLOAD, there's nothing that sets it
to zero. Some code in the cbmem console depends on a global variable being
zero initially, and if that's not true bad things happen.
BUG=None
TEST=Built and booted on pit. After this fix, CBMEM being on doesn't cause pit
to hang during boot.
BRANCH=None
Change-Id: Ic72a9fb0ee0c5a608190be6f24d0d7de7c34fc1f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64769
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Abstract the use of rdtsc() and make the timestamps
uint64_t in the generic code.
The ARM implementation uses the monotonic timer.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
BUG=chrome-os-partner:18637
TEST=See cbmem print timestamps
Change-Id: Id377ba570094c44e6895ae75f8d6578c8865ea62
Reviewed-on: https://gerrit.chromium.org/gerrit/63793
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The CBMEM console pointer in romstage is actually a zero byte array.
This means CBMEM area has to live at the end of the allocations or
else CBMEM console will overwrite whatever comes after it.
BRANCH=none
BUG=chrome-os-partner:18637
TEST=cbmem -c prints console without nasty workaround
Change-Id: Icc59e982b724a2d396370c3a5abd8898e08baf26
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63997
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
This functions are by definition changing the data pointed to by their
arguments, so they shouldn't by const.
BUG=chrome-os-partner:19420
TEST=Built for snow.
BRANCH=None
Change-Id: Id29b3f76526aba463f8bb744f53101327f9c7bde
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63777
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
That symbol isn't used by anything and doesn't appear in other linker scripts.
BUG=chrome-os-partner:19420
TEST=Built for snow.
BRANCH=None
Change-Id: Iab54ecb3be2e262d7674ef8ee7ed13ea2e5b56f3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63776
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
... and move the Kconfig variable from cpu/x86/Kconfig to cpu/Kconfig
Despite calling romstage memory CAR in this case, the variables actually
do live in SRAM on the Exynos CPUs. However, in order to share as much
generic code as possible, we're using the same infrastructure here.
BRANCH=none
BUG=chrome-os-partner:18637
TEST=none
Change-Id: I85173c37099a25f3e55980e88120401826cdf29c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62188
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
... In order to do this, the graphics memory has to move into
the resource allocator and out of CBMEM.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
Change-Id: I7396da4a7068404b0d2e4d308becab4dd6ea59bb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59326
Reviewed-by: David Hendricks <dhendrix@chromium.org>
and add an ARMv7 version.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I13d9194235bf03e3cceb862c791572f89196b65b
Reviewed-on: https://gerrit.chromium.org/gerrit/59293
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
BUG=None
TEST=Built and booted on Snow.
BRANCH=None
Change-Id: I0f27bca119a248e22b06b7343ddc6a4cb85f68a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61532
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The OP assigned by dcache_clean_by_mva must be handled in dcache_op_mva.
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
BRANCH=none
Change-Id: Ia7631a08be6afacb13dfff406ac4db20efc98926
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61076
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
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>
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>
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>
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>
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>
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>
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)
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>
