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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 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>
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>
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
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>
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>
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)
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-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>
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>
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>
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>
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>
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>
Nico Huber