Without this, building with COLLECT_TIMESTAMPS fails.
Fixes a mistake during upstreaming in commit 0de8820.
Change-Id: Ie56bd38649a821f6b22a1e5dee5f50ef397035fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10002
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
CPTR_EL3 and CPACR_EL1 are the registers for controlling the trap level
and access right of the FPU/SIMD instructions. Need to save/restore them
in every power cycle to keep the settings consistent.
BRANCH=none
BUG=none
TEST=boot on smaug/foster, verify the cpu_on/off is ok as well
Change-Id: I96fc0e0d2620e72b6ae2ffe4d073c9328047dc01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 73e8cc8f25922e7bc218d24fbf4f7c67e15e3057
Original-Change-Id: I51eed07b1bb8f6eb2715622ec5d5c3f80c3c8bdd
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/266073
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-on: http://review.coreboot.org/9981
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Implement the individual core powerdown sequence as per
Cortex-A57/A53/A72 TRM.
Based-on-the-work-by:
Varun Wadekar <vwadekar@nvidia.com>
BRANCH=none
BUG=none
TEST=boot on smaug/foster, verify the cpu_on/off is ok as well
Change-Id: I4719fcbe86b35f9b448d274e1732da5fc75346b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b6bdcc12150820dfad28cef3af3d8220847c5d74
Original-Change-Id: I65abab8cda55cfe7a0c424f3175677ed5e3c2a1c
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265827
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9980
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patchs introduces level specific data cache maintenance operations
to cache_helpers.S. It's derived form ARM trusted firmware repository.
Please reference here.
https://github.com/ARM-software/arm-trusted-firmware/blob/master/
lib/aarch64/cache_helpers.S
BRANCH=none
BUG=none
TEST=boot on smaug/foster
Change-Id: Ib58a6d6f95eb51ce5d80749ff51d9d389b0d1343
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b3d1a16bd0089740f1f2257146c771783beece82
Original-Change-Id: Ifcd1dbcd868331107d0d47af73545a3a159fdff6
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265826
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9979
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Same as commit fe0eac5f416e "arm64: Allow cpu specific early setup", we
need the same in secmon too.
BRANCH=none
BUG=none
TEST=boot on smaug/foster
Change-Id: I5b1347880306a95f99233db12cb99547bad4aa8c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1f70fd940ff92eb5b8991cd777c2894b7a9633cf
Original-Change-Id: Ifce5a6d636051e7a447d055c8e09ed4e29e091c7
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265825
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-on: http://review.coreboot.org/9978
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Call arm64_cpu_early_setup to allow cpu-specific initialization to be
performed. Also, add support for setting SMPEN bit for cortex a57
within arm64_cpu_early_setup.
BUG=chrome-os-partner:38222
BRANCH=None
TEST=Compiles successfully and SMP works for foster
Change-Id: Ifa4e6134dbce3ad63046b3dd9b947c3d9134d5e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fe0eac5f416efcf9f7b05388a17444205a8352c0
Original-Change-Id: I28a05a20e6adf084cd0bf94bdd0c3b492632107c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/262993
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9977
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Disable and enable GIC before switching off a CPU and after bringing
it up back respectively.
BUG=None
BRANCH=None
TEST=Compiles successfully and psci commands work for ryu.
Change-Id: Ib43af60e994e3d072e897a59595775d0b2dcef83
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5271d731f0a569583c2b32ef6726dadbfa846d3
Original-Change-Id: I672945fcb0ff416008a1aad5ed625cfa91bb9cbd
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265623
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9926
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
PSCI_CPU_OFF is SMC32 call, there is not SMC64 version. Register SMC32
and SMC64 types of PSCI calls.
BUG=None
BRANCH=None
TEST=Compiles successfully and CPU off works fine with PSCI command.
Change-Id: I8df2eabfff52924625426b3607720c5219d38b58
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9228c07f9d9a4dd6325afb1f64b41b9b8711b146
Original-Change-Id: I2f387291893c1acf40bb6aa26f3d2ee8d5d843ea
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265622
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9925
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We support SMC32 calls from AARCH64, however we do not support SMC32
calls from AARCH32. Reflect this policy in the code by using
appropriate names for exception type check in SMC handler.
BUG=None
BRANCH=None
TEST=Compiles successfully and able to turn CPU1 on and off using psci commands.
Change-Id: Ifc3c9e2fe0c4e6e395f2647769a2d07f5f41f57f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cbaf712c2c45273a9eb0b0808a0d4d0630023fdd
Original-Change-Id: I133b2c0bbc4968401a028382532bd051d6298802
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265621
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CNTFRQ_EL0 can only be set in highest implemented exception level.
Save and restore CNTFRQ_EL0 for secondary cpus in coreboot.
This patch fix the error below:
SANITY CHECK: Unexpected variation in cntfrq. Boot CPU:
0x00000000c65d40, CPU1: 0x00000000000000
BRANCH=none
BUG=none
TEST=boot to kernel on oak board and check secondary cpu's cntfrq.
confirmed cpu1's cntfrq is same as boot cpu's.
Change-Id: I9fbc3c82c2544f0b59ec34b1d631dadf4b9d40eb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b47e4e649efc7f79f016522c7d8a240f98225598
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Change-Id: I2d71b0ccfe42e8a30cd1367d10b0f8993431ef8c
Original-Reviewed-on: https://chromium-review.googlesource.com/264914
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9921
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add arm64_arch_timer_init function which should be called per CPU for
setting up the cntfrq register of arch timer. During the Linux kernel
bring up time, it will check the cntfrq register per CPU and should be
the same with the boot CPU.
BRANCH=none
BUG=none
TEST=bring up 4 cores in Linux kernel without warning message of cntfrq
register value
Change-Id: I9cb33a54c2c8f9115bbe545a2338ca8e249b8db6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 253cd3c68bb4513ae2033c12c2f070ee391e5a13
Original-Change-Id: I71068dbdd00a719145410ef6ec466f001ae837ad
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/264244
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9915
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to allow proper working of caches, set the correct
shareability option for normal memory.
BUG=chrome-os-partner:38222
BRANCH=None
TEST=Compiles successfully for foster and SMP works.
Change-Id: I5462cb0a2ff94a854f71f58709d7b2e8297ccc44
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e092916780716ac80c3608c1bd8ca2901fbb3bd1
Original-Change-Id: Idd3c096a004d76a8fd75df2a884fcb97130d0006
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/262992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The hardware initialization is now split in basic
initialization (MIPS and system PLL, system clock,
SPIM, UART), and initialization of other hardware
blocks (USB, I2C, ETH). The second part uses board ID
information to select setup that is board specific
(currently only I2C interface is selected through
board ID).
BRANCH=none
BUG=chrome-os-partner:37593
TEST=tested on bring up board for both Urara and Concerto;
to simulate the use of Concerto (I2C3) DIP SW17 was
set to 0.
it works with default settings on Urara
Change-Id: Ic5bbf28ab42545a4fb2aa6fd30592a02ecc15cb5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f2b3db2e7f9fa898214f974ca34ea427196d2e4e
Original-Change-Id: Iac9a082ad84444af1d9d9785a2d0cc3205140d15
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/257401
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9888
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=None
BUG=None
TEST=build coreboot, make sure there are fmov instructions
generated by the compiler, and boot to kernel
Change-Id: Ia99c710be77d5baec7a743a726257ef3ec782635
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f770a436a0692c8e57a8c80860a180330b71e82c
Original-Change-Id: Iab4ba979b483d19fe92b8a75d9b881a57985eed7
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/262242
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to not duplicate the instruction cache invalidation
sequence provide a common routine to perform the necessary
actions. Also, use it in the appropriate places.
BUG=None
BRANCH=None
TEST=Built on ryu.
Change-Id: I29ea2371d034c0193949ebb10beb840e7215281a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5ab28b5d73c03adcdc0fd4e530b39a7a8989dae
Original-Change-Id: I8d5f648c995534294e3222e2dc2091a075dd6beb
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260949
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9871
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: If1850c4a6df29b1195714ed0bdf025e51220e8ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf3b4924121825a5ceef7e5c14b7b307d01f8e9c
Original-Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223784
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remember the XN bit? The one we had so much fun with on Nyan (LPAE)
because not setting it allows random instruction prefetches to device
memory that hang the system every few thousand boots? Thankfully, we had
always been setting it in the non-LPAE MMU code already...
"When the XN bit is 1, a Permission fault is generated if the processor
attempts to execute an instruction fetched from the corresponding memory
region. However, when using the Short-descriptor translation table
format, the fault is generated only if the access is to memory in the
Client domain, see Domains[...]" - ARM A.R.M. section B3.7.2
Oops. This patch changes our Domain Access Control Register (DACR) to
set domain 0 (the only one we are using) to Client. This means that
access permissions (AP[2:0] bits) become enforced, but they are already
set to full access (0b011). It also means that non-LPAE systems will not
be allowed to execute from DCACHE_OFF memory with enabled MMU anymore.
As far as I can see, Veyron_Pinky has been the only board that does
that.
BUG=chrome-os-partner:32118
TEST=Booted Veyron_Pinky with MMU in the bootblock, saw hangs that look
like spurious prefetches and confirmed that this patch fixes them.
Change-Id: I81c00743f938924a5dc8825389fe512a069b77db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cbc96db296a41ae700371a8515a1179c142f58e7
Original-Change-Id: I30676a5bfe12d516e5f910f51ee6854f6e5be557
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds an mmu_config_range_kb() function, which can set memory
types at the 4KB level by chaining a fine-grained page table to an
existing superpage entry. It is only intended for special cases where
this level of precision is really necessary and therefore comes with a
few practical limitations (the area for each invocation must be confined
within a single superpage, and you are not allowed to remap the same
region with mmu_config_range() again later). Since the fine-grained page
tables need some space, boards intending to use this feature must define
a TTB_SUBTABLES() region in their memlayout.ld.
BUG=chrome-os-partner:32848
TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured
that they still work. Checksummed the page tables with and without this
patch, confirmed that they end up equal. Hacked in some subtable test
entries, hexdumped all tables and manually confirmed that they look as
expected.
Change-Id: I8c3eb7c2eb9c82e2abc5f2c0dda91f5b2eee7023
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f13e60cf5509b9a63fb7b8d84846daf889dc1b7
Original-Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223781
Reviewed-on: http://review.coreboot.org/9341
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I overlooked the macro name change from the Kconfig option.
'ARM' and 'V4' should not be separated by a '_'.
Change-Id: I8bf0d851e6fd5b5cfc0aa29af2246540c8cb1399
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9371
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
C0 is a coprocessor register set defined in certain MIPS
architectures. This patch adds macros necessary to access the
registers and a couple of helper macros to access two particular
registers needed in the next patch.
The definitions come straight from arch/mips/include/asm/mipsregs.h in
the 3.14 kernel tree.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=the following patch demonstrates timer counter C0 register
configuration and use.
Change-Id: Ia5d52ffa75f2dd66d4cee3a4ed0af5122ccb2113
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eb3d69eaf1561ca0b995720c24dafe2e6e22707d
Original-Change-Id: Ia4b1da40ecc1a03cf1cba0c648d42cd189fbcf93
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227887
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9336
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
... so uint32_t is known by the time it's used.
Change-Id: I7281e869ce2e00165a0e21bc017aa6c0e27827b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9333
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
With kconfig understanding wildcards, we don't need
Kconfig files that just include other Kconfig files
anymore.
Change-Id: I7584e675f78fcb4ff1fdb0731e340533c5bc040d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9298
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This allows combining and simplifying linker scripts.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ie5c11bd8495a399561cefde2f3e8dd300f4feb98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Fix up commit b3847e64 (program loading: add prog_run() function),
which misses the braces for the if statement, causing the function
also to return if a non-payload program should be run causing the rest
of the stages never to be run.
Change-Id: I04940b218ba71e82af769c8db574528f830d0cbb
Found-by: Coverity, CID 1293136: Control flow issues (NESTING_INDENT_MISMATCH)
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/9306
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Instead of keeping this separate variable around, add linker scripts
to the $(class)-y source lists and let the build system sort things out.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I4af687becf2971e009cb077debc902d2f0722cfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9289
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
So far we assumed that all files in *-srcs are below src/
which wasn't really true actually and will be less true with
future changes.
Fix up crt0.S handling on x86, which is covered by default rules
due to this change.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Icae563c2d545b1aea809406e73faf3b417796a1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9288
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Secmon needs a special build rule because of the objcopy -B
operation required to include it in ramstage. Utilize the
manual template so builds continue to work with upcoming
build chnages.
Note: secmon is actually missing symbols still so those
still need to be addressed. That looks to be as if
--gc-sections isn't be honored, but I'm actually thinking
the symbols are just erroneously carried over as the
references for these symbols don't show up in the
symbol table:
U coreboot_build
U coreboot_extra_version
U coreboot_version
U default_baudrate
U lb_add_console
U lb_add_serial
U uart_baudrate_divisor
Change-Id: I41c75e93536b73c4304ef3a87dc39d448d1f00d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The ldscript_ prefix is redundant.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I0f005c0c2abe2fdd6911a2c579cb7ec49ae5c0b7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9284
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of having different structures for loading
ramstage and payload align to using struct prog.
This also removes arch_payload_run() in favor of
the prog_run() interface.
Change-Id: I31483096094eacc713a7433811cd69cc5621c43e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8849
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The prog_run() function abstracts away what is required
for running a given program. Within it, there are 2
calls: 1. platform_prog_run() and 2. arch_prog_run().
The platform_prog_run() allows for a chipset to intercept
a program that will be run. This allows for CPU switching
as currently needed in t124 and t132.
Change-Id: I22a5dd5bfb1018e7e46475e47ac993a0941e2a8c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8846
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The struct prog serves as way to consolidate program
loading. This abstraction can be used to perform more
complicated execution paths such as running a program
on a separate CPU after it has been loaded. Currently
t124 and t132 need to do that in the boot path. Follow
on patches will allow the platform to decide how to
execute a particular program.
Note: the vboot path is largely untouched because it's
already broken in the coreboot.org tree. After getting
all the necessary patches pushed then vboot will be
fixed.
Change-Id: Ic6e6fe28c5660fb41edee5fd8661eaf58222f883
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8839
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also gives ARM64 its
own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech off the ARM one
(currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: I3e8bb3dfbb2c4edada621ce16d130bd7387d4eb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5528aa9252cdf711af3c160da387c6a7bebe9e76
Original-Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9235
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It also creates file names in the build directory and with
the stage sliced in, but keeps the extension for anything
not .c or .S.
Also some handling for non-.c/.S files was adapted to match.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: If8f89a7daffcf51f430b64c3293d2a817ae5120f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
A branch instruction in a branch delay slot confuses the execution
pipeline and causes an exception.
bootblock.S was written 'by hand', has a branch instruction in branch
delay slot and includes '.set noreorder' directive, which causes it to
crash when trying to branch to main().
Adding a nop instruction fixes the problem. Also adding a nop after
the last branch in the file just in case main() returns and the object
linked next starts with a branch.
BUG=chrome-os-partner:31438
TEST=Running on the simulator can reach main() now
Change-Id: I0882b2eb5ce426f5a311018ffbb6f37a2ca64d98
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221421
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9183
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The ARM SMP feature was added a long time ago and has never really been
used by anyone since. We are still always compiling cpu_info() even
though we don't use it, and it makes some dangerous assumptions about
stack alignment that are not guaranteed anywhere.
I'm planning to change the way the stack boundaries are defined. Rather
than trying to work that into this unsafe, unused and hard to test
feature, I think we should just seal it off with police tape and make
sure that if anyone ever tries to use it again (which currently seems
unlikely), they get forced to do their due diligence on making sure it
works as intended.
BUG=None
TEST=Compiled Veyron_Pinky.
Change-Id: Id25545cab88f29200c7672ef02c7804f0ac26399
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5b517fc46b030a6e50ef2f5e4d4a449b98ce16c6
Original-Change-Id: I8a60bd30e8b27a22bb3da68ca84daea99424dee9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219680
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9222
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
mosys will use this field to identify system
BRANCH=none
BUG=chromium:359155
TEST=build ok, use dmidecode to check whether data is
written correctly
Change-Id: I461215c012b6ad712b3f813a3928e90a23bf54f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7adbdab761cd7b4bda0a43e7b1c4070de26f150a
Original-Change-Id: Icfbd4c61fc49a9cb3d3ecd2b622339957963150c
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217400
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9230
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of relying on the CBFS header's romsize field use
the CONFIG_ROM_SIZE Kconfig variable. That value is what is
used to create the rom file as it is. Therefore, just remove
the dependency.
Change-Id: If855d7378df20080061e27e4988e96aee233d1e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9130
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The serialized format of CBFS is separate from the APIs
used to traverse and read from CBFS. Separate those out
so they can be consumed as a standalone header.
Change-Id: I09f71d9c474ee9f23a62b0062ffa777963d1a4dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9125
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Use the run_romstage() API to prevent code duplication
and more maintenance for any API changes or features.
Change-Id: I4122b813cccf4dc0703f256e1245deeeb90deeb9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9172
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This replicates commit 3f7ad7b216 and
commit 823edda98e for mips.
Change-Id: Id97e1fefa20cfa3bcb2cf0336b5a4ff7d9fe813b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9166
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The console interface changed in upstream, and the
driver didn't reflect that yet.
This wasn't obvious because the driver wasn't compiled
at all.
Change-Id: Id18391e62e7ebd8f5fc929838ce27bf414e364f9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9165
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The mips Makefile was inherited from x86 and so included lots
of stuff that is necessary on x86 but nowhere else.
That cruft is now gone.
It also adopts the non-x86 approach of handling linker scripts,
hardcoding an include to ldoptions there, instead of manual
concatenation (of just one file plus options).
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ibf0c7096f9425572d8f83837aa6a253fd91e212c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9163
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Introduce generic-$(type)-ccopts and $(class)-generic-ccopts
to declare compiler flags that apply to all files of a certain
type or of a certain class. Then use them.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I655688e82a0cc5bad89b6f55dc217b9f66b64604
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9114
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I192fa50989b586fd8e967d4c22db56ac9de7a30e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9108
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
It points to a binary.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I164d7f717a9523d187e2c215083e176b59fd5acc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9113
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: Ia22c9fcbf8c629d0eb3f1356f80c4565f117d8b8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9110
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have .lb, .lds, and .ld in the tree. Go for .ld everywhere.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I3126af608afe4937ec4551a78df5a7824e09b04b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I362e2f6a978de23e72e6fc9c83bc99457cd76d9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9112
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I8a5dc66d8c0dc4ccdb6dc3d66b8cdbf50dc976ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9111
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the approrpiate car* empty implementations as well as types
included within the rest of coreboot to start building correctly.
Change-Id: Ifaf10281f9a9e28f518f4694630cbffa3f8d187d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9150
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Aaron Durbin <adurbin@google.com>
Since PSCI dynamically determines which EL to transition
to based on SCR_EL3 there's no need to provide that
information.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted into kernel with MP.
Change-Id: Ia59bc8116ec4ae9bde2e6cad1861f76c14f7d495
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8bc5f7c8a114568ede98478c2fbea2f8b7d97f0c
Original-Change-Id: I8783b6315dca01464e14c9d2b20d009cf0beeb67
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218924
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9098
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The PSCI functionality initially includes CPU_ON and CPU_OFF
functions. Upon entering secmon if the parameters are non-NULL
then a PSCI CPU_ON action is done for the current CPU.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted kernel with PSCI support. Brought up all CPUs in kernel
using PSCI. Turned CPUs on and off.
Change-Id: I256fa45a1c9889ff9d7990eb1898df1ec241c117
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 689ba03e313e7e52e9b74aa774897b55cbd52748
Original-Change-Id: I943826b7dbcc8e3f6c8c4b66344af8fac12ba94e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218923
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9097
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
If an exception is taken that the secmon won't return
to, there needs to be way to reset that cpu's state
w.r.t. stack usage. Therefore, provide secmon_trampoline
which will reinitialize the exception stack and SP_EL0
and start executing with SP_EL0 like the initial state
of the secmon entry.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted to kernel. Also tested when PSCI
is employed in the kernel.
Change-Id: Ie9f5bbe715dcbcf8b67ea40f9a3a5088ac7aa2ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1f546ee3e9eca93baaa1ae0437351205bf548a5
Original-Change-Id: Ia3da75e1fa0251c8ea30eb0b0523c8a51c03b917
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218922
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9096
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Two things:
1. Not returning once setting the return state.
2. mempcy(x, y, ARRAY_SIZE(x)) is not memcpy(x, y, sizeof(x))
With these 2 changes arguments and results are being processed
correctly.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and brought up SMP using PSCI.
Change-Id: If76a207e1a434a4c08faaa535f069d7386481e9e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 42d540afd4e6ea2b34cf3632ad2c683fcaa063c8
Original-Change-Id: I656b9c11e3bc07cc1664789a600eb88afd639f93
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218847
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9094
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to process PSCI commands SMC instructions need to be
serviced. Provide a simple way for users of SMC to register their
handlers by function.
The SMC layer hooks into the exception processing, however it only
processes AARCH64 SMC calls. All others are ignored.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Added nop smc call to depthcharge. SMC handled and continue booting
to kernel.
Change-Id: I378f13c29220ff9f37040f094bf9cfb69259af0c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 76d2febc50397348b68d38532b8f37e2b3cf6a30
Original-Change-Id: Ieaa29fa883b9f9d55fc62ba92a1d45452296efa4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218846
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9092
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The exception vectors were not reinitialized in secmon yet.
Add that as well as the split BSP vs non-BSP path. In doing
so bring in the cpu.c semantics for determining bsp at runtime.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted to kernel. Also noted only one CPU
printing messages.
Change-Id: I26a7f9446f4422d2203b1d520e69f8dee9450b59
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 67f79c61c902ee614f029047255b4be35112cd32
Original-Change-Id: Ide66f13c24f5798d5983c481ce616ae2800d558c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218845
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9091
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's helpful to differentiate the startup paths for
the BSP and the non-BSP. Therefore have c_entry
be an 2 element array of function pointers. The
non-BSP paths have an entry point one instruction after
stage/module entry.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: I40bb40462906f1b1eaf2db8584985095e8ac0bae
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ce10f954041b3fd581ad8a3d82dee567b68637fe
Original-Change-Id: Ia573b1095dca5f69e371bf1ddf6b6df72fa3b52e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218844
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9090
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cpu.c contains some helpful construts as well as ramstage
devicetree handling. Split the 2 pieces so that cpu.c can be
reused in secmon.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted.
Change-Id: Iec0f8462411897a255f7aa289191ce6761e08bb0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4f30f1186950424b65df6858965a09ca51637e4f
Original-Change-Id: Ie87bd35bf1ccd777331250dcdaae07dab82d3d18
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218842
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9089
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to build upon the arm64 exception handlers need
to be registered. This provides very basic support to
register a handler for a specific exception vector.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted into kernel.
Change-Id: If046f0736765a2efeb23201c1d2d1f7f7db47dd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a82e5e8d5900ebef16abdb68701be6beeb9ca13a
Original-Change-Id: I0f68a48101ff48d582f5422871b9e7e5164357e4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218650
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9088
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There was a hacky and one-off spin table support in tegra132.
Make this support generic for all arm64 chips.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Ran with and without secure monitor booting smp into the kernel.
Change-Id: I3425ab0c30983d4c74d0aa465dda38bb2c91c83b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 024dc3f3e5262433a56ed14934db837b5feb1748
Original-Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218654
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9084
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's helpful to know if the current running CPU
is the BSP. Therefore, provide that semantic.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: I18cb8ab5149c3337e22b1f6046b1af266be7e47c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b390dc70b658c207cd3b64408713ec4cddab3172
Original-Change-Id: I3d5518d1f6d6a78b14f25bb7ef79727605064561
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218653
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9083
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to provide richer semantics for running code
on all CPUs add an all-but-self construct.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: If8dd28ff7f34d93592ab2025a65a2fd665e4e608
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a4622f63a065f620f0c92ef92eeb2aa5c2b441d
Original-Change-Id: Id18dc0423bcb0016ed36ace659b3f858e824c46c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218652
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9082
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
stage_entry is the best place to enter for secmon, since it sets up all the
stacks right. The only need we need to take care is losing out on the parameter
passed to secmon. This patch adds an entry point for secmon rmodule and moves
the argument from x0 to x25, which is restored just before the jump to c_entry
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully
Change-Id: I9638e9716b3bd5bff272e88fe9d965528d71e394
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffedb03208bafab6d5886db0259ec205dd20588f
Original-Change-Id: I74a7a609fbc08692d68708abe132cd219c89b456
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217570
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/9079
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide SCR_EL3 initialization on all CPUs. This settings were
chosen in such a way that nothing would need to be done if EL3
is abandoned after transitioning to EL2 or EL1. If persistent
EL3 program is used those SCR policies can be updated within
that program.
BUG=chrome-os-partner:31634
BRANCH=None
TEST=Built and booted through kernel. Printed out SCR setting for
each CPU.
Change-Id: Ib44acd8ae40dbca590740340632f5b72998e9dd8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f77b903afbafad7d439ec50fc48f1eaa37827d90
Original-Change-Id: Id659f0a98360fe8bbc80e5a623eba1526e81b400
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218300
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9078
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For every CPU that comes online initialize the GIC for
that CPU. This allows the per-cpu register state to
be initialized for every CPU that comes online.
BUG=chrome-os-partner:31945
BRANCH=None
TEST=Built and booted to kernel on ryu.
Change-Id: I467ca38d51ac67ffc19b1b4fc6fafa9394a876c9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b2faf33fad80fd7ecb884d3ad40917f5a629a5b2
Original-Change-Id: I58d0ffcfe65cffc6a4dd2678c041219e1e698aaf
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217513
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9076
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Transition library acts as a common interface for handling exceptions. The only
thing that needs to be implemented by exception.c is the exc_dispatch routine to
handle the exceptions as required.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and exceptions are tested using test_exc
Change-Id: I90b4861909189adfe8449b9d4590965e6b743c00
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b83c9404407dd4dd2dda4e4eaed0b443f0f58425
Original-Change-Id: Ibb643d7ea2f9aabbc66439549ea2168fd66ced5e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217143
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/9071
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Transition library provides the following functionalities:
1) Setup the environment for switching to any particular EL and jump to the
loaded program at that EL. In short "Execute program X at exception level Y
using the state Z"
2) Provides routines for exception entry and exception exit that can be used by
any program to implement exception handling. The only routine required by the
program would be exc_dispatch which handles the exception in its own required
way and returns by making a call to exc_exit. On exc_exit, the transition
library unwinds the whole stack by popping out the saved state of xregs
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and exceptions are tested for ramstage on ryu
Change-Id: I8116556109665e61a53e4b3987d649e3cfed64a1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ab888e8cae0c5f1e79b0e16ca292869f16f1cca
Original-Change-Id: I90f664ac657258724dc0c79bd9f6ceef70064f90
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216375
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/9070
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If mmu_init is called more than once then, free_idx should be reset to
1. Here, the assumption would be that mmu_init will not be called more than
once. However, this is not necessarily true. Thus, free_idx should be reset to 1
every time we are initializing ttb from scratch.
BUG=None
BRANCH=None
TEST=Compiles sucessfully and boots to kernel
Change-Id: I5ac0af43346a492583380b0f15101390fc98d182
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 398a68c3b08d82cfa521d235af2c1922629bdf56
Original-Change-Id: Idb7424df7dd577f263f12d1527dbd7fb89216d40
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216906
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/9068
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If there are no devices underneath a device in a devicetree the
bus pointer in a struct device is NULL. Check for this condition
before proceeding in walking through the children devices.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Ran through coreboot w/o any devices under the cpu_cluster device.
No more exceptions.
Change-Id: I9aedbc0dffc638b878bd0ffacfa318b6eb30d504
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d21e181077eba3c5ee03afca1738a24c21a8fc19
Original-Change-Id: I891aeb36319dce67ce9e431156c85c74177c7ab7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/217511
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9066
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of relying on config variables to determine the current el, use
{read/write}_current macros for accessing registers.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and boots to kernel login prompt
Change-Id: I6c27571fa65e06e28b71fee3e21d6ca93542e66b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 96aed53b2879310f6f979d5aa78b8d1df7f04564
Original-Change-Id: If4a5d1e9aa50ab180c8012862e2a6c37384f7f91
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217148
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9065
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Allow read/write to registers at a given el. Also, make read/write registers at
current el call this newly added function.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully
Change-Id: I98f35b8d3eb5e292ac895102ad91b675325c08c7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 11d90df1fd92e03c25bfc463429a5f6a8d9d411d
Original-Change-Id: I17de4c4f3bc1ee804422efe5f4703b4dd65b51f2
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216904
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/9063
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to ease the process of reading and writing any register at current EL,
provide read_current and write_current assembly macros. These are included in
arch/lib_helpers.h under the __ASSEMBLY__ macro condition. This is done to allow
the same header file to be included by .c and .S files.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully
Change-Id: I51749b6e4ae7b1ffbaae28d915cd100a28959f26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c11c7287f507fa398cbbee75abc2bd11140ef19b
Original-Change-Id: I1258850438624abfe3b1ed7240df0db0e7905be6
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216373
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9062
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add smbios type 17 which can optionally be implemented
at the platform or mainboard level
In order to create SMBIOS type17, you will need to fill
memory_info data
BUG=None
BRANCH=None
TEST=Compile successfully on rambi and samus
Boot to chromeOS on samus and rambi
Original-Change-Id: Ie4da89135c879d7a687305d423103fcfcbb96e3f
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/210005
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit 634b899ba41242caa800d7b570f3a339c738db77)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I61d1e8b1d32d43f0011b0f93966d57646ea0eb63
Reviewed-on: http://review.coreboot.org/8955
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The original purpose of soc_secondary_cpu_init() was to provide
a way for the SoC to run code on the secondary processors as
they come up. Now that devicetree based bringup is supported
there's no need to have this functionality.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Booted SMP into linux.
Change-Id: I6fa39b66a8b728d9982b0721480b7fae45af7c6e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1356ec527e2bc61043ccd7dea4a7ff5182b16f3e
Original-Change-Id: Ie5c38ef33efadb2d6fdb2f892b4d08f33eee5c42
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216927
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9044
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are some ARMv8/ARMv4 SoC where the ARMv8 part needs to be
SMP aware but the ARMv4 part does not.
Until we need real SMP on ARMv4, work around that situation
with stub defines.
Change-Id: Iec5b4302b19c17fe2b3f677b84a8edf4b4902946
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9046
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds SMP bring up support for arm64 cpus. It's
reliant on DEVICE_PATH_CPU devices in the devicetree.
Then for each enabled device it attempts to start then
initialize each CPU. Additionally, there is a cpu_action
construct which allows for running actions on an individual
cpu.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Booted both cores on ryu into linux.
Change-Id: I3e42fb668034c27808d706427a26be1558ad2af1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a733fd566a8e5793da5ff28f9c16c213f411372e
Original-Change-Id: I407eabd0b6985fc4e86de57a9e034548ec8f3d81
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216925
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9042
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide a simple spinlock implentation for arm64. A value
of 0 is unlocked and a value of 1 is locked.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Built and ran SMP bringup on ryu.
Change-Id: Ie88a715a6b51cd38a5fdd830583dae528cc49d67
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 14dab94610c96d6b1530c64d661833f8e613101c
Original-Change-Id: I3bf2d80b91112d04442455ff0fa3f16900b7327f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216923
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9040
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The spinlock header file was not residing in the correct place.
It needs to live under 'arch/smp'.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Built with SMP. spinlock.h found.
Change-Id: Ie0e974674a6ea8ec769ca0ce64eb888c4d094652
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 50079befdc3d43306e4ae9e543f7266f1ac99aa0
Original-Change-Id: I0e594cacfafcd6f30802c9563785ca09a2f7a2af
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216922
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9039
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The load-acquire/store-release operations (including exclusive
variants) form a basis for atomic operations. Also remove
the dmb, dsb, and isb functions from lib_helpers as barrier.h
already included these. Lastly, utilize barrier.h.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Built and ran SMP bringup using barriers.
Change-Id: I6304a478d769dc2626443005b4eec4325d8a06f4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8fac8d46b09d449d59f1b4f492d363392dcc4118
Original-Change-Id: I77ff160c635297a2c7cab71cb0d3f49f2536f6ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216921
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9038
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
printk() shouldn't be called until the consoles have been
initialized. This just so happened to work by luck. Once
CONFIG_SMP is enabled that breaks because of spinlock
usage in uncached memory.
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Built with CONFIG_SMP and ramstage doesn't hang early.
Change-Id: I54231db3c811c0d19c5c7fbaa406cacd1ff019ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 31c3f972ac5c89472009b5b2cb7dbc0f02cfd9a0
Original-Change-Id: I6091b1e949e648b3435231946e5924260bf1807f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/216920
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9037
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Patrick Georgi