summaryrefslogtreecommitdiffstats
path: root/toolchain.inc
Commit message (Collapse)AuthorAgeFilesLines
* Makefiles: Rename top-level Makefiles from .inc to .mkMartin Roth2024-01-241-294/+0
| | | | | | | | | | | | | | | | | | | The .inc suffix is confusing to various tools as it's not specific to Makefiles. This means that editors don't recognize the files, and don't open them with highlighting and any other specific editor functionality. This issue is also seen in the release notes generation script where Makefiles get renamed before running cloc. The rest of the Makefiles will be renamed in following commits. Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Idaf69c6871d0bc1ee5e2e53157b8631c55eb3db9 Reviewed-on: https://review.coreboot.org/c/coreboot/+/80063 Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
* toolchain.inc: Set CCACHE_COMPILERCHECK=mtimeNico Huber2023-07-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | From ccache(1): mtime Hash the compiler’s mtime and size, which is fast. This is the default. Hashing the compiler binary's content would only be necessary when we expect different binaries of the same size with the same path (e.g. during a compiler bootstrap) and wrong modification timestamps (might happen when checking an older version out of a (package) repository). Neither should be the case during our builds. And even if everything fails at once, chances are additionally low that a wrong cache hit would cause a problem. tl;dr we're building and testing firmware, not toolchains. Change-Id: I264a72c628559384fcc2060d777c52af927d5e14 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/76561 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@mailbox.org> Reviewed-by: Martin L Roth <gaumless@gmail.com>
* Append per-board ccache statistics in logKyösti Mälkki2023-06-111-0/+1
| | | | | | | | | | | | | | Starting with ccache 4.4 it is possible to collect statistics about cache miss/hit rates in a separate file. Add the info of the build at end of created make.log file or on stdout. Change-Id: I1bab712712f4d6379ec6733fdc55b234e3845da7 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/75087 Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* coreboot: Add support for include-what-you-useMartin Roth2022-10-111-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | The tool "include-what-you-use" analyzes each file's headers and makes recommendations for header files to add and remove. There are additional scripts as part of the package that will make these changes directly based on the recommendations, but due to the way coreboot compiles code in/out base on Kconfig options, this isn't really safe for the project to use. It is a good starting point though. To use, set the IWYU kconfig option, then build with the command: make -k Because this doesn't actually build any files, the -k option is needed or make will stop after looking at the first file. Signed-off-by: Martin Roth <martin.roth@amd.corp-partner.google.com> Change-Id: I084813f21a3c26cac1e4e134bf8a83eb8637ff63 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67915 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Julius Werner <jwerner@chromium.org>
* build system: immediately report what users are supposed to look intoPatrick Georgi2021-10-181-1/+2
| | | | | | | | | | | Instead of just logging "Check out that file over there for this type of values", why not emit them directly? Change-Id: I54630afce4011ab9ee3eda415e95d5b7d5812e6b Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/57508 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com>
* toolchain.inc: copy architecture specific CFLAGS to GCC_ADAFLAGSIru Cai2021-07-011-0/+7
| | | | | | | | | | | | This fixes building with libgfxinit in x86_64 mode, which can generates unsupported R_X86_64_32S relocations without -mcmodel=large. Change-Id: If5162fae475f3e70c856d9664a8cfc6a89d82283 Signed-off-by: Iru Cai <mytbk920423@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/55549 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* toolchain.inc: Update and fix the test-toolchain targetMartin Roth2021-02-241-10/+30
| | | | | | | | | | | | | | | | | Due to some change, the test-toolchain was no longer working, and was always reporting that the toolchain is out of date. This fixes the failure, and prints both the expected versions of Clang, GCC, and IASL on failures. Additional changes fix some indentation issues and skip trying to update submodules when the test is run. Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: Ia350f279c3fd3533523996327cc6b2304e0bead4 Reviewed-on: https://review.coreboot.org/c/coreboot/+/48903 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
* Remove MAYBE_STATIC_BSS and ENV_STAGE_HAS_BSS_SECTIONKyösti Mälkki2020-05-261-1/+1
| | | | | | | | | | | | | | | | | After removal of CAR_MIGRATION there are no more reasons to carry around ENV_STAGE_HAS_BSS_SECTION=n case. Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit zero-initializers. Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
* treewide: Remove "this file is part of" linesPatrick Georgi2020-05-111-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* treewide: more SPDX header workPatrick Georgi2020-05-091-14/+2
| | | | | | | | | Change-Id: Ib78c322730ec6dfa9dcaafa16e5741cd3d351b8d Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41174 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
* Makefile: Remove romccElyes HAOUAS2019-12-271-2/+0
| | | | | | | | | Change-Id: I2fe7fa8b23da3b909adc2b8bce59304acfb5b807 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37788 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
* Makefiles: Remove -D__PRE_RAM__Kyösti Mälkki2019-11-221-1/+1
| | | | | | | | | | | | 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>
* Remove MIPS architectureJulius Werner2019-11-201-3/+0
| | | | | | | | | | | | | | | | | 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>
* Split MAYBE_STATIC to _BSS and _NONZERO variantsKyösti Mälkki2019-08-261-1/+1
| | | | | | | | | | | | 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>
* Move -Wlogical-op into xcompileNico Huber2019-06-211-1/+1
| | | | | | | | | | | | | 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>
* arch/power8: Rename to ppc64Jonathan Neuschäfer2018-11-301-3/+3
| | | | | | | | | | | | | | | 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>
* Introduce bootblock self-decompressionJulius Werner2018-05-221-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: Always use GCC for Ada sourcesNico Huber2017-09-231-1/+2
| | | | | | | | | | | | | 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>
* toolchain: Use xcompile proposed CFLAGS for AdaNico Huber2017-09-231-1/+1
| | | | | | | | | | | | | | | | 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>
* toolchain.inc: Use -Wstack-usage only on gccPatrick Georgi2017-06-191-0/+2
| | | | | | | | | | | | 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>
* Remove libverstage as separate library and source file classJulius Werner2017-03-281-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add minimal GNAT run time system (RTS)Nico Huber2016-09-191-1/+6
| | | | | | | | | | | | | | | 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>
* Make Ada a first class citizenNico Huber2016-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain.inc: Update 'required toolchain' error textMartin Roth2016-08-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* toolchain.inc: test IASL by version string instead of numberMartin Roth2016-03-041-1/+1
| | | | | | | | | | | | | | 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>
* power8: try to fix toolchain.inc for power8.Ronald G. Minnich2016-02-171-0/+3
| | | | | | | | 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>
* toolchain.inc: Update commentsMartin Roth2016-01-181-7/+13
| | | | | | | | | | | 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>
* toolchain.inc: Fix whitespace issues and wrap long linesMartin Roth2016-01-151-25/+63
| | | | | | | | | 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>
* Makefile: Add toolchain version checkMartin Roth2016-01-121-0/+15
| | | | | | | | | | | | | | | 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)
* toolchain.inc: Test for valid toolchain when ANY_TOOLCHAIN is usedMartin Roth2016-01-061-0/+8
| | | | | | | | | | | 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>
* toolchain.inc: Update help text, Add TODO.Martin Roth2016-01-041-5/+6
| | | | | | | | | | | | - 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>
* toolchain.inc: Skip how to use any toolchain if it's selectedMartin Roth2016-01-041-3/+7
| | | | | | | | | | | 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>
* toolchain.inc: Move nocompile around entire check, Comment endifsMartin Roth2016-01-041-3/+4
| | | | | | | | | | | | | 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>
* toolchain.inc: Test for toolchain when using llvm/clangMartin Roth2016-01-041-4/+4
| | | | | | | | | | 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>
* toolchain.inc: print XGCCPATH if it's setMartin Roth2015-12-161-0/+4
| | | | | | | | | | | 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>
* toolchain.inc: fix typoMartin Roth2015-12-081-1/+1
| | | | | | | | | 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>
* toolchain.inc: verify tool variable validity before using it.Martin Roth2015-12-081-2/+2
| | | | | | | | | | | | | | | | | 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>
* toolchain.inc: Add IASL test as part of coreboot toolchainMartin Roth2015-12-021-0/+7
| | | | | | | | | | | | | | 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>
* toolchain.inc: Improve help messages for coreboot toolchainMartin Roth2015-12-021-2/+8
| | | | | | | | | | | 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>
* rules.h: Add ENV_ macros to detect current architectureJulius Werner2015-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tree: drop last paragraph of GPL copyright headerPatrick Georgi2015-10-311-4/+0
| | | | | | | | | | | | | | | | 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>
* linking: add and use LDFLAGS_commonAaron Durbin2015-09-091-0/+1
| | | | | | | | | | | | | | | | | | 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>
* Move function/data sections to common CFLAGSStefan Reinauer2015-08-091-10/+5
| | | | | | | | | | | | 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>
* arm, arm64, mips: Add rough static stack size checks with -Wstack-usageJulius Werner2015-07-291-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: Add -mgeneral-regs-only to CFLAGS for arm64Furquan Shaikh2015-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* build system / amd64: Avoid GCC taking the ABI spec too literallyPatrick Georgi2015-07-081-1/+1
| | | | | | | | | | | | -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>
* toolchain.inc: Don't overwrite architecture specific CFLAGSStefan Reinauer2015-07-081-5/+5
| | | | | | | | | | | | 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>
* toolchain.inc: Add x86-64 supportStefan Reinauer2015-06-161-1/+4
| | | | | | | | | | | | | 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>
* build system: move compiler runtime determination to xcompilePatrick Georgi2015-06-041-9/+2
| | | | | | | | | | | | 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>
* build system: only query the compiler runtime's location oncePatrick Georgi2015-05-261-2/+2
| | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-26 12:59:30 +0000