summaryrefslogtreecommitdiff
path: root/src/arch/arm/Makefile.inc
AgeCommit message (Collapse)Author
2019-08-26AUTHORS: Move src/arch/arm copyrights into AUTHORS fileMartin Roth
As discussed on the mailing list and voted upon, the coreboot project is going to move the majority of copyrights out of the headers and into an AUTHORS file. This will happen a bit at a time, as we'll be unifying license headers at the same time. Additional changes in this patch: - Make sure files say that they're part of the coreboot project - Move descriptions below the license header - Fix some spacing Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Id5f26a73f0df366651c076a94975bce1fb321b70 Reviewed-on: https://review.coreboot.org/c/coreboot/+/34605 Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-22Introduce bootblock self-decompressionJulius Werner
Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@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>
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-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>
2015-12-02build system: Add more files through cbfs-files instead of manual rulesPatrick Georgi
verstage, romstage, and payload can be added through infrastructure now. Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/12549 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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-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-11arm: 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. Lastly, VERSTAGE_LIB has no value so remove it. Change-Id: Ie53b42c4995a96006463ec5b358aa43a731cb1b8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10149 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-30arch/arm: only include subdirectories for ARM buildsPatrick Georgi
Change-Id: Ieac02fcc4508f7c1b194802453d6222b902a38a2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10032 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-04-28arm: guard verstage rulesAaron Durbin
Do not unconditially supply verstage rules for all platforms. Change-Id: Ic0713350aa21a9966fca828211750d25c2b6b71d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9969 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-28arch/arm: Move inclusion of timestamps.c to the right directoryPatrick Georgi
Without this, building with COLLECT_TIMESTAMPS fails. Fixes a mistake during upstreaming in commit 0de8820. Change-Id: Ie56bd38649a821f6b22a1e5dee5f50ef397035fe Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10002 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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-08arm: Add timestamp.c to bootblock and verstageFurquan Shaikh
BUG=chrome-os-partner:32973 BRANCH=None TEST=cbmem -t and verified timestamps on ryu Change-Id: Ia2d4d88c5230702319c5651641d8a1a3cc5128b5 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: a227beb4dd4de8c9e6188a62a3b92ba4eeded80c Original-Change-Id: I4687c2ffe77dcc93d0853de32c8492c7b4d1dbb0 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/223346 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/9344 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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-04-02arm: Prevent compilation of old, experimental SMP supportJulius Werner
The ARM SMP feature was added a long time ago and has never really been used by anyone since. We are still always compiling cpu_info() even though we don't use it, and it makes some dangerous assumptions about stack alignment that are not guaranteed anywhere. I'm planning to change the way the stack boundaries are defined. Rather than trying to work that into this unsafe, unused and hard to test feature, I think we should just seal it off with police tape and make sure that if anyone ever tries to use it again (which currently seems unlikely), they get forced to do their due diligence on making sure it works as intended. BUG=None TEST=Compiled Veyron_Pinky. Change-Id: Id25545cab88f29200c7672ef02c7804f0ac26399 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 5b517fc46b030a6e50ef2f5e4d4a449b98ce16c6 Original-Change-Id: I8a60bd30e8b27a22bb3da68ca84daea99424dee9 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/219680 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9222 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-24vboot2: separate verstage from bootblockDaisuke Nojiri
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over the bootblock, then exits to the romstage. this is necessary for some SOC (e.g. tegra124) which runs the bootblock on a different architecture. With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock. Then, the bootblock loads the romstage over the verstage and exits to the romstage. this is probably necessary for some SOC (e.g. rockchip) which does not have SRAM big enough to fit the verstage and the romstage at the same time. BUG=none TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze. BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544 Original-Reviewed-on: https://chromium-review.googlesource.com/212365 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Note: This purposefully is probably broken in vendorcode/google/chromeos as I'm just trying to set a base for dropping more patches in. The vboot paths will have to change from how they are currently constructed. (cherry picked from commit 4fa17395113d86445660091413ecb005485f8014) Signed-off-by: Aaron Durbin <adurbin@chromium.org> Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9 Reviewed-on: http://review.coreboot.org/8881 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-02coreboot arm: Define function for setting cntfrq registerFurquan Shaikh
Define functions for setting cntfrq register in arm and arm64 arch. This allows SoCs to set this register independently of the architecture being used. BUG=None BRANCH=None TEST=Compiles successfully for nyan and rush Original-Change-Id: I93240419b2c012eee29a408deff34a42af943a63 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/205580 Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 768463fef5d630dec915aa0b95e7724d4a6f74b6) armv8: GPL license armv8 lib BUG=None BRANCH=None TEST=Compiles successfully. Original-Change-Id: Ibe0f09ef6704ad808cc482ffec27a4db32d7f6fd Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/250950 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> (cherry picked from commit bc115869bb0bcedbc284677ca5743b9ab40bfc7e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I298c3e76cb52f0876bce3dd4f54d875f62e9310a Reviewed-on: http://review.coreboot.org/8468 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27vboot2: implement select_firmware for pre-romstage verificationDaisuke Nojiri
This patch has a basic structure of vboot2 integration. It supports only Nyans, which have bootblock architecture and romstage architecture are compatible from linker's perspective. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa Original-Reviewed-on: https://chromium-review.googlesource.com/204522 Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org> Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org> (cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001 Reviewed-on: http://review.coreboot.org/8160 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2015-01-27vboot2: add verstageStefan Reinauer
This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e and fixes the build issue that cuased it to be reverted. Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf Reviewed-on: http://review.coreboot.org/8224 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-14Revert "vboot2: add verstage"Paul Menzel
This reverts commit 320647abdad1ea6cdceb834933507677020ea388, because it introduced the following regression. $ LANG=C make V=1 Warning: no suitable GCC for arm. Warning: no suitable GCC for aarch64. Warning: no suitable GCC for riscv. /bin/sh: --: invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: --debug --debugger --dump-po-strings --dump-strings --help --init-file --login --noediting --noprofile --norc --posix --rcfile --restricted --verbose --version Shell options: -ilrsD or -c command or -O shopt_option (invocation only) -abefhkmnptuvxBCHP or -o option make: -print-libgcc-file-name: Command not found It also introduced trailing whitespace. Change-Id: I50ec00a38e24c854fa926357cd24f9286bf4f66f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/8223 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2015-01-13vboot2: add verstageDaisuke Nojiri
Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I42b2b3854a24ef6cda2316eb741ca379f41516e0 Reviewed-on: http://review.coreboot.org/8159 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
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-11-09arm: Thumb ALL the things!Julius Werner
This patch switches every last part of Coreboot on ARM over to Thumb mode: libpayload, the internal libgcc, and assorted assembly files. In combination with the respective depthcharge patch, this will switch to Thumb mode right after the entry point of the bootblock and not switch back to ARM until the final assembly stub that jumps to the kernel. The required changes to make this work include some new headers and Makefile flags to handle assembly files (using the unified syntax and the same helper macros as Linux), modifying our custom-written libgcc code for 64-bit division to support Thumb (removing some stale old files that were never really used for clarity), and flipping the general CFLAGS to Thumb (some more cleanup there as well while I'm at it). BUG=None TEST=Snow and Nyan still boot. Original-Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/182212 Original-Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 5f65c17cbfae165a95354146ae79e06c512c2c5a) Conflicts: payloads/libpayload/include/arm/arch/asm.h src/arch/arm/Makefile.inc src/arch/arm/armv7/Makefile.inc *** There is an issue with what to do with ramstage-S-ccopts, and *** will need to be covered in additional ARM cleanup patches. Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/6930 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-05ARM: Use local versions of libgcc functions instead of linking against libgcc.Gabe Black
The flags used to compile libgcc may make it incompatible with the code it's linked against, and/or the hardware it's going to run on. Rather than try to tease the right libgcc from the compiler, lets just leave it out and use our own implementations of the necessary functions. Most of these implementations were taken from the Linux kernel, except for uldivmod.S which was taken from a CL originally written for U-Boot by Che-Liang Chiou in December of 2010. It was modified to not use the CLZ instruction on machines that don't have it, anything earlier than ARMv5. The top block was taken from an earlier version of the same CL which didn't use CLZ in that spot. The later block was written from scratch. BUG=None TEST=Built and booted into the bootblock on nyan. Ran a series of tests which divided and modded a 64 bit value by various 32 bit values which were powers of 2. Confirmed that this function was used and that the returned value was correct. Printed decimal and hex versions of some values and verified that they equaled each other. Built and booted on pit with serial enabled. BRANCH=None Original-Change-Id: I7527e28af411b7aa7f94579be95a6b352a91a224 Original-Signed-off-by: Gabe Black <gabeblack@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/172401 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Commit-Queue: Gabe Black <gabeblack@chromium.org> Original-Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit be8c7a8f3292a7d7651b7c6dafc9a2c53afbd402) *** This second patch is cherry-picked and squashed again to *** pick up the libgcc changes that were skipped previously. arm: Move libgcc assembly macros to arch/asm.h libgcc/macros.h contains some useful assembly macros that are common in Linux kernel code and facilitate things such as unified ARM/THUMB assembly. This patch moves it to a more general place where it can be used by other code as well. BUG=None TEST=Snow still boots. Original-Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/182178 Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit a780670def94a969829811fa8cf257f12b88f085) *** Additional changes for stage specific builds Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Ie3e48f34ebf6fbe20c3dd76ecbcbea7844e9466e Reviewed-on: http://review.coreboot.org/7322 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-24arm: add missing gc-sections for ramstageIsaac Christensen
This is a fix up for recent patch: c505837 arm: Have the linker garbage-collect unused functions and variables I missed adding --gc-sections to a couple of the ramstage lines. Change-Id: I81178eb99fddbd99c603c79ba506db51af975b27 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6956 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-09-22arm: Have the linker garbage-collect unused functions and variablesJulius Werner
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>
2014-09-12arm: Remove some pointless CFLAGSJulius Werner
This patch removes the -ffixed-r8 CFLAG from the coreboot and libpayload Makefiles. This seems to be a relic from U-Boot, which uses that register to keep it's global data structure pointer. There's no reason for us to throw away a perfectly fine register on this already pretty constrained architecture. Also removed a config.h inclusion from the Makefile because that should really be done inside the C files. Change-Id: Ia176c0f323c1be07cddf88fa5488788786a27cdf Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/177110 Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 2a81112abde284ba09020db6afa363169911a7f6) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6880 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-09ARM: Add an ARMv4 architecture version.Gabe Black
This is needed for the tegra124's bootblock and includes enough implementation to support that use. No caching is supported, although there are function prototypes and stub implementations to satisfy includes and linking. Change-Id: Ib79dde8c30eda98b3e823cba2ff6115a610bb2e8 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171401 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 221dc76b3ce4c1d73851c432333e091e1c60f0cb) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6783 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-08ARM: Generalize armv7 as arm.Gabe Black
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)