path: root/src/arch/arm/ramstage.ld
Commit message (Collapse)AuthorAgeFilesLines
* New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner2015-04-061-134/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* build system: run linker scripts through the preprocessorPatrick Georgi2015-04-061-3/+0
| | | | | | | | | | | | | | | | 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>
* bootstate: use structure pointers for scheduling callbacksAaron Durbin2015-03-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | The GCC 4.9.2 update showed that the boot_state_init_entry structures were being padded and assumed to be aligned in to an increased size. The bootstate scheduler for static entries, boot_state_schedule_static_entries(), was then calculating the wrong values within the array. To fix this just use a pointer to the boot_state_init_entry structure that needs to be scheduled. In addition to the previous issue noted above, the .bs_init section was sitting in the read only portion of the image while the fields within it need to be writable. Also, the boot_state_schedule_static_entries() was using symbol comparison to terminate a loop which in C can lead the compiler to always evaluate the loop at least once since the language spec indicates no 2 symbols can be the same value. Change-Id: I6dc5331c2979d508dde3cd5c3332903d40d8048b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8699 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* arm: Have the linker garbage-collect unused functions and variablesJulius Werner2014-09-221-9/+11
| | | | | | | | | | | | | | | | | | | | This patch activates -ffunction-sections and -fdata-sections for the compiler and --gc-sections for the linker. This will strip out all unused functions and static/global variables from the final binaries and reduce the amount of data we need to read over SPI. A quick test with ToT images shows a 2.5k (13%) / 10k (29%) / 12k (28%) reduction on Nyan and 3k (38%) / 23k (50%) / 13k (29%) on Pit, respectively for bootblock / romstage / ramstage. Change-Id: I052411d4ad190d0395921ac4d4677341fb91568a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177111 (cherry picked from commit 5635b138778dea67a5f179e13003132be07f7e59) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6904 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
* ARM: Generalize armv7 as arm.Gabe Black2014-09-081-0/+134
There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)