summaryrefslogtreecommitdiff
path: root/toolchain.inc
AgeCommit message (Collapse)Author
2019-11-22Makefiles: Remove -D__PRE_RAM__Kyösti Mälkki
All cases of testing for __PRE_RAM__ have been converted to equivalent ENV_xxx definitions from <rules.h>. Change-Id: Ib6cd598f17109cc1072818cebe4791f7410c3428 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37075 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2019-11-20Remove MIPS architectureJulius Werner
The MIPS architecture port has been added 5+ years ago in order to support a Chrome OS project that ended up going nowhere. No other board has used it since and nobody is still willing or has the expertise and hardware to maintain it. We have decided that it has become too much of a mainenance burden and the chance of anyone ever reviving it seems too slim at this point. This patch eliminates all MIPS code and MIPS-specific hacks. Change-Id: I5e49451cd055bbab0a15dcae5f53e0172e6e2ebe Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34919 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-08-26Split MAYBE_STATIC to _BSS and _NONZERO variantsKyösti Mälkki
These are required to cover the absensce of .data and .bss sections in some programs, most notably ARCH_X86 in execute-in-place with cache-as-ram. Change-Id: I80485ebac94b88c5864a949b17ad1dccdfda6a40 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35003 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2019-06-21Move -Wlogical-op into xcompileNico Huber
Clang doesn't know `-Wlogical-op`, so let's move it into xcompile where we can easily distinguish between the two. However, this requires us to split out `GCC_ADAFLAGS*` from `GCC_CFLAGS*`. Change-Id: I6a50de0bc5372f61337f237383d32645ba86b0fd Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33579 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-11-30arch/power8: Rename to ppc64Jonathan Neuschäfer
POWER8 is a specific implementation of ppc64, which is by now outdated (POWER9 has been on the market for a while). Rename arch/power8/ to potentially cover a wider range of hardware. TEST=Toolchains built before/after this commit can build coreboot for emulation/qemu-power8 from before/after this commit. Change-Id: I2d6f08b12a9ffc8a652ddcd6f24ad85ecb33ca52 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/c/29943 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
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-09-23toolchain: Always use GCC for Ada sourcesNico Huber
We can't use $(CC) in case it's set to Clang. TEST=Built one target with Ada sources before and after this change and verified that the same compiler commands are emitted. Change-Id: I9b8ea35352d74b364f09fc12d8d981ca42f8b7c8 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21366 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-09-23toolchain: Use xcompile proposed CFLAGS for AdaNico Huber
We don't output special ADAFLAGS in xcompile but its CFLAGS are compatible with and necessary for Ada too. So use the latter and make sure we use them for libgnat too. Fixes i386 builds with x86_64 toolchain. TEST=Gave libgfxinit a shot on lenovo/t420. Change-Id: I0d13f182acfaa9bd1b608edd8a508c4ceedef3b3 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/21363 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-06-19toolchain.inc: Use -Wstack-usage only on gccPatrick Georgi
clang isn't happy with it Change-Id: I2c22171dedc77df24e739ec26335010f0f443963 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/19657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Edward O'Callaghan <quasisec@google.com> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Martin Roth <martinroth@google.com>
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-09-19Add minimal GNAT run time system (RTS)Nico Huber
Add a stripped-down version of libgnat. This is somehow comparable to libgcc but for Ada programs. It's licensed under GPLv3 but with the runtime library exception. So it's totally fine to link it with our GPLv2 code and keep it under GPLv2. Change-Id: Ie6522abf093f0a516b9ae18ddc69131bd721dc0c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/11836 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-09-19Make Ada a first class citizenNico Huber
Some remarks on the make process: o We usually leave Ada specs (.ads files which are like c headers) together with the bodies (implementations in .adb files) in one directory. So we have to know, where they live. o If there is no matching .adb an .ads is a valid source file and we'll generate an object file from it. o Object files need to have the same basename as their source files :-/ That's why we put them in build/<class>/ dirs now. o We track dependencies by looking at the compiler output (.ali files which accompany every .o). This way we don't need any gnatmake magic, or even more complex, less portable tools. For ADAFLAGS_common, I simply copied the CFLAGS_common whilst dropping everything unsupported and adding sane warning options. The set of language features is highly restricted (see gnat.adc). This should suit the embedded nature of coreboot and helps proving absence of runtime errors with SPARK. Change-Id: I70df9adbd467ecd2dc7c5c1cf418b7765aca4e93 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/13044 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2016-08-04toolchain.inc: Update 'required toolchain' error textMartin Roth
The old text said: *** building <STAGE> without the required toolchain. Stop. Where <STAGE> could be any of the coreboot stages - bootblock, verstage, ramstage, romstage. This error message was very misleading though, because what it actually meant was that it didn't know what architecture was required to build the stage, not that the toolchain was missing. Update the text to better reflect the actual issue, and to give the user a hint as to what to look for: *** The toolchain architecture for <STAGE> is unknown. *** Check your .config file for CONFIG_ARCH_<STAGE>_* settings. Stop. Change-Id: Ic2a4f60c1f25e0f5e1ebde76781bcb8da0987d82 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/16024 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker
2016-03-04toolchain.inc: test IASL by version string instead of numberMartin Roth
Test that the coreboot toolchain version of IASL is being used by looking for the string 'coreboot toolchain' instead of a specific version number. While this may cause people to have to rebuild their toolchains again now, it helps to prevent toolchain failures when bisecting in the future. Change-Id: I9913eeae8f29ddc3ec8c70077c05d898595eb283 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12847 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-17power8: try to fix toolchain.inc for power8.Ronald G. Minnich
Change-Id: Ic249ee89d8683b9ecc020d1ec6934019ae5ae1b6 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/13724 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-18toolchain.inc: Update commentsMartin Roth
This fixes some nits that were pointed out in a previous review, and adds a couple additional comments to explain what is happening. Change-Id: I1ca4bf59ba79744f79fbe73f4e226feeea1cc2ab Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/13019 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-15toolchain.inc: Fix whitespace issues and wrap long linesMartin Roth
Change-Id: Iad4dc0af8af508a7e3eb0d9227b2f7c54511f130 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12889 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-12Makefile: Add toolchain version checkMartin Roth
This is an initial check for the coreboot toolchain versions. It currently checks binutils, gcc, clang, and iasl. The other components are slightly more difficult to test, but should follow on shortly. If the toolchain is not the correct version, make will halt with an error. Change-Id: I41daf6c4545c01dc21231d78fd081bbcf77c4726 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12846 Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Tested-by: build bot (Jenkins)
2016-01-06toolchain.inc: Test for valid toolchain when ANY_TOOLCHAIN is usedMartin Roth
Even when ANY_TOOLCHAIN is selected, a valid compiler for the requested architecture is needed. Change-Id: If1a0a1ca6b726e8e58d29c69de93546510582548 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12681 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-04toolchain.inc: Update help text, Add TODO.Martin Roth
- Update the help text to be more informative. - Add todo about IASL - we shouldn't require it if the build doesn't use it. Change-Id: Iffeb94f78c1ae7535a8a7b9b0b9f1728301a42b3 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12680 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-01-04toolchain.inc: Skip how to use any toolchain if it's selectedMartin Roth
If ANY_TOOLCHAIN is selected, don't bother telling the user how to do what they've already done. Change-Id: I7182d18a91e832aa56638ec64fe8b3b0c38cff7a Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12679 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-01-04toolchain.inc: Move nocompile around entire check, Comment endifsMartin Roth
Move the check for NOCOMPILE flag around the whole block. There's no need to test COMPILERFAIL if NOCOMPILE is set. Comment the endif lines to make it easier to understand. Signed-off-by: Martin Roth <martinroth@google.com> Change-Id: Id7bb5ca13e6bf1cabf4b7b2ff3256b47b966bac1 Reviewed-on: https://review.coreboot.org/12678 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-01-04toolchain.inc: Test for toolchain when using llvm/clangMartin Roth
Change-Id: I45ed5e289f9bfae90d71938243f921588b256e39 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12676 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-16toolchain.inc: print XGCCPATH if it's setMartin Roth
To help a user debug issues, print the current XGCCPATH value if it's set. Change-Id: I69afdd1c93cfd4747547ecad0d5e1ab4c87511b7 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12677 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-08toolchain.inc: fix typoMartin Roth
Change-Id: I6336881f0ec3568e14c03c55c7c060eba9f4be53 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12675 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-12-08toolchain.inc: verify tool variable validity before using it.Martin Roth
If the toolchain for a stage/architecture wasn't present, we'd call the shell with '-v', generating an ugly warning: /bin/sh: - : invalid option Usage: /bin/sh [GNU long option] [option] ... /bin/sh [GNU long option] [option] script-file ... GNU long options: ... Change-Id: Icd6d7a00083ee1695591ff96da36b7868be0c2f0 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12649 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-02toolchain.inc: Add IASL test as part of coreboot toolchainMartin Roth
Even though coreboot has IASL as part of its toolchain, it was not being picked up when testing to make sure coreboot is being compiled with the coreboot toolchain. This patch adds an iasl test when testing coreboot toolchain. Change-Id: I5b989869417c3f60057a91842b911855d9528f1b Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12543 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-12-02toolchain.inc: Improve help messages for coreboot toolchainMartin Roth
Show better help text on how to compile the coreboot toolchain or use an unsupported toolchain. Change-Id: I64a2159d324d673784669b2464c1a2769b048678 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12557 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-11-17rules.h: Add ENV_ macros to detect current architectureJulius Werner
This patch expands the existing ENV_<stage> macros in <rules.h> with a set of ENV_<arch> macros which can be used to detect which architecture the current compilation unit is built for. These are more consistent than compiler-defined macros (like '#ifdef __arm__') and will make it easier to write small, architecture-dependent differences in common code (where we currently often use IS_ENABLED(CONFIG_ARCH_...), which is technically incorrect in a world where every stage can run on a different architecture, and merely kinda happened to work out for now). Also remove a vestigal <arch/rules.h> from ARM64 which was no longer used, and genericise ARM subarchitecture Makefiles a little to make things like __COREBOOT_ARM_ARCH__ available from all file types (including .ld). BUG=None TEST=Compiled Falco, Blaze, Jerry and Smaug. Change-Id: Id51aeb290b5c215c653e42a51919d0838e28621f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/12433 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
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-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-09Move function/data sections to common CFLAGSStefan Reinauer
Instead of adding -ffunction-sections and -fdata-sections to every architecture, just add it to CFLAGS_common, thus making sure that new architectures will pick it up automatically. Change-Id: I38e878851226565b7791d05e222cb4e502e0c8a3 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11105 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-07-29arm, arm64, mips: Add rough static stack size checks with -Wstack-usageJulius Werner
We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-16toolchain: Add -mgeneral-regs-only to CFLAGS for arm64Furquan Shaikh
BUG=None BRANCH=None TEST=Compiles successfully and boots to kernel prompt on smaug Change-Id: I7eb75b215798a63157bae04d9d44dbd6f95a5715 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 6e5ecf9b45fa35e3c87bf6ef4bd2ea01680c8826 Original-Change-Id: I36a20d65d7ccaa21fdeb6070d43c2bb0ae22a16b Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/285553 Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Reviewed-on: http://review.coreboot.org/10959 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-08build system / amd64: Avoid GCC taking the ABI spec too literallyPatrick Georgi
-mno-red-zone is an option that pretty much every barebone software package (eg. kernel, bootloader, ...) needs to use. We weren't hurt by it yet, but make sure we won't in the future. Change-Id: Ide5b63424ec1be5bf7bcade10540190b9871593b Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10852 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-08toolchain.inc: Don't overwrite architecture specific CFLAGSStefan Reinauer
For almost all platforms the CFLAGS_<arch> specified in .xcompile were overwritten by toolchain.inc, effectively breaking the build in different places and in subtle ways. Change-Id: I8e1db0eee7ca417ec56ed2156ae1b0b318e57e81 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/10831 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-16toolchain.inc: Add x86-64 supportStefan Reinauer
For now, share code with x86, and use the "large" code model. Also align the architecture specific CFLAGS in toolchain.inc for cosmetics. Change-Id: Ie84893d3460115802fbd70c28b10e709029c6b4e Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/8690 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-06-04build system: move compiler runtime determination to xcompilePatrick Georgi
Instead of fetching libgcc's location and required compiler flags on every individual build, do it once in xcompile. Change-Id: Ie5832fcb21710c4cf381ba475589d42ce0235f96 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/10425 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-05-26build system: only query the compiler runtime's location oncePatrick Georgi
No need to execute the compiler to figure this out once for each source file (or so). Change-Id: I56bf084f1217b96748296931617e9233f21183d5 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/10294 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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-20riscv: enable function and data sectionsAaron Durbin
Every other arch we support has these options enabled. Enable it to make everything a lot easier in compiling common code. Change-Id: I86205468bbd793fbd377e471a1d32be617af5302 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10258 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> 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-17ARM: Remove -mno-unaligned-accessJulius Werner
We've decided that it is generally okay for coreboot to expect unaligned accesses to work. Trying to find all instances of unaligned access opportunities and working around them in software would be an unsustainable whack-a-mole contest. Instead, architectures and boards need to make sure they conform to this, which on ARM and ARM64 requires setting up paging early in the bootblock. Other architectures (x86, ARM64, MIPS) already generate code in this manner. ARM still had an -mno-unaligned-access flag hanging around that has been copied so many times its initial origin was lost in time (probably U-Boot). Let's remove it for consistency between architectures and to improve code generation. BRANCH=veyron BUG=None TEST=Booted Jerry and Blaze. Looked at the disassembly for timestamp_sync() and confirmed that it only gives you half as much eye cancer as before (GCC still somehow insists on byte accesses when zeroing fields which is very odd, but at least that terrible AND/OR mess is gone). Measured a boot time increase of about 11ms on Jerry (mostly faster timestamp and CBFS accesses). Could not test Storm because despite our claimed abundance of test devices, every time I get one of them it magically disappears again in less than a week. Change-Id: I8fc08cc7ce4471651a51ee795269909ef69277c8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 07591fadb89bd127fe065abf0b9ba3facecf1aeb Original-Change-Id: I1d046e05bb11822b86e467eafb6aa92e8fbce774 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/241732 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9728 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-03-29mips: mips, not mipselPatrick Georgi
Change-Id: I49df089d3fd5f578702dcc32be08bf6245277a45 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9149 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2015-03-27toolchain: fix build with x86_64 gccGerd Hoffmann
Commit f69a99db (coreboot: x86: enable gc-sections) overrides CFLAGS_x86_32, which looses (among other things) -m32, which in turn breaks the build with the standard distro gcc on a x86_64 machine. Fix it by appending the new flags instead. Change-Id: Ic3409a1aaa5b26139847258a7eb5c3468efdc6a3 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-on: http://review.coreboot.org/9053 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-26build system: Test gccs that are actually usedPatrick Georgi
Test that the compilers used for the target are built by our buildgcc utility. Users can override this test with the ANY_TOOLCHAIN Kconfig variable. Change-Id: I24adf2c9b83667fd34ce8eb103327c9376765f6d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/9055 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-23console: Allow bootblock console on MIPSPaul Burton
In addition to ARM based systems, allow MIPS based systems to select bootblock console support. BUG=chrome-os-partner:31438 TEST=none yet Change-Id: I40e5d8b651102709118878a317f7e983a617f433 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1a41853273ef9ae716d5645379fcef79c5771b87 Original-Change-Id: I41f03ea8c8104ba2dd9f532b084696385d29636c Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/207973 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org> Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/8769 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21arch/mips: Add base MIPS architecture supportPaul Burton
Add the build infrastructure and basic architectural support required to build for targets using the MIPS architecture. This is sufficient to run on a simulator, but will require the addition of some cache maintenance and timer setup in order to run on real hardware. BUG=chrome-os-partner:31438, chromium:409082 TEST=none yet Change-Id: I027902d8408e419b626d0aab7768bc564bd49047 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: fcc0d934d7223922c878b1f87021cb5c2d7e6f21 Original-Change-Id: If4f99554463bd3760fc142477440326fd16c67cc Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com> Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/207972 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8760 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-17coreboot: x86: enable gc-sectionsAaron Durbin
Garbage collected sections allow for trimming the size of the binaries as well as allowing for not needing to config off unused functions. To that end, on a rambi build the following differences are observed: $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/ramstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/ramstage.elf) --- /dev/fd/63 2015-03-10 12:07:27.927985430 -0500 +++ /dev/fd/62 2015-03-10 12:07:27.927985430 -0500 @@ -6,9 +6,9 @@ There are 4 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x001000 0x00000000 0x00000000 0x00040 0x00040 RWE 0 - LOAD 0x001040 0x00000040 0x00000040 0x34560 0x34560 RWE 0 - LOAD 0x0355a0 0x000345a0 0x000345a0 0x02578 0x02578 RWE 0 - LOAD 0x037b18 0x00036b18 0x00036b18 0x00000 0x0b560 0 + LOAD 0x001040 0x00000040 0x00000040 0x2cbf8 0x2cbf8 RWE 0 + LOAD 0x02dc38 0x0002cc38 0x0002cc38 0x02208 0x02208 RWE 0 + LOAD 0x02fe40 0x0002ee40 0x0002ee40 0x00000 0x0a888 0 Section to Segment mapping: Segment Sections... $ diff -up \ <(readelf -l coreboot-builds/google_rambi/cbfs/fallback/romstage.elf) \ <(readelf -l coreboot-builds/google_rambi_gc_sections/cbfs/fallback/romstage.elf) --- /dev/fd/63 2015-03-10 12:08:16.855985880 -0500 +++ /dev/fd/62 2015-03-10 12:08:16.851985880 -0500 @@ -5,8 +5,8 @@ There are 1 program headers, starting at Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align - LOAD 0x000060 0xfff20000 0xfff20000 0x08b81 0x08b81 R E 0x10 + LOAD 0x000060 0xfff20000 0xfff20000 0x06300 0x06300 R E 0x10 Section to Segment mapping: Segment Sections... - 00 .rom .text + 00 .rom The following warnings needed to be applied to CFLAGS_common because for some reason gcc was miraculously emitting the warnings with the unrelated *-sections options: -Wno-unused-but-set-variable Change-Id: I210784fdfc273ce4cb9927352cbd5a51be3c6929 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/8635 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-02-24build: mipsel cross compiler supportPaul Burton
This patch introduces support for building a MIPS cross compiler targetting little endian machines by default. Original-Change-Id: I116f6f431cdf80f5f5f58d2743357a9f70a7347d Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/207970 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit d6c9603c41b3d11400cee7b5b409203af0632aa2) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I543cd2276d2f63ed2036a1c1259c9a07cb8a4ba8 Reviewed-on: http://review.coreboot.org/8518 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>