summaryrefslogtreecommitdiff
path: root/src/arch/arm64/Makefile.inc
AgeCommit message (Collapse)Author
2017-05-183rdparty/arm-trusted-firmware: Update to upstream masterMartin Roth
Submodule 3rdparty/arm-trusted-firmware 236c27d21f..3944adca59 This brings in 241 new commits from the upstream arm-trusted-firmware repository, merged to the upstream tree between December 30, 2016 and March 18, 2017. 3944adca Merge pull request #861 from soby-mathew/sm/aarch32_fixes .. e0f083a0 fiptool: Prepare ground for expanding the set of images at runtime Also setup ATF builds so that unused functions don't break the build. They're harmless and they don't filter for these like we do. Change-Id: Ibf5bede79126bcbb62243808a2624d9517015920 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18954 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-03-28Remove libverstage as separate library and source file classJulius Werner
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are linked directly into the bootblock or the romstage. However, they're still compiled with a separate "libverstage" source file class, linked into an intermediate library and then linked into the final destination stage. There is no obvious benefit to doing it this way and it's unclear why it was chosen in the first place... there are, however, obvious disadvantages: it can result in code that is used by both libverstage and the host stage to occur twice in the output binary. It also means that libverstage files have their separate compiler flags that are not necessarily aligned with the host stage, which can lead to weird effects like <rules.h> macros not being set the way you would expect. In fact, VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86 because their libverstage code that gets compiled into the romstage sets ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to run pre-migration. This patch resolves these problems by removing the separate library. There is no more difference between the 'verstage' and 'libverstage' classes, and the source files added to them are just treated the same way a bootblock or romstage source files in configurations where the verstage is linked into either of these respective stages (allowing for the normal object code deduplication and causing those files to be compiled with the same flags as the host stage's files). Tested this whole series by booting a Kevin, an Elm (both with and without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode. Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18302 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-28arm64: Fix verstage to use proper assembly versions of mem*()Julius Werner
Due to an unfortunate race between adding verstage support and reverting an earlier hack that disabled the optimized assembly versions of memcpy(), memmove() and memset() on ARM64, it seems that we never enabled the optimized code for the verstage. This should be fixed so that all stages use the same architecture support code. Change-Id: I0bf3245e346105492030f4b133729c4d11bdb3ff Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18976 Tested-by: build bot (Jenkins)
2017-02-24arm-trusted-firmware: Disable a couple of warnings for GCC 6.2Martin Roth
- Remove warnings about code using deprecated declarations such as: plat/mediatek/mt8173/bl31_plat_setup.c: In function 'bl31_platform_setup': plat/mediatek/mt8173/bl31_plat_setup.c:175:2: warning: 'arm_gic_setup' is deprecated [-Wdeprecated-declarations] include/drivers/arm/arm_gic.h:44:6: note: declared here: void arm_gic_setup(void) __deprecated; - Disable pedantic warnings to get rid of these warnings: In file included from plat/mediatek/mt8173/bl31_plat_setup.c:36:0: plat/mediatek/mt8173/include/mcucfg.h:134:21: error: enumerator value for 'MP1_CPUCFG_64BIT' is not an integer constant expression [-Werror=pedantic] MP1_CPUCFG_64BIT = 0xf << MP1_CPUCFG_64BIT_SHIFT Change-Id: Ibf2c4972232b2ad743ba689825cfe8440d63e828 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17995 Tested-by: build bot (Jenkins) Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-01-31build system: mark sub-make invocations as parallelizablePatrick Georgi
We rely on gnu make, so we can expect the jobserver to be around in parallel builds, too. Avoids some make warnings and slightly speeds up the build if those sub-makes are executed (eg for arm-trusted-firmware and vboot). Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/18263 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-11-17arm64: arm_tf: Do not build raw bl31.bin binaryJulius Werner
coreboot's build system picks up the BL31 image as an ELF from the ARM Trusted Firmware submodule and inserts it into CBFS. However, the generic 'bl31' build target we run in the ARM Trusted Firmware build system also generates a raw bl31.bin binary file. We don't need that binary, and with the recently added support for multiple non-contiguous program segments in BL31 it can grow close to 4GB in size (by having one section mapped near the start and one near the end of the address space). To avoid clogging up people's hard drives with 4GB of zeroes, let's only build the target we actually need. BRANCH=gru BUG=chrome-os-partner:56314,chromium:661124 TEST=FEATURES=noclean emerge-kevin coreboot, confirm that there's no giant build/3rdparty/arm-trusted-firmware/bl31.bin file left in the build artifacts, and that we still generate .d prerequisite files. Change-Id: I8e7bd50632f7831cc7b8bec69025822aec5bad27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 31699820f4c36fd441a3e7271871af4e1474129f Original-Change-Id: Iaa073ec11dabed7265620d370fcd01ea8c0c2056 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/407110 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17380 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06arm64: Use 'payload' format for ATF instead of 'stage'Simon Glass
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can have multiple independent segments. This also requires disabling the region check since SRAM is currently faulted by that check. This has been tested with Rockchip's pending change: https://chromium-review.googlesource.com/#/c/368592/3 with the patch mentioned on the bug at #13. BUG=chrome-os-partner:56314 BRANCH=none TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is correct though: CBFS: Locating 'fallback/payload' CBFS: Found @ offset 1b440 size 15a75 Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d Loading segment from ROM address 0x000000000010001c Entry Point 0x0000000018104800 Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d using LZMA [ 0x18104800, 18137d90, 0x192843e0) <- 00100038 Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650 dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1 Jumping to boot code at 0000000018104800(00000000f7eda000) CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes CBFS: 'VBOOT' located CBFS at [402000:44cc00) CBFS: Locating 'fallback/bl31' CBFS: Found @ offset 10ec0 size 8d0c Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192 Loading segment from ROM address 0x000000000010001c code (compression=1) New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26 Loading segment from ROM address 0x0000000000100038 Entry Point 0x0000000000010000 Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 using LZMA [ 0x00010000, 00035708, 0x00050000) <- 00100054 Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8 dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 using LZMA [ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6 dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff Loaded segments INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80 INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364 INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648 NOTICE: BL31: v1.2(debug): NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1189): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x18104800 INFO: SPSR = 0x8 Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376849 Original-Commit-Ready: Simon Glass <sjg@google.com> Original-Tested-by: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16706 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-03build system: remove CBFSTOOL_PRE1_OPTSPatrick Georgi
It isn't used anymore. Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14567 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-03-09Makefile: Add build-time overlap check for programs loaded after corebootJulius Werner
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to statically allocate the different memory regions it needs and guarantees at build time that there are no dangerous overlaps between them. At the end of its (ramstage) execution, however, it usually loads a payload (and possibly other platform-specific components) that is not integrated into the coreboot build system and therefore cannot provide the same overlap guarantees through memlayout.ld. This creates a dangerous memory hazard where a new component could be loaded over memory areas that are still in use by the code-loading ramstage and lead to arbitrary memory corruption bugs. This patch fills this gap in our build-time correctness guarantees by adding the necessary checks as a new intermediate Makefile target on route to assembling the final image. It will parse the memory footprint information of the payload (and other platform-specific post-ramstage components) from CBFS and compare it to a list of memory areas known to be still in use during late ramstage, generating a build failure in case of a possible hazard. BUG=chrome-os-partner:48008 TEST=Built Oak while moving critical regions in the way of BL31 or the payload, observing the desired build-time errors. Built Nyan, Jerry and Falco without issues for good measure. Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13949 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-02-18arch/arm64: Compile arm-trusted-firmware with coreboot timestampPatrick Georgi
Update ATF codebase to a version that supports passing a timestamp and fix the format to what it accepts now (including quotes). This provides reproducible builds. Change-Id: I12a0a2ba1ee7921ad93a3a877ea50309136ab1ab Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13726 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-29arch/arm64: Override bl31 timestamp with coreboot build timestampPatrick Georgi
If coreboot's build process is reproducible (eg. using the latest git timestamp as source), bl31 is, too. This requires an arm-trusted-firmware side merge first (in progress) and an update of our reference commit for the submodule, but it also doesn't hurt anything because it merely sets a variable that currently goes unused. Change-Id: If139538a2fab5b3a70c67f4625aa2596532308f7 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13497 Tested-by: build bot (Jenkins) Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
2016-01-28Makefile: Make full use of src-to-obj macroNico Huber
There were several spots in the tree where the path to a per class object file was hardcoded. To make use of the src-to-obj macro for this, it had to be moved before the inclusion of subdirs. Which is fine, as it doesn't have dependencies beside $(obj). Tested by verifying that the resulting coreboot.rom files didn't change for all of Jenkins' abuild configurations. Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13180 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-22arch/arm64: Extend verstageItamar
Add more code to verstage [pg: split downstream commit into multiple commits] Change-Id: I578a69a1e43aad8c90c3914efd09d556920f728e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2827aa08ff8712c0245a22378f3ddb0ca054255d Original-Change-Id: I94a9ee2c00e25a37a92133f813d0cd11a3503656 Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/292662 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/12612 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-12-01build system: strip quotes from CONFIG_CBFS_PREFIX in a single locationPatrick Georgi
Instead of having to remember to strip the quotes everywhere so that string comparisons (of which there are a few) match up, do it right at the beginning. Fixes building the image with a .config where CONFIG_CBFS_PREFIX contains quotes. Change-Id: I4d63341cd9f0bc5e313883ef7b5ca6486190c124 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12578 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
2015-11-17arm64: tegra132: tegra210: Remove old arm64/stage_entry.SJulius Werner
This patch removes the old arm64/stage_entry.S code that was too specific to the Tegra SoC boot flow, and replaces it with code that hides the peculiarities of switching to a different CPU/arch in ramstage in the Tegra SoC directories. BRANCH=None BUG=None TEST=Built Ryu and Smaug. !!!UNTESTED!!! Change-Id: Ib3a0448b30ac9c7132581464573efd5e86e03698 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12078 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-16arm64: Implement generic stage transitions for non-Tegra SoCsJulius Werner
The existing arm64 architecture code has been developed for the Tegra132 and Tegra210 SoCs, which only start their ARM64 cores in ramstage. It interweaves the stage entry point with code that initializes a CPU (and should not be run again if that CPU already ran a previous stage). It also still contains some vestiges of SMP/secmon support (such as setting up stacks in the BSS instead of using the stage-peristent one from memlayout). This patch splits those functions apart and makes the code layout similar to how things work on ARM32. The default stage_entry() symbol is a no-op wrapper that just calls main() for the current stage, for the normal case where a stage ran on the same core as the last one. It can be overridden by SoC code to support special cases like Tegra. The CPU initialization code is split out into armv8/cpu.S (similar to what arm_init_caches() does for ARM32) and called by the default bootblock entry code. SoCs where a CPU starts up in a later stage can call the same code from a stage_entry() override instead. The Tegra132 and Tegra210 code is not touched by this patch to make it easier to review and validate. A follow-up patch will bring those SoCs in line with the model. BRANCH=None BUG=None TEST=Booted Oak with a single mmu_init()/mmu_enable(). Built Ryu and Smaug. Change-Id: I28302a6ace47e8ab7a736e089f64922cef1a2f93 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12077 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-11-07arm64: Remove cpu intialization through device-treeFurquan Shaikh
Since, SMP support is removed for ARM64, there is no need for CPU initialization to be performed via device-tree. Change-Id: I0534e6a93c7dc8659859eac926d17432d10243aa Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/11913 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-11-07arm64: Remove SMP supportFurquan Shaikh
As ARM Trusted Firmware is the only first class citizen for booting arm64 multi-processor in coreboot remove SMP support. If SoCs want to bring up MP then ATF needs to be ported and integrated. Change-Id: Ife24d53eed9b7a5a5d8c69a64d7a20a55a4163db Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/11909 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-11-07arm64: remove spin table supportAaron Durbin
As ARM Trusted Firmware is the only first class citizen for booting arm64 multi-processor in coreboot remove spintable support. If SoCs want to bring up MP then ATF needs to be ported and integrated. Change-Id: I1f38b8d8b0952eee50cc64440bfd010b1dd0bff4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11908 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-11-07arm64: remove secmonAaron Durbin
It's been decided to only support ARM Trusted Firmware for any EL3 monitor. That means any SoC that requires PSCI needs to add its support for ATF otherwise multi-processor bring up won't work. Change-Id: Ic931dbf5eff8765f4964374910123a197148f0ff Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11897 Tested-by: build bot (Jenkins) Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-11vboot: remove remnants of VBOOT_STUBAaron Durbin
For vboot1 there was an rmodule that was loaded and ran to do the firmware verification. That's no longer used so remove the last vestiges of VBOOT_STUB. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built glados. Change-Id: I6b41544874bef4d84d0f548640114285cad3474e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11817 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-09-09linking: add and use LDFLAGS_commonAaron Durbin
Add an LDFLAGS_common variable and use that for each stage during linking within all the architectures. All the architectures support gc-sections, and as such they should be linking in the same way. BUG=chrome-os-partner:44827 BRANCH=None TEST=Built rambi and analyzed the relocatable ramstage. Change-Id: I41fbded54055455889b297b9e8738db4dda0aad0 Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11522 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Julius Werner <jwerner@chromium.org>
2015-08-31armv7/arm64: remove timestamp.cAaron Durbin
The src/lib/timestamp.c already has an implementation using timer_monotonic_get() for timestamp_get(). Use that instead of duplicating the logic. BUG=chrome-os-partner:44669 BRANCH=None TEST=None Change-Id: If17be86143f217445bd64d67ceee4355fa482d39 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/11468 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2015-08-28arm64: Fix 'verstage-objs: command not found' errorYidi Lin
Fix following compilation error. LINK cbfs/fallback/verstage.debug /bin/sh: verstage-objs: command not found /usr/x86_64-pc-linux-gnu/aarch64-cros-linux-gnu/binutils-bin/2.24/ld.bfd.real: warning: cannot find entry symbol stage_entry; defaulting to 00000000000d7000 BRANCH=chromeos-2015.07 BUG=none TEST=emerge-oak coreboot Change-Id: I30e4c43625b2d1d076f24e8c2639ce951839661b Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Original-Commit-Id: 2a8936cdf34d315f580819df682335b2998f044f Original-Change-Id: I9afd57a5a868a348dff2c66cad0a8a09cdb2e911 Original-Signed-off-by: Yidi Lin <yidi.lin@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/292557 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11402 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-21arm64: Set LOG_LEVEL=0 for BL31 if coreboot does not use serialFurquan Shaikh
Even if DEBUG=0, BL31 puts NOTICE(..) messages on serial console. Set LOG_LEVEL=0 if coreboot does not use serial. BUG=None BRANCH=None TEST=Compiles successfully and no console output from bl31 for production images. Change-Id: Ie77bcac3e2a0d314545b6811327c413536c77fb9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e8e3bcbf6249c80850a87dd66f34d3ff36158641 Original-Change-Id: I1415a3816cd2fa9dd05bcbd36ac0abc3f2759960 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/286150 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/11014 Reviewed-by: Furquan Shaikh <furquan@google.com> Tested-by: build bot (Jenkins)
2015-06-30arch/arm64: Avoid race condition when building bl31Patrick Georgi
The arm-trusted-firmware build system may not create the final bl31.elf file atomically, confusing our make to try to use it before it's ready. Hence insert a (hopefully, but not guaranteed to be atomic) file move. Change-Id: Iffc80467e0f4bbc96fc62414d4abfaa7b42634f4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10700 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-06-30arm64: Add support for loading secure osFurquan Shaikh
Add support for loading secure os and pass its entrypoint as bl32 params to bl31 stage. BUG=chrome-os-partner:40713 BRANCH=None TEST=Compiles successfully and loads secure os Change-Id: I1409ccb7344c1d1b1ddc2b321fdae1beea2f823d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: d3dc19025ff11c1e0590306230df7654ef9ad086 Original-Change-Id: Iafd540bf2906d10b5ee009e96179121fecbf5e11 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/273719 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/10693 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-06-23Revert "arm64: remove assembly code string functions"Furquan Shaikh
This reverts commit 00263d0d8ee23bbe60ea359ea9cb33d551688980 to reintroduce optimized string handling functions. BUG=chrome-os-partner:41185 BRANCH=None TEST=Compiles successfully and boots to kernel prompt on Smaug Change-Id: I47f8d8afa5c9ff3fca67d4d0f393336fef03402b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: eeb38afea828a2727d815e4fb5762cfdd09a2b3a Original-Change-Id: Id053cbcea8b5e7ae29bdd6bb8b6f5e5011c42b00 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/275865 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/10564 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-06-21Remove obsolete EARLY_CONSOLE usageMartin Roth
The EARLY_CONSOLE Kconfig symbol was removed in commit 48713a1b - console: Drop EARLY_CONSOLE option The arm64 and mips directories don't even have early_console.c to include. Change-Id: Idc60ffb2bac2b180f4fdd0adf5c411e1f692a846 Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10615 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-27arm64: Remove PLAT= variable initialization based on Kconfig variableFurquan Shaikh
Each SoC should have a BL31_MAKEARGS += ... defining all the make arguments required for bl31 component compilation. BUG=chrome-os-partner:40414 BRANCH=None TEST=Compiles successfully and boots into bl31. Change-Id: I20383ab61d012f7294d969f196044a5f1c07dfc1 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 72bd297994248a9d96acc6f21d06bb6ff0d5292c Original-Change-Id: I1ddd5c38e9214021d857d9d586310e23fa4114e0 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/272430 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/10309 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Furquan Shaikh <furquan@google.com>
2015-05-27arm64: Pass in CROSS_COMPILE_arm64 for ARM TF compilationFurquan Shaikh
BUG=chrome-os-partner:40414 BRANCH=None TEST=ATF compilation successful Change-Id: Ib4eeced911181f756bd47c19eeb2d196ab5a0a2f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3061a219c24294a9fec4f26fc60b02f67bb55d66 Original-Change-Id: I39849d4048d7333eeab9bd698b4fd496181081a2 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/272374 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/10307 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-20build system: use archives, not linker action to shorten command linesPatrick Georgi
Intermediate linking may distort linker behavior (in particular related to weak symbols). The idea is that archives are closer to 'just a list of object files', and ideally makes the linker more predictable. Using --whole-archive, the linker doesn't optimize out object files just because their symbols were already provided by weak versions. However it shouldn't be used for libgcc, because that one has some unexpected side-effects. Change-Id: Ie226c198a93bcdca2d82c02431c72108a1c6ea60 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10139 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-05-19arm64: Add support for using ARM Trusted Firmware as secure monitorJulius Werner
This patch adds support for integrating the runtime-resident component of ARM Trusted Firmware (github.com/ARM-software/arm-trusted-firmware) called BL31. It expects the ARM TF source tree to be checked out under $(top)/3rdparty/arm-trusted-firmware, which will be set up in a later patch. Also include optional support for VBOOT2 verification (pretty hacky for now, since CBFSv1 is just around the corner and will make all this so much better). BRANCH=None BUG=None TEST=Booted Oak with ARM TF and working PSCI (with additional platform patches). Change-Id: I8c923226135bdf88a9a30a7f5ff163510c35608d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a1b3b2d56b25bfc1f3b2d19bf7876205075a987a Original-Change-Id: I0714cc10b5b10779af53ecbe711ceeb89fb30da2 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/270784 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10249 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-19arm64: Reorganize payload entry code and related KconfigsJulius Werner
Rename Kconfig options for secmon and spintable to be prefixed with ARM64_ instead of ARCH_, which seems to be the standard throughout the rest of coreboot (e.g. ARM_LPAE or X86_BOOTBLOCK_SIMPLE). I think this provides a clearer separation between generic options that are selected by the architecture (e.g. a hypothetical ARCH_HAS_FEATURE_X similar to some of the MAINBOARD_HAS_... we have) and options that only make sense in the context of a single architecture. Change-Id: I38c2efab833f252adbb7b61ef0af60ab25b768b0 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/270783 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10242 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-19arm64: Reorganize payload entry code and related KconfigsJulius Werner
Remove the secmon Kconfig guard from Makefiles that add to the secmon class since they are redundant (the class is simply not used when compiling without secmon) to improve readability/ease-of-use. [pg: taken out of the patch linked below] Change-Id: I2f0ad8a923ca32fcade748ac8ee50c23cf9bafb9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/270783 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10241 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-11arm64: update verstage linkingAaron Durbin
The linker scripts are added to stage objs so remove those from the object lists. boot.c will be needed to link verstage properly. Change-Id: Ib8427fe015b72e2282219f116a39949739a0af48 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10150 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-30vboot: split class in library and stagePatrick Georgi
The build system includes a bunch of files into verstage that also exist in romstage - generic drivers etc. These create link time conflicts when trying to link both the verstage copy and romstage copy together in a combined configuration, so separate "stage" parts (that allow things to run) from "library" parts (that contain the vboot specifics). Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10041 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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-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-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: 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-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-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-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-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-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-03-28arm64: split cpu.cAaron Durbin
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>
2015-03-28arm64: add spin table supportAaron Durbin
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>
2015-03-28arm64: Add support for secure monitorFurquan Shaikh
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>
2015-03-28arm64: Add support for transition libraryFurquan Shaikh
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>
2015-03-17rmodules: Make rmodules inclusion for vboot dependent on romstage_archFurquan Shaikh
Currently, the rmodules inclusion for vboot is dependent on ramstage_arch. This change adds dependency on romstage_arch, since vboot is associated with romstage. Inclusion based on ramstage_arch is left as is in case someone needs it in ramstage. BUG=chrome-os-partner:30784 BRANCH=None TEST=Compiles successfully for link, rush and nyan Original-Change-Id: Ib62415671c26a4a18c7133d98e8c683414def32b Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209568 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 00da67cc02c81d7a6160f7336b33bf53b00e1875) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9df02134af4e396c7257a2db2e2c371cfd1a02bc Reviewed-on: http://review.coreboot.org/8673 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-17coreboot classes: Add dynamic classes to corebootFurquan Shaikh
Provide functionality to create dynamic classes based on program name and the architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class and compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. BUG=chrome-os-partner:30784 BRANCH=None TEST=Compiles successfully for nyan, rush and link. Original-Change-Id: I3e3aadbe723d432b9b3500c44bcff578c98f5643 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/209379 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 242bb90d7476c2ee47d60c50ee18785edeb1a295) Some of this cherry-pick had already been committed here: commit 133096b6dc31163f59f658e15f2eb342a0de2ac6 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I9f5868d704c4b3251ca6f54afa634588108a788c Reviewed-on: http://review.coreboot.org/8672 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-05arm64: provide early SoC initializationAaron Durbin
Some of the SoC's need an early hook to configure certain registers. One example of this is on t132 where ramstage is the first thing being ran on the arm64 core and it is the only entity that can configure certain registers required for the rest of ramstage. Therefore, provide the opportunity for the SoC to implement such requirements. BUG=chrome-os-partner:30572 BRANCH=None TEST=Built and ran through coreboot. Original-Change-Id: Ib352f3788872f888581b398c9b394b7c4e54b02a Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/208061 Original-Reviewed-by: Tom Warren <twarren@nvidia.com> Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 2c50e2b39e75d1383e8e573c576630a5b7313349) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I38df63e46c5c21b2d319fc9eb42053c3a0d61bc8 Reviewed-on: http://review.coreboot.org/8595 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-03-04arm64: remove assembly code string functionsAaron Durbin
Inconsistent progress was observed running ramstage. It was determined that the hand-coded assembly functions were causing issues. Some of the comments seems suspect about the hardware taking care of alignment. The prudent thing to do is to use the C ones. Optimization can come later after maturity. BUG=chrome-os-partner:29923 BRANCH=None TEST=Built and booted to attempting to payload Original-Change-Id: I4137adf9b36b638ed207e4efd57adaac64c6a6c1 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/207431 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 2762e478c6b59dd30c59aa87a922d0f78c00c0c4) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id3196b0c2bf41a21db31f999ba437d118875a236 Reviewed-on: http://review.coreboot.org/8587 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-03-04arm64: use one stage_entry for all stagesAaron Durbin
Ramstage needs an assembly entry point for setting up the initial state of the CPU. Therefore, a function is provided, arm64_el3_startup(), that bootstraps the state of the processor, initializes the stack pointer, and branches to a defined entry symbol. To make this work without adding too much preprocessor macro conditions provide _stack and _estack for all the stages. Currently the entry point after initialization is 'main', however it can be changed/extended to do more work such as seeding the stack contents with tombstones, etc. It should be noted that romstage and bootblock weren't tested. Only ramstage is known to work. BUG=chrome-os-partner:29923 BRANCH=None TEST=Brought up 64-bit ramstage on rush. Original-Change-Id: I1f07d5b6656e13e6667b038cdc1f4be8843d1960 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/207262 Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 7850ee3a7bf48c05f2e64147edb92161f8308f19) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Ia87697f49638c8c249215d441d95f1ec621e0949 Reviewed-on: http://review.coreboot.org/8585 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-26arm64: Prepare ARM64 for buildingMarc Jones
There were a number of issues with the ARM64 build files. This patch ports the following changes from ARMV4/V7 to ARMV8: - make armv8 Kconfig options consistent with armv4/v7 - fix build include issues in boot.c, tables.c, and early_variables.h by matching armv4/v7. Change-Id: I57359a96821d88c50f48dc0bb6ad226cacb0c2ec Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Iacd95d336559c45458784d1da67bde62a0956620 Reviewed-on: http://review.coreboot.org/8236 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-30Unify remaining binutils invocationsPatrick Georgi
No need to pass calls through gcc in one case and directly to binutils in another. Just always call binutils. Change-Id: Icf9660ce40d3c23f96dfab6a73c169ff07d3e42b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7610 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-23coreboot arm64: Add support for arm64 into coreboot frameworkFurquan Shaikh
Add support for enabling different coreboot stages (bootblock, romstage and ramstage) to have arm64 architecture. Most of the files have been copied over from arm/ or arm64-generic work. Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://chromium-review.googlesource.com/197397 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Commit-Queue: Furquan Shaikh <furquan@chromium.org> Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934) This patch is essentially a squash of aarch64 changes made by these patches: d955885 coreboot: Rename coreboot_ram stage to ramstage a492761 cbmem console: Locate the preram console with a symbol instead of a sect 96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3 3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage 25fd2e9 aarch64: Remove CAR definitions from early_variables.h 65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM 9484873 aarch64: Change default exception level to EL2 7a152c3 aarch64: Fix formatting of exception registers dump 6946464 aarch64: Implement basic exception handling c732a9d aarch64/foundation-armv8: Basic bootblock implementation 3bc412c aarch64: Comment out some parts of code to allow build ab5be71 Add initial aarch64 support The ramstage support is the only portion that has been tested on actual hardware. Bootblock and romstage support may require modifications to run on hardware. Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6915 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Furquan Shaikh <furquan@google.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 19:28:33 +0000