Some platforms may pass as a parameter the maskrom or vendor startup
code information when calling the bootblock.
Make sure the bootblock startup code saves this parameter for use by
coreboot. As we don't want to touch memory before caches are
initialized, save the passed in parameter in r10 for the duration of
cache initialization.
Added warning comments to help enforcing that cache initialization
code does not touch r10.
BRANCH=storm
BUG=chrome-os-partner:30623
TEST=with the rest of the patches applied see the QCA uber-sbl report
in the coreboot console output.
Change-Id: Ic6a09e8c3cf13ac4f2d12ee91c7ab41bc9aa95da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e41584f769eb042604883275b0d0bdfbf5b0d358
Original-Change-Id: I517a79dc95040326f46f0b80ee4e74bdddde8bf4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255144
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@gmail.com>
Reviewed-on: http://review.coreboot.org/9842
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch changes the argument order for the (now temporarily unused)
write32() accessor macro (and equivalents for other lengths) from
(value, address) to (address, value) in order to conform with the
equivalent on x86. Also removes one remaining use of write32() on ARM
that slipped through since coccinelle doesn't inspect header files.
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: Id5739b144f6a5cfd40958ea68510dcf0b89fbfa9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f02cae8b04f2042530bafc91346d11bb666aa42d
Original-Change-Id: Ia91c2c19d8444e853a2fc12590a52c2b6447a1b9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to the
directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>,
src/soc/<arm(64)-soc> and src/drivers/gic:
@@
expression A, V;
@@
- write32(V, A)
+ writel(V, A)
@@
expression A, V;
@@
- write16(V, A)
+ writew(V, A)
@@
expression A, V;
@@
- write8(V, A)
+ writeb(V, A)
This replaces all uses of write{32,16,8}() with write{l,w,b}()
which is currently equivalent and much more common. This is a
preparatory step that will allow us to easier flip them all at once to
the new write32(a,v) model.
BRANCH=none
BUG=chromium:451388
TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky.
Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24
Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254862
Reviewed-on: http://review.coreboot.org/9834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix build bug that is referencing vboot_data from
vendorcode/google/chromeos/gnvs.c when CONFIG_HAVE_ACPI_TABLES is not
set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
1. Checkout updated patches for config, skylake and glados through
FspNotify1
2. Verify that mainboard/intel/glados/Kconfig does not select
HAVE_ACPI_TABLES
3. emerge-glados coreboot
4. Test passes if build completes successfully
Change-Id: Ida5ab8b8dafe30b11dc80dab935e3223d4c760d3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1908079360aa065a36956d487eb93142e9c012a1
Original-Change-Id: Icac3845f7e2d1ddffa5f787a640033fba286c13e
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/254360
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9825
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Cache operations are simplified by removing assembly
implementation and replacing it with simpler C code.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; caches are properly
invalidated;
BRANCH=none
Change-Id: I0f092660549c368e98c208ae0c991fe6f5a428d7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf99849e75813cba865b15af9e110687816e61e4
Original-Change-Id: I965e7929718424f92f3556369d36a18ef67aa0d0
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/250792
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9820
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Using identity_map(), map the DRAM/SRAM regions to themselves (which
happens to be using KUSEG on urara).
The bootblock (which still runs in KSEG0) sets up the identity mapping
in bootblock_mmu_init() so that ROM/RAM stages can be loaded into the
KUSEG address range.
The stack and pre-RAM CBMEM console also remain in KSEG0 since we
don't really care about their physical addresses.
Also splitting CBFS cache to pre and post RAM, to allow for larger
rambase images.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=With the rest of coreboot and depthcharge patches applied:
- booted urara into the kernel login prompt
- from depthcharge CLI tried accessing memory below 0x100000 -
observed the exception.
Change-Id: If78f1c5c54d3587fe83e25c79698b2e9e41d3309
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9668b440b35805e8ce442be62f67053cedcb205e
Original-Change-Id: I187d02fa2ace08b9fb7a333c928e92c54465abc2
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246694
Reviewed-on: http://review.coreboot.org/9816
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Introduce identity_map() function. It takes a memory range and
identity maps it entirely in the TLB table, if possible. As a result
the virtual and physical address ranges are the same.
The function attempts to use as large of a page size as possible for
each region in order to conserve TLB entries.
BUG=chrome-os-partner:36258
BRANCH=none
TEST=Build and boot on Pistachio with the rest of the patches applied.
Change-Id: I4d781b04699e069a71c49a0c6ca15c7a6b42a468
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 234d32edfd201019b7a723316a79c932c62ce87e
Original-Change-Id: If3e2392b19555cb6dbae8b5559c1b1e53a313637
Original-Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246693
Reviewed-on: http://review.coreboot.org/9815
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We recently restructured where the CBFS header is stored
and how it is looked up, with less magic. The RISC-V port
didn't get the memo, so have it follow the pack now.
Change-Id: Ic27e3e7f9acd55027e357f2c4beddf960ea02c4d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9795
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This is necessary to make sure that bootblock uses the default CBFS
header (as it ought to) when multiple CBFS images support is enabled.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest of the patches applied storm boots all the way inot
the Linux prompt
Change-Id: I5e029d95c5cb085794c7bf5f44513b2144661e38
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75b2c2ef6c8287db7c3e5879cacfd5dcba4391ac
Original-Change-Id: I5c352921b4c9b6a3294f4658d174e0842d2ee365
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237661
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9770
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
broadcom cygnus hangs if we clean caches by dcache_clean_invalidate_all
at bootblock entry point. this change makes startup code call
dcache_invalidate_all instead.
other boards theoretically should not be affected as long as maskrom
does not hand off execution to bootblock with dirty cache.
BUG=chrome-os-partner:36648,chrome-os-partner:36691
BRANCH=broadcom-firmware
TEST=boot cygnus b0 board, messages were printed on console:
coreboot-688aae9-dirty bootblock Mon Feb 9 13:21:02 PST 2015
starting...
Exception handlers installed.
Change-Id: I05777ca525c97bb3d7cbb5ea7e872a602dcd5a19
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 59de5328df9d0502a3b3f7c624d3e86e038de50e
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I9b8850846b941e7e62712e90cc28ad14a68da393
Original-Reviewed-on: https://chromium-review.googlesource.com/251304
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9762
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:239470
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2
Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240819
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Each type of cache might have different cache line size.
Call the proper get_<*>cache_line function for each cache
type.
Fixes problem with get_L2cache_line which previously
targeted L3 cache line in the config register, instead of
L2 cache.
TODO: add support for tertiary caches and have cache
operations be called per CPU, not per architecture.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; worked as expected;
BRANCH=none
Change-Id: I7de946cbd6bac716e99fe07cb0deb5aa76c84171
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 62e2803c6f2a3ad02dc88f50a4ae2ea00487e3f4
Original-Change-Id: I03071f24aacac1805cfd89e4f44b14ed1c1e984e
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241853
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change defines stage_entry as a weak symbol so that a board
can implement custom stage entry code.
BUG=none
BRANCH=tot
TEST=built all current boards. booted cosmos p1.
Change-Id: If8f6945ecdc5047558bb6359aa997867e36f33b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86d5008981d0b01652907baab47a476d784a2ceb
Original-Change-Id: Ib43158c4013e6393d86a9aef37cf444a48b9fc79
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238021
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9721
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Commit 54229a7 (arm: Fix checkstack() to use correct stack size) didn't
quite hit the mark. Due to the crazy way our Kconfig includes work, It
accidentally set CONFIG_STACK_SIZE to 0 even on architectures that need
it.
This patch fixes the issue by moving everything back to a single entry
in src/Kconfig, making sure we end up with the intended numbers on all
architectures.
BRANCH=None
BUG=chrome-os-partner:34750
TEST=Built for Pinky, Urara, Falco and Ryu. Confirmed that the generated
.config contained CONFIG_STACK_SIZE=0x0 for the former two, and
CONFIG_STACK_SIZE=0x1000 for the latter.
Original-Change-Id: Ib18561925aafe7c74e6c4f0b10b55000a785e144
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236753
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c64b127e163f98162f3f7195b6ed09bd5a4b77c4)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I2c747b04760bc97f43523596640bfb15317e5730
Reviewed-on: http://review.coreboot.org/9696
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
checkstack() runs at the end of ramstage to warn about stack overflows,
and it assumes that CONFIG_STACK_SIZE is always the size of the stack to
check. This is only true for systems that bring up multiprocessing in
ramstage and assign a separate stack for each core, like x86 and ARM64.
Other architectures like ARM and MIPS (for now) don't touch secondary
CPUs at all and currently don't look like they'll ever need to, so they
generally stay on the same (SRAM-based) stack they have been on since
their bootblock.
This patch tries to model that difference by making these architectures
explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to
assume the whole (_estack - _stack) area in checkstack() instead. Also
adds a BUG() to the stack overflow check, since that is currently just
as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM
HALTED" output) but a little more easy to spot. Such a serious failure
should not drown out in all the normal random pieces of lower case boot
spam (also, I was intending to eventually have a look at assert() and
BUG() to hopefully make them a little more useful/noticeable if I ever
find the time for it).
BRANCH=None
BUG=None
TEST=Booted Pinky, noticed it no longer complains about stack overflows.
Built Falco, Ryu and Urara.
Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4
Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235894
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9610
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This provides the opportunity to remove the kludge of disabling caches
altogether in the bootblock.
[pg: originally, this commit also provided automatic cache management
after loading stages, ie. flush dcache, so code ends up in icache. This
is done differently in upstream, so it's left out here]
BUG=chrome-os-partner:34127, chrome-os-partner:31438
TEST=with this fix romstage, ramstage and payload are executed properly
BRANCH=none
Change-Id: I568c68d02b2cd9c1c2c9c1495ba3343c82509ccc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 95ab0f159cabf21fc100f371d451211e7d113761
Original-Change-Id: Iaf90b052073dd355ab9114e8dba9f5ef76188c94
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232410
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9618
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Until proper MIPS cache management is available it is necessary to
disable data and instruction caches, otherwise code placed in memory
stays in data cache and is not available for instruction fetched.
BRANCH=none
BUG=chrome-os-partner:31438,chrome-os-partner:34127
TEST=coreboot loading rombase and rambase now succeeds.
Change-Id: I4147e1325edc0b9bb951cd7ce18d5f104f3eaec0
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 93d5bfa1d01fbbabbabef33a22287ceeea28b15b
Original-Change-Id: Ib195ed6e5f08ccaa6bbe3325c2199171bfb63b88
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232191
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9569
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597
Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231941
Reviewed-on: http://review.coreboot.org/9603
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The information about the DMA memory area is further passed
through the coreboot table to the payload.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA; DMA memory area was used to test the
functionality of the DWC2 USB controller driver; behavior was
as expected.
BRANCH=none
Change-Id: I658e32352bd5fab493ffe15ad9340e19d02fd133
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 0debc105b072a37e2a8ae4098a9634d841191d0a
Original-Change-Id: Icf69835dc6a385a59d30092be4ac69bc80245336
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/235910
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9593
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When the i-cache is on and the d-cache is off, the L1 i-cache is still
fetching information through L2 cache.
Since L2 cache is never invalidated, it has stale information.
BRANCH=storm
BUG=none
TEST=Resolves the invalidate data fetch from i-cache while jumping from
bootblock to romstage.
Change-Id: Ibaca1219be2e40ce5bbbd1c124863d0ea71d0466
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a13e20f9b242d8193dcb314a2bdc708c6bdfea51
Original-Change-Id: I252682d372bd505f525f075461b327e4bcf70a1a
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236422
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9587
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With support for initializing registers based on values saved by primary CPU, we
no longer need to invalidate secondary CPU stack cache lines. Before jumping to
C environment, we enable caching and update the required registers.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu.
Change-Id: Ifee36302b5de25b909b4570a30ada8ecd742ab82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0a0403d06b89dae30b7520747501b0521d16a6db
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I738250f948e912725264cba3e389602af7510e3e
Original-Reviewed-on: https://chromium-review.googlesource.com/231563
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9541
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Change-Id: Ia4ca0e7d35c0738dbbaa926cce4268143c6f9de3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f5e78469313ddd144ad7cf5abc3e07cb712183a
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Original-Reviewed-on: https://chromium-review.googlesource.com/231561
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some registers are available only at EL3. Add conditional read/write functions
that perform operations only if currently we are in EL3.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: Ic95838d10e18f58867b6b77aee937bdacae50597
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 62a0e324a00248dba92cb3e2ac2f4072d0e4e2a7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: Ia170d94adb9ecc141ff86e4a3041ddbf9045bc89
Original-Reviewed-on: https://chromium-review.googlesource.com/231549
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9538
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I96312e62a67f482f4233c524ea4e22cbbb60941a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ae71f87143f899383d8311a4ef908908116340d7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Original-Reviewed-on: https://chromium-review.googlesource.com/231548
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9537
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
psci_soc_init() was added to allow SoC PSCI initialization.
However, actually calling said function was omitted accidentally.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and noted correct on entry point was used.
Change-Id: I84a397e2dabf149fe8f252ef69d0a7362fa1f194
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a0e6ad41f049bbab483423231db59390894e9b2
Original-Change-Id: I1a4e25fde64ecdc98fa9231f7d9cafc21119630d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231935
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Secondary CPUs were intermittently not coming online as expected.
Upon investigation it was found that a cache line needed to be
invalidated that corresponded to the top of the stack for the
failing CPU.
Currently the secondary CPUs come online with caching disabled.
However, the code paths are using C and thus the stack it is assigned.
The MMU is enabled in C after it's pushed its return path onto the
stack that went directly to ram. When the cache line corresponding
to its stack is valid in the cache it will hit once the MMU is enabled.
That hit will have invalid data w.r.t. the return addresses pushed
directly into ram.
This is not the best solution as the only way to guarantee we don't
hit such a situation is to tightly manage resource usage up until
the point of MMU enablement. That can be done in a followup patch.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=On ryu where secondary CPUs weren't coming online consistently,
they now come up.
Change-Id: I03237656da180d1f74df3a8e00029ba8d778bca8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06ab6afc996cf92c45d4cd6850e31167c2946a95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: I32de749ea48c19e23442e6dc5678c5369ac3b2b6
Original-Reviewed-on: https://chromium-review.googlesource.com/231219
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9527
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial MP code assumed all CPUs would come online. That's not
very defensive, and it is a bad assumption. Provide a timeout
mechanism for bring CPUs online.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Multiple times with CPUs working and not working. Boot to kernel.
Change-Id: Ib0aef31f5c732816d65c2e4b3c6a89e159974fdc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9cf5bc2844c8f4ad987cfcb69ef33c73551f0083
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: Ifb3b72e3f122b79e9def554c037c9b3d6049a151
Original-Reviewed-on: https://chromium-review.googlesource.com/231070
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9526
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Expand the boot block include file to allow for a file containing reset
routines to be added. Prevent breaking existing platforms by using a
Kconfig value to specify the path to this file, and have the code
include this file only if the Kconfig value is set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
Change-Id: I604f701057d7018f2ed9c3ba49a643c4bca13f00
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c109481d9503916e19ed300c1a3f085e0d2b5c51
Original-Change-Id: I3214399f8156b5ea2ef709ce77e3915cea1523a3
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/248300
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
SeaBIOS doesn't like CC and LD to contain arguments, so split
those out.
Change-Id: Id651719d529adfa8602a3e4f6685228330f36432
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9378
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
Provide support for SoCs to participate in PSCI commands.
There are 2 steps to a command:
1. prepare() - look at request and adjust state accordingly
2. commit() - take action on the command
The prepare() function is called with psci locks held while
the commit() function is called with the locks dropped.
No SoC implements the appropriate logic yet.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Booted PSCI kernel -- no SMP because cmd_prepare()
knowingly fails. Spintable kernel still brings up both
CPUs.
Change-Id: I2ae4d1c3f3eac4d1060c1b41472909933815d078
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 698d38b53bbc2bc043548792cea7219542b5fe6b
Original-Change-Id: I0821dc2ee8dc6bd1e8bc1c10f8b98b10e24fc97e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226485
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Newly turned on CPUs need a place to go bring its EL3
state inline with expectations. Plumb this path in for
CPUs turning on as well as waking up from a power down
state. Some of the infrastructure declarations were
moved around for easier consumption in ramstage and
secmon. Lastly, a psci_soc_init() is added to
inform the SoC of the CPU's entry point as well do
any initialization.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted. On entry point not actually utilized.
Change-Id: I2af424c2906df159f78ed5e0a26a6bc0ba2ba24f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dbefec678a111e8b42acf2ae162c1ccdd7f9fd40
Original-Change-Id: I7b8c8c828ffb73752ca3ac1117cd895a5aa275d8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228296
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Instead of relying on CONFIG_MAX_CPUS to be the number of
CPUs running a platform pass the number of online cpus
from coreboot secmon. That allows for actually enabled
CPUs < CONFIG_MAX_CPUS.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted SMP kernel.
Change-Id: Iaf1591e77fcb5ccf5fe271b6c84ea8866e19c59d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3827af876c247fc42cd6be5dd67f8517457b36e7
Original-Change-Id: Ice10b8ab45bb1190a42678e67776846eec4eb79a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227529
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The struct cpu_action already tracks entry/arg pointers. Use that
instead of duplicating the same information.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted.
Change-Id: I70e1b471ca15eac2ea4e6ca3dab7d8dc2774a241
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cdddfd8d74d227cb5cbdf15b6871480839fa20d8
Original-Change-Id: I4070ef0df19bb1141a1a47c4570a894928d6a5a4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227549
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9396
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current implementation of secmon assumes just entry/arg
are passed to secmon for starting up a CPU. That's lacking
in flexibility. Therefore change secmon_params to contain
both the BSP and secondary CPUs' entry/arg information.
That way more information can be added to secmon_params when
needed.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted SMP kernel using PSCI and spin table.
Change-Id: I84c478ccefdfa4580fcc078a2491f49f86a9757a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c5fb5bd857a4318174f5b9b48e28406e60a466f8
Original-Change-Id: Iafb82d5cabc806b6625799a6b3dff8d77bdb27e9
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227548
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is state within the system that relies on having
all CPUs present in order to proceed with initialization.
The current expectation is that all CPUs are online and
entering the secure monitor. Therefore, wait until all
CONFIG_MAX_CPUs show up.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Can get all CPUs up in kernel using PSCI.
Change-Id: I741a09128e99e0cb0c9f4046b1c0d27582fda963
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 030535b7c9821b40bf4a51f88e289eab8af9aa13
Original-Change-Id: Ia0f744c93766efc694b522ab0af9aedf7329ac43
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227547
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change sets the stack pointer to the value specified in
memlayout.ld before jumping to the bootblock.
BUG=none
BRANCH=ToT
TEST=Built cosmos and all other current boards.
Change-Id: Ic1b790f27bce431124ba70cc2d3d3607c537564b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d50fd02db8bf10147fd808f3030e6297b9ca0aad
Original-Change-Id: I4bb8cea7435d2a0e2c1ced050c3366d2e636cb8a
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225420
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9384
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this adds an entry point jumping to main for the bootblock.
BUG=None
BRANCH=ToT
TEST=Built coreboot for cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1c9ea6ba63a1058e09613d969fe00308260037be
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 662d0083f25008b55b9bc5fbce9e30e6b80c2c65
Original-Change-Id: I74f2f5e3b3961ab54a7913e6b3a3ab0e6fd813a3
Original-Reviewed-on: https://chromium-review.googlesource.com/225205
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9382
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The arch_run_on_all_cpus[_async]() APIs can run the BSP before
the APs if the BSP's id is less than the APs' ids. Fix this by
ensuring we run the necessary callback on all but self.
BUG=chrome-os-partner:33532
BRANCH=None
TEST=Booted spin table kernel. All CPUs are up.
Change-Id: Ic9a466c3642595bad06cac83647de81873b8353e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 575437354cc20eeac8015a0f7b0c9999ecb0deee
Original-Change-Id: I87e944f870105dbde33b5460660c96c93c3cdf93
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227488
Original-Tested-by: David Riley <davidriley@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9392
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to properly support more arm64 SoCs PSCI needs
to handle the hierarchy of cpus/clusters within the SoC.
The nodes within PSCI are kept in a tree as well as
a depth-first ordered array of same tree. Additionally,
the PSCI states are now maintained in a hierachal manner.
OFF propogates up the tree as long as all siblings are
set to OFF. ON propogates up the tree until a node is
not already set to OFF.
The SoC provides the operations for determining how many
children are at a given affinity level. Lastly, the
secmon startup has been reworked in that all non-BSP CPUs
wait for instructions from the BSP.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Can still boot into kernel with SMP.
Change-Id: I036fabaf0f1cefa2841264c47e4092c75a2ff4dc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 721d408cd110e1b56d38789177b740aa0e54ca33
Original-Change-Id: I520a9726e283bee7edcb514cda28ec1eb31b5ea0
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226480
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The cpu_info struct can be easily obtained at runtime
based on smp_processor_id(). To allow easier mapping
between cpu_info and PSCI entities add the mpidr info
to the cpu_info struct.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted in SMP. Noted MPIDR messages for each cpu.
Change-Id: I390392a391d953a3b144b56b42e7b81f90d5fec1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d091706f64f1fc4b1b72b1825cab82a5d3cbf23e
Original-Change-Id: Ib10ee4413d467b22050edec5388c0cae57128911
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226481
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9388
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Vadim Bendebury