summaryrefslogtreecommitdiff
path: root/src/arch/arm64
AgeCommit message (Collapse)Author
2015-04-28vboot2: Build verstage archive, then use that for building the stagePatrick Georgi
This slightly streamlines integrating the vboot2 library and prepares for merging verstage and bootblock on selected devices. Change-Id: I2163d1411d0c0c6bf80bce64796e1b6a5a02b802 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10004 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-27arch/arm64: update mmu translation table granule size, logic and macrosJimmy Huang
1. change mmu granule size from 64KB to 4KB 2. correct level 1 translation table creation logic 3. automatically calculate granule size related macros BRANCH=none BUG=none TEST=boot to kernel on oak board Change-Id: I9e99a3017033f6870b1735ac8faabb267c7be0a4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2f18c4d5d9902f2830db82720c5543af270a7e3c Original-Change-Id: Ia27a414ab7578d70b00c36f9c063983397ba7927 Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265603 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/10009 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-04-27arm64: save/restore cptr_el3 and cpacr_el1 registersJoseph Lo
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>
2015-04-27arm64: implement CPU power down sequence as per A57/A53/A72 TRMJoseph Lo
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>
2015-04-27arm64: introduce data cache ops by set/way to the level specifiedJoseph Lo
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>
2015-04-27arm64: perform early setup in secmon tooJoseph Lo
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>
2015-04-27arm64: Allow cpu specific early setupFurquan Shaikh
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>
2015-04-22armv8/secmon: Disable and Enable GIC in PSCI pathFurquan Shaikh
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)
2015-04-22armv8/secmon: Correct PSCI function idsFurquan Shaikh
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>
2015-04-22armv8/secmon: Correct names for SMC macrosFurquan Shaikh
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>
2015-04-22arm64: save and restore cntfrq for secondary cpusJimmy Huang
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>
2015-04-22arm64: add arm64_arch_timer_init functionJoseph Lo
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>
2015-04-22arm64: Correct shareability option for normal memoryFurquan Shaikh
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>
2015-04-22arch/arm64: allow floating-point registers accessYen Lin
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>
2015-04-22arm64: provide icache_invalidate_all()Aaron Durbin
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>
2015-04-21Unify byte order macros and clrsetbitsJulius Werner
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>
2015-04-21arm(64): Change write32() argument order to match x86Julius Werner
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>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
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>
2015-04-14CBFS: Correct ROM_SIZE for ARM boards, use CBFS_SIZE for cbfstoolJulius Werner
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>
2015-04-10arm64: No need of invalidating cache line for secondary CPU stackFurquan Shaikh
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>
2015-04-10arm64: Add support for save/restore registers for CPU startup.Furquan Shaikh
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>
2015-04-10arm64: Add macro to invalidate stage 1 TLB entries at current ELFurquan Shaikh
BUG=chrome-os-partner:33962 BRANCH=None TEST=Compiles successfully for ryu. Change-Id: Ia4941a864dd3394689121a8c9ddfaaf6f5c150a1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1e43a081f7394b2014d89e723f816f1eca83ef49 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Change-Id: I60d77456573a2a1e854d9f3ca730237acfb77728 Original-Reviewed-on: https://chromium-review.googlesource.com/231698 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/9539 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10arm64: Add conditional read/write from/to EL3 assembly macros.Furquan Shaikh
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>
2015-04-10arm64: Add function for reading TCR register at current ELFurquan Shaikh
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>
2015-04-10arm64: psci: actually inform SoC layer of CPU_ON entryAaron Durbin
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>
2015-04-10arm64: ensure secondary CPU's stack tops are not in the cacheAaron Durbin
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>
2015-04-10arm64: add timeout waiting for CPUs to come onlineAaron Durbin
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>
2015-04-10arm64: Implement PSCI command supportAaron Durbin
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)
2015-04-10arm64: secmon: add entry point for turned on CPUsAaron Durbin
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)
2015-04-10arm64: secmon: pass online CPUs to secmonAaron Durbin
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>
2015-04-10arm64: psci: use struct cpu_action to track startup entryAaron Durbin
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>
2015-04-10arm64: secmon: prepare for passing more state into secmonAaron Durbin
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>
2015-04-10arm64: secmon: wait for all CPUs to enter secmonAaron Durbin
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>
2015-04-09arm64: secmon: direct non-BSP cpus to start before BSPAaron Durbin
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>
2015-04-09arm64: psci: add node hierarchyAaron Durbin
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>
2015-04-09arm64: add malloc support to secmonAaron Durbin
In order to dynamically allocate structures based on affinity levels add malloc() support. BUG=chrome-os-partner:32136 BRANCH=None TEST=Built and booted to kernel. Change-Id: I40cbd8497a1599db12b9e87eeb379f7dcd21c9b0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9cd2b23c2ea045b5832b3d838e29f4b6a1b6cdfb Original-Change-Id: Ie1412a3a9eb07689059a2cd69bd111274bcb88fa Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/226482 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/9389 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2015-04-09arm64: add mpidr field to cpu_info structAaron Durbin
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>
2015-04-08arm64: Add timestamp.c to bootblock and verstageFurquan Shaikh
BUG=chrome-os-partner:32973 BRANCH=None TEST=Compiles successfully Change-Id: Ia4715fd7a852b82c66d436eb12988f8e3290b9b0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0d88dd324a8ee0ace51e9ad2343d81cc828a4f34 Original-Change-Id: I662163848a772018f1e8eb003aa3d3bc06e80e98 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223347 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/9359 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-07arm: Include types.h in clock.hPatrick Georgi
... 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>
2015-04-07arm64: Add verstage supportFurquan Shaikh
This stage is not tested on any hardware. BUG=None BRANCH=None TEST=Compiles successfully for rush_ryu and veyron_pinky Original-Change-Id: I6dd266471c815895bb3dd53d34aacc8fe825eeb6 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/221911 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 907ea2d1f8c9f01d815e8673695dd5271322c7a8) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I617a742d4a387be947086dae33e9a913f742a8d1 Reviewed-on: http://review.coreboot.org/9255 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-07kconfig: drop intermittend forwarder filesStefan Reinauer
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>
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
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>
2015-04-06build system: run linker scripts through the preprocessorPatrick Georgi
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>
2015-04-06arch/arm64/boot.c: Only return if condition is metPaul Menzel
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>
2015-04-04arm64: make secmon link with the manual templateAaron Durbin
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>
2015-04-03program loading: unify on struct progAaron Durbin
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>
2015-04-03program loading: add prog_run() functionAaron Durbin
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>
2015-04-03program loading: introduce struct progAaron Durbin
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>
2015-04-02Clean up architecture-specific KconfigsJulius Werner
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>
2015-04-02build system: extend src-to-obj for non-.c/.S filesPatrick Georgi
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)