The header is now created before the "converters" are run.
Adding new capabilities (and fields to the header) will happen there,
so we're close.
Change-Id: I0556df724bd93816b435efff7d931293dbed918f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11326
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These functions can do all kinds of things, such as converting an ELF
image into SELF, or (in the future) compress or checksum entire files.
This may require changing or adding fields to the header, so they
need to have access to it.
The header_size parameter that was provided (but never used) is
equivalent to cbfs_file's offset field.
Change-Id: I7c10ab15f3dff4412461103e9763a1d78b7be7bb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11325
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's sole use was comparing it to the header's "len" field.
Change-Id: Ic3657a709dee0d2b9288373757345a1a56124f37
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11324
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
->len used to be set to the file data length plus the size of the
padding used for the cbfs_file header. This isn't the case anymore,
so no patching of this field is necessary anymore.
->offset still needs to be patched in that case because its final
value can only be determined when the file's actual location is known.
Change-Id: I1037885f81b4ed3b68898dd7d0e515cf7a9c90a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11322
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now cbfstool creates the cbfs_file header at the latest possible
time, which is unsuitable when the idea is to add further fields to it
that need to be configured earlier.
Thus, have it ripple up the call chain.
Change-Id: I7c160681c31818bc550ed2098008146043d0ee01
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
"target", for what? It's the offset where the file header of the currently
added file will be located, name it as such.
Change-Id: I382f08f81991faf660e217566849773d9a7ec227
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Refactor the code to be better understandable.
Change-Id: Ia815a27f7cc83c226a32e87485d712a5fbf4168e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11318
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In testing other localization changes, I found that I couldn't build
anymore because xcompile wasn't picking up my toolchain. I traced it
to the regex comparison of '.*format \(.[a-z0-9-]*\)' to the string
'formato del fichero elf32-i386'. Forcing the localization of
objdump to C before doing the comparison fixes the issue.
Change-Id: I6bed5a9824807dd5bc5a38b711ab47e2af4b0c29
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11304
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
There doesn't seem to have been an olddefconfig target in the coreboot
version of the Kconfig makefile. It's listed in the .PHONY, but it
doesn't seem like it's ever been there. This is useful for expanding
a miniconfig saved with 'make savedefconfig'.
Change-Id: I3798f8469135b58d32da68d4b0e434ab5351b501
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11273
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some patch implementations (eg. BSD) create new files by taking the "---" file
name instead of the "+++" one, so set both to the file name that is to be
created.
Change-Id: I6f37748b4cf0852d292f8f5156fc27ab8fd481b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reported-by: Idwer Vollering <vidwer@gmail.com>
Reported-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/11303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It still needs to pass --32 (yes, 32) to the assembler.
x86_64-linux does this (through some other config file),
x86_64-elf did not.
This fixes building SeaBIOS with our x86_64-elf multilib compiler.
Change-Id: Ibe2a70e46e64e71c947482be5ec0eaf7f7bf300d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11289
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All compilers built, incl. x86_64-elf as multilib and riscv-elf.
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69372
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10975
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The get_region() function was using fixed masks for
the base and limit. However, newer descriptors (on
skylake, e.g.) use a 15-bit mask -- not a 12-bit one.
Choose the right mask based on ifd_version.
BUG=chrome-os-partner:43461
BRANCH=None
TEST=Built glados bootimage.
Original-Change-Id: Ibcbfd649a561d36b17ea2cc8fbeb30ffdbbb2c96
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293250
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7f2ef9fb8e5b6c7114225fecc2798668d6507ac3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11229
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The descriptor format has changed with Skylake and some fields have
moved or been expanded.
This includes new SPI frequencies and chip densities, though unfortunately
30MHz in the new format conflicts with 50MHz in the old format...
There are also new regions with a few reserved regions inserted before
a new embedded controller region.
Unfortunately there does not seem to be a documented version field
so there does not seem to be an official way to determine if a
specific descriptor is new or old. To work around this ifdtool
checks the hardcoded "SPI Read Frequency" to see if it set for
20MHz (old descriptor) or 17MHz (new descriptor).
BUG=chrome-os-partner:40635
BUG=chrome-os-partner:43461
BRANCH=none
TEST=run ifdtool on skylake and broadwell images
Original-Change-Id: I0561b3c65fcb3e77c0a24be58b01db9b3a36e5a9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/281001
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9a08c26432e13c4000afc50de9d8473e6f911805
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293240
Reviewed-on: http://review.coreboot.org/11228
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display the total accumulated time using each timestamp
entry. It purposefully doesn't take into account the first
timestamp because that can be a platform dependent value
that may not contribute to the concept of "total".
BUG=None
BRANCH=None
TEST=Ran cbmem on glados where TSC doesn't reset to 0 on
reboots. Clear total value given at end.
Original-Change-Id: Idddb8b88d3aaad11d72c58b18e8fd9fd1447a30e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291480
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: I79a0954d3b738323aaebb3e05171bcf639e5d977
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11202
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After the preparation in earlier commits, it is now possible to handle the
more general case of position independent files using the special code path
for fixed location files.
This leads to a single place where non-empty cbfs file headers are actually
written into the image, allowing us to move it up the chain more easily.
Change-Id: I8c1fca5e4e81c20971b2960c87690e982aa3e274
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11222
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
... and the assert is gone.
The actual action of adding a just-right file can be moved after the tests
since it's exactly the condition those tests don't continue or break on.
Change-Id: I6d0e829e0158198301136ada9a0de2f168ceee3f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11221
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The assert() makes sure the if() holds true. But that assert won't survive for
long.
Change-Id: Iab7d2bc7bfebb3f3b3ce70dc5bd041902e14bd7a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11220
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We will want to create headers that live outside the final image at some point
(eg. to build the file before we even know where to place it).
Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11219
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pass the file type into it instead of creating an entry, then modifying the
header field again after the fact.
Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11218
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If an earlier stage built a larger header, cbfs_add_entry_at() shouldn't
decide to go with the most boring, least featureful header type (and its size)
instead.
Change-Id: Icc5dcd9a797a0f3c42f91cddd21b3b3916095b63
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The idea is that they can at some point add extended attributes to the header.
That also needs to be passed, but let's start simple.
Change-Id: I80359843078b149ac433ee3d739ea192592e16e7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It will at some point create the header, and pass it with its size. We can
start with the size already.
Change-Id: I8f26b2335ffab99a664d1ff7bc88e33ed62cf9ca
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11215
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Headers vary in size soon, and more places need to be able to calculate their
size.
Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11214
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is in preparation of creating the cbfs_file header much earlier
in the process. For now, size is enough because lots of things need to
move before it makes sense to deal with cbfs_file at a higher level.
Change-Id: I47589247c3011cb828170eaa10ef4a1e0f85ab84
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to read the file before bailing out.
Change-Id: Ida7226c6ec227e1105724cdb1e5a0927217a69c7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11212
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a generic structure, not unlike the cbtables design, based on which we
can build specialized TLV data structures.
Change-Id: I98a75eef19f049ad67d46cdc2790949dcd155797
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Add -P|--package to build iasl
2. Remove -G|--skip-gdb, which was to skip gdb.
3. Add -S|--scripting to build gdb
4. Remove -C|--clang, which was to build clang.
All these changes are aligned with the options parsing below.
The help text is correct.
Change-Id: I897ea5e8ab002086e45bf05ff33230815b246057
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11158
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The script is pretty linux specific as-is, but more portability won't hurt.
Change-Id: I33e18606bea4e23043d748e3fe66a345e720d389
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11151
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
libpayload is calling the xcompile script from payloads/libpayload, so the
script never finds the path on its own and has to be fed the right XGCCPATH by
hand.
This makes xcompile look for the parent path too, so that it can find the
crossgcc toolchains when called from libpayload.
Change-Id: Icc41bb68e3a43810f40f03ab1eb08af07a50a3de
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The test failed to trigger because top wasn't set.
Change-Id: I96de16a1b5cbc5a64d8e65ed84fd6849dd618e8f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11147
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes the botched fix in commit d9bc2fadc4
Change-Id: I0c4445af2851bc80fabb631864321a56123ce7b0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11146
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Otherwise the later processing may fail. Keep minimized version as
config.short.txt for the user's benefit.
Change-Id: I1082ff68de85027d526266cdbf2073d22ce7f2e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10525
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Otherwise there may be a filesystem boundary that breaks make oldconfig.
Change-Id: I1eb55bcabc3e1b834d54f3da9fadfc352f0c4a65
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11150
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is basically a -Werror mode for Kconfig. When exporting
KCONFIG_STRICT in the Makefile, warnings in Kconfig will produce
errors instead.
This will make it easier to spot unclean Kconfig files, settings
and dependencies.
Change-Id: I941af24c3ccb10b8b9ddc5c98327154749ebbbc6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10977
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is to trick libreboot into not deleting misc.c when checking
out coreboot.
Change-Id: I8f0bb5cb3eb5681f99c616ae03de126efab852a9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11134
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
oldconfig may wait for some input. Since we don't care while building tools,
just provide something.
Change-Id: I1c6f1b46957301886a7645cfb6c6bd264437aa7e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11094
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This will allow building and reporting both in one pass.
Change-Id: Id7dbe63c7628cb97d9cf190c151bf23c7b264a89
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11093
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This simplifies editing.
Change-Id: Iff7f0cb7e52788836adcc0813a7bfb6d69009eed
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11091
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Similar to what the below change says,
(
http://review.coreboot.org/10792
commit ddb8f80894
Author: Patrick Georgi <patrick@georgi-clan.de>
Date: Sat Jul 4 17:45:54 2015 +0200
buildgcc: Deal with gmp on 32bit Linux on 64bit CPUs
GMP is overeager to detect 64bit ABIs even if the entire running codebase is
32bit (but on a 64bit CPU). Enforce a 32bit build in that situation.
)
building GMP can not detect Cygwin is 32bit either if the
host which Cygwin is running is 64bit. We set ABI=32
in that case.
Change-Id: Ic53d75defebbe902325eb07f3d8631b2a53245ef
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11123
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Running `uname` on Cygwin gets "CYGWIN_NT-6.1-WOW" instead of "Cygwin".
We need to fix the $UNAME on Cygwin.
Change-Id: I540bfc52089951006fd0e20bb9893a3d891df9e1
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11124
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
secimage does not use libgmp, so don't link it in.
(Otherwise linking fails if the library is not installed)
Change-Id: I24af21c7754ecd0109f3e86669fa34fa6991d7fe
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11079
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It doesn't know "source", but wants the older "." instead
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69374
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10974
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The code for removing a file had its own merge routine. Use the generic one
instead.
Change-Id: I90ed007ab86f78a2728f529fa0143c5c1dfbbdc3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10967
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So far it's still unused, but its purpose will change:
It will become an offset to another structure that contains additional file
attributes.
This change is compatible because the binary format doesn't change and so far
the field was always set to 0, which can serve nicely as 'unused' field.
Change-Id: I2dafb06866713d43a236556f9492641526270837
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables running the checkpatch script on the code portion
of each commit as part of the pre-commit hook. At this point there
is no checking of the commit message in place (e.g. for typos)
Change-Id: I7cdf0692cf372986e411f4aba4691417b73c7511
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8419
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Trailing commas are useful for lists that can be extended. These lists are
0-terminated, and there should be no elements following that.
Change-Id: Iea8c6d5579d6363e77e1f5af666948160c4a9bf9
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10932
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Parse compression algorithm arguments using a single list.
Change-Id: Idc5b14a53377b29964f24221e42db6e09a497d48
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With introducing hash algorithms, 'algo' is ambiguous, so rename it to
'compression' instead.
Change-Id: Ief3d39067df650d03030b5ca9e8677861ce682ed
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10930
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Lock down its size and document some of the fields
Change-Id: I09fd6c80185345da0ae17d0f4498b50995fd1ec5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10927
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It's not like we _ever_ changed it, so drop the option and make cbfstool
use the default. always.
Change-Id: Ia1b99fda03d5852137a362422e979f4a4dffc5ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's helpful to know the base_time (1st timestamp) in the
timestamp table because it provides more information like
the accumulated time before the first timestamp was recorded.
In order to maximize this information report the base time
as an entry that is printed. It's called '1st timestamp'.
The implementation turns all the timestamp entries into absolute
times so one can observe both absolute and relative time for
each marker.
Change-Id: I1334a2d980e3bcc2968a3bd6493c68b9efcca7ae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10883
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There may be boards that shouldn't be built for one reason or another.
Allow black-listing them by adding a file to the mainboard directory called
'abuild.disabled'. It should contain the reason that is printed by abuild and
also serves as documentation for users that want to know what's going on.
Change-Id: I78c3281a578e96ee40f6b101143d4f3763582350
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10917
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In case of downloading errors, the URL is handy for analyzing the cause.
Change-Id: I6874cdc3c881cfdd52c80f80323536c30723654b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10853
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
The script `util/crossgcc/buildgcc` was rewritten in commit 85b07d68
(buildgcc: move to a package centric user interface) and the switches
changed. This patch does the following:
- IASL was split out of the gcc builds, so needs a target of its own.
- Add clang build target
- Update the build-ARCH targets as buildgcc -G no longer builds gcc.
- Rework all the targets to use common targets to call buildgcc
- Split the tempfile clean from the regular clean
- Change the 'all' target to leave the tempfiles until all architectures
are built so that if one fails and needs a rebuild, it doesn't have to
start from scratch.
- Add an all_without_gdb target
- Add clang build to all
Change-Id: I4ff720eab6d9b72d00757fd2b632e6d9a6c25aa3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10679
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
rmodule.c: In function ‘rmodule_create’:
rmodule.c:287:29: error: ‘phdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
(phdr->p_vaddr + phdr->p_memsz))) {
^
rmodule.c:204:14: note: ‘phdr’ was declared here
Elf64_Phdr *phdr;
^
Change-Id: I94a235253610348484eef218ec855103a3bb5da5
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Reviewed-on: http://review.coreboot.org/10881
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Instead of having a second copy that already within 2-3 days
becamer quite outdated, use the same xcompile copy for coreboot
and libpayload, as we do with Kconfig already.
This requires a simple change to the top level xcompile to understand
both CONFIG_COMPILER_GCC and CONFIG_LP_COMPILER_GCC (only one of
them will occur at the same time)
libpayload's .xcompile target was moved later so that it can make use
of $(top)
Change-Id: I44001067f551cd0776dd303cbaeaa40eb3d5c1db
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10863
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
clang probing will pick up the first one that clang does not complain about
and right now that is armv7a-eabi, even though our toolchain builds for
armv7-a-eabi (and consecutively the build fails because there is no
armv7a-eabi-as)
Change-Id: I2594151150107f8e9c1aad33647dcb2f9878f953
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10830
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On Windows systems, structs can be packed gcc style or ms style.
Make sure we use the same one (gcc style) in our user space tools
that we use in coreboot.
Change-Id: I7a9ea7368f77fba53206e953b4d5ca219ed4c12e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10794
Tested-by: build bot (Jenkins)
On Windows systems the archetype printf defaults to ms_printf
instead of gnu_printf. Keep the archetype print for all non-
Windows compiles to not break compatibility with other systems
out there.
Change-Id: Iad8441f4dc814366176646f6a7a5df653fda4c15
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10793
Tested-by: build bot (Jenkins)
The option --divide is required by our assembler to ensure that
'/' is not parsed as a comment sign but as a division, because
some of the cache as ram code is using divisions.
The --divide parameter has been part of the GNU as since binutils 2.17.
Hence, compile romstage (which contains cache as ram init) with
-Wa,--divide unconditionally instead of probing for it and adding it to
all compiler invocations (because that is causing random trouble with
clang when compiling the SMM code and calling gcc with --divide instead of
-Wa,--divide)
Change-Id: Ideefb2a243dc1d657ba415a99c1f8ab1d93800e0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
While for GCC targets the compiler is just defined as a single
binary, for clang it is defined as a binary and some options, e.g.:
clang -target i386-elf -ccc-gcc-name i386-elf-gcc
When executing the compiler with "$1", the shell will look for a
binary with the above name (instead of just clang) and always fail
detection of any CFLAGS.
By adding -c we prevent the compiler from failing because it can't
link a user space program (when what we're looking for, is whether
a specific compiler flag can be used to compile a coreboot object
file)
Change-Id: I1e9ff32fe40efbe3224c69785f31bc277f21d21b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10816
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Running "clang -target i386-elf --print-librt-file-name" prints
[..]/bin/../lib/clang/3.6.1/lib/libclang_rt.builtins-i386.a
However, the correct path is [..]/lib/linux/libclang_rt.builtins-i386.a
on a Linux host. Hence, create symbolic links to make sure that our
build system finds the file where it expects it.
Change-Id: I21ef5c4a690d83c326717ca55c5ace558257a0ec
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10815
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I974c6c8733356cc8ea4e0505136a34b6055abf0c
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10809
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I9bfc017dee86fe6cbc51de99f46429d53efe7d11
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10810
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not all systems put bash at /bin/bash.
Change-Id: Ib58cd2f6cf330b5b2678d55bb929696872fba9c9
Signed-off-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/10808
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
GMP is overeager to detect 64bit ABIs even if the entire running codebase is
32bit (but on a 64bit CPU). Enforce a 32bit build in that situation.
Change-Id: I23e9e57f3c8b0e3ad2e4e1e3eb106f7830aa76a1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10792
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
xcompile keeps two CFLAGS around now, for GCC and CLANG. Normally they're not
required to request the libgcc/compiler-rt path, but with the multilib capable
x86_64-elf target it's required to make it pick the right libgcc when used as
i386-elf builder.
Change-Id: I700e7aa5783dc36698dd2ab8a38642a144e80fe9
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10795
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The syntax of "conf" has changed, but we never adapted
our Kconfig Makefile since we are not typically using those
targets (except for coreinfo)
Change-Id: Ib95b53d255d7456cc6d6bcc7048fcaa0db1ce142
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10716
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
It's perfectly fine to have one single copy of kconfig in the tree.
Change-Id: Icfe32f0249dfc1c223009d6e7136462f8f8a7248
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
These scripts were bit-rotting on my box and may be useful for somebody else.
no-fsf-addresses.sh removes various FSF addresses from license headers
find-unused-kconfig-symbols.sh points out Kconfig variables that may be
unused. There are some false positives, but it serves as a starting point.
Change-Id: I8ddb5bea5fe87d39eed5f39f32077944b37d0665
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10675
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Adds support in cbfstool to adjust the entry field based on the
virtual and physical address in program header.
BUG=chrome-os-partner:40713
BRANCH=None
TEST=Verified correct entry point address. Trusty loads and boots correctly.
Change-Id: I215b0bea689626deec65e15fb3280e369d816406
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 32a740f0b628c124d3251cc416e2fc133bb15c57
Original-Change-Id: Ia999b5c55887c86ef1e43794ceaef2d867957f4d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/274087
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10690
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I looked for a way to pass the 'make crossgcc -j8' on to buildgcc, but
didn't find a way to get that value directly. MAKEFLAGS turns -j8 into
a jobserver variable.
Instead, this patch allows the number of CPUs to be set on the command
line through a variable instead.
Example: 'make crossgcc BUILDJOBS=8'
Change-Id: I37608cdb4549226cb7ff8c3ff6d9f4773acf6b0b
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10620
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update the clean target to remove the intermediate files. These should
get removed automatically, but if the build stops in the middle, or if
the -t command is used for buildgcc, they can be left in the directory.
Add a distclean target that removes the downloaded tarballs as well as
everything else.
Change-Id: I6ea19e7a499b0c313c1d2eff7e36386204ec834e
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10621
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
After commit with Change-Id Ia1839ed3 (sandy/ivy: Include
IRQ routes from platform), update autoport to include
that file into the DSDT.
Change-Id: I14534438d0b433895f384539c8b413eaa53d943a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10612
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
buildgcc fails if g++ or clang isn't found on the host. This
was failing on OSX due to the string used to check for clang
doesn't match "Apple LLVM". Add an additional search string for
clang "LLVM".
Change-Id: I05e36cfc690061b3233376d57f44f197cab933ea
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10569
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's a separate target -P iasl for that now.
Change-Id: I95c0fe8fc266859d8a31b7bea890775dc9f19694
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10567
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this change, the x86_64-elf-gcc can compile i386-elf
binaries by specifying -m32. The patch against GCC is needed
to enable building the 32bit libraries when building x86_64-elf-gcc
Change-Id: Ic86a009eccfdf3e33a398bcdcc13b15c8dfc0d31
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10497
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For consistency in user output, move the check for all
required utilities after printing the banner and parsing
options.
Change-Id: I5bf31368885c73e35f18b02d53d099f3f3871acc
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10566
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When required tools are missing, try to give the user more detailed
information on how to solve the problem.
Change-Id: Ifa21c1af38a036a7d4f5a786041a87a7d45f4ec5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10555
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Iee5ab0d3bdc8b754669356f2046d290d9ca555c2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10511
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Don't print error messages if an unpatched clang is detected.
Change-Id: If77722a40a59e99f01d121a0c43999f05f3c4421
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10554
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves the CMAKE definition down into the case statement
for $PACKAGE so that it is only required when the user wants to
build clang.
With this approach, "./buildgcc -P clang" will error out with the
"ERROR: Missing tool:" message if cmake is not installed.
Change-Id: I1e5c1bd67ade8f93ba0390df7f234deb47b9b18a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/10556
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support for detecting an x86-64 cross compiler in xcompile.
Change-Id: Icd2c9af7903956216db1fd54902eab6da0fe3e21
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/8669
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Otherwise dummy contains uninitialized data, which leads to non-reproducible
builds (and a leak of 4 bytes of stack data).
Change-Id: Iaaf846580ec436fdd4f0800c7576b544f50d6ae0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10524
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The precise phrase returned by 'type' differs between locales and shells.
It also doesn't matter because it returns an error code when it hasn't found a
match.
Let's simply assume there's no build_$OneOfOurPackages commands around that
could also match.
Change-Id: I44f021243149701e8da9dd74c368ca2ad4509419
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Tested-on: linux bash, linux dash, solaris sh, solaris ksh.
Reviewed-on: http://review.coreboot.org/10517
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ic6ce697af6102da7d8c53947c9d3b5ac39817d7c
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10333
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
using grep is an extra process invocation, but it's not a bashism.
Also match precisely, so AGCC doesn't trigger on GCC (we don't have collisions
right now, but we won't have to deal with them in the future)
Change-Id: I242833c350b7f1e6a6793f288c1aae0b50d57a26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10518
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Locales differ in the order in which they sort entries. This ensures
predictable behavior.
Change-Id: I4ceec90a56bbc368a847d14298db0a21cc21e77c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10510
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Build with bfd and gold linker, but use bfd linker per default
and make sure that lto is enabled in both binutils and gcc
Change-Id: I0584396b4580674cfdca24fbed0d8eeb1ee38806
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10496
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Instead of building IASL and GDB implicitly when building
GCC, this patch changes buildgcc to let you explicitly specify
what you want to build.
This will prevent IASL from building over and over again, when
all you need is GDB.
The new command line option is -P | --package <package> where
package is one of the following: GCC, GDB, CLANG, IASL
If no package is specified, buildgcc will default to GCC.
Change-Id: I8836bed16fc2bc39e0951199143581cc6d71cb4d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10492
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
IASL was broken when compiling without GCC.
Change-Id: Ib859ce41c1dda10181781c025fc378504f5ebb91
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10495
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
GDB stopped building ever since we updated from version 7.6
but nobody noticed ;)
Update from 7.9 to 7.9.1 and bring the required patches forward.
Change-Id: I2f357525a46d5540e9f57b80d830943bbd5dfcaf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10494
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This groups all tasks happening in the main program,
orders them according to their dependencies and adds
comments on the various tasks.
Change-Id: Ib62bd213977cbc3307ef62e9a7e64515563968c1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10490
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
- don't capture build_$package in a subshell by piping it
- move HOSTCFLAGS to build_GMP
- only create a build directory if a build happens
- automatically collect packages to build
Change-Id: Ic5a9f3f222faecd3381b413e5f25dff87262a855
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10475
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
Add a savedefconfig target and the help for it to the kconfig
makefile.
The main advantage I found for using defconfigs instead of the full
.config is that they require less maintenence, so long as reasonable
default values are set when adding new config options. When the
defconfig is expanded, it will use default values for all options not
saved in the defconfig. This cuts the size of a saved config from
500ish lines to roughly 20 lines.
savedefconfig was added to the linux kernel in commit id
7cf3d73b4360e91b14326632ab1aeda4cb26308d
Change-Id: I45f3dc87b773fb6e9ee53e32fdcafff1f53074d2
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10462
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring gdb in sync with all other build targets.
Change-Id: I9c478947a00f044edf910a91d876bbf486a791cf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10488
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Otherwise one could end up with what they think is a coreboot toolchain
but in fact it'd be missing some patches.
Change-Id: Ic451f7061b822d0f4b64acc9976ba81fd544e85b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10487
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
gcc and binutils fixed their upstream tar balls, and running
autoconf created more problems than it solved
Change-Id: I0003dd597f521701405ff35923214435136b262d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10486
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I29fe23e377045f08b8212742d84c2ee2b4a61b15
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10485
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I7a095470d408d013a4a915e010c59ea99ca1f1c8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10484
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
The cbmem util needs the CBMEM_IDs and the strings for
reporting and shares the cbmem.h file with coreboot. Split out
the IDs so for a simpler sharing and no worries about overlap of
standard libraries and other things in the header that coreboot
requires, but the tool does not.
Change-Id: Iba760c5f99c5e9838ba9426e284b59f02bcc507a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10430
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
$ make gitconfig
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
[..]
Change-Id: Ib477566e3841e419aa7880c912636540a0ad5432
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10464
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This removes quite a bit of boilerplate from the script, and makes
it easier to read.
Change-Id: I92348b810ff19f7d18810f842b76e0e595b3d397
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a new option -C|--clang to buildgcc to build a clang based
toolchain as opposed to a gcc based toolchain. This toolchain
comes with the required patches needed to successfully build
coreboot, and also with clang's famous scan-build script.
Change-Id: I1aea7cd6002edc4f3bb2b46dc1f69a212ad18f77
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10415
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- keep a list of packages to build in $PACKAGES and only download,
patch and build a package if it is in that list (instead of having
exceptions for GDB, EXPAT and PYTHON)
- unify interface for download() and unpack_and_patch()
- consolidate some randomly spread code like creating / removing
build directories and calls to searchtool()
Change-Id: I2070e3b2fbb84eb18e9220658fb2d5518b8179ee
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10434
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will be useful for adding clang support (and hopefully
makes the code a bit more readable)
Change-Id: Ie866fb2bd71e2a64f26f2755961bd126e101cbe5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
clang requires some additional options to disable warnings which
can be handled by xcompile.
Also drop the hard coded clang compilers in Makefile
Change-Id: I0f12f755420f315127e6d9adc00b1246c6e7131b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7612
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This uses the availability of CONFIG_* variables in .xcompile and tests for
compilers in xcompile so that the build system doesn't need to probe them.
Change-Id: I359ad6245d2527efa7e848a9b38f5f194744c827
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/10424
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is in preparation of adding support for clang to xcompile.
Change-Id: I518d077f134610082b0939b1525682f2289eec34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10423
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
crossgcc builds gmp, whose build system normally optimises for the hardware
it's built on. That may give a minor performance boost but has the downside
that the compiler becomes non-portable and may break on other systems due to
illegal instructions.
Setting CFLAGS to some reasonable value prevents gmp's configure script from
choosing CPU specific -mtune flags (which may enable optimizations that only
run on CPUs with the same feature set).
Enabling "fat" builds make the build system add all optimized assembler
routines and makes the selection of the right one a runtime decision instead
of deciding at compile time.
Change-Id: I72d20627270baa082cd02ebb4c9a09cd23f30f8c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10412
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfs_get_file_content was replaced with cbfs_boot_map_with_leak but
36f8d27ea9 failed to get it into account.
Change-Id: I0c7840043b2ea6abaf8e70f4bf1a63c96aedebc1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10403
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Previously I tried to see if Linux think that port 0x60 is in use by keyboard.
Unfortunately it always thinks that it is. Instead just base off real input
busses used.
Change-Id: I4bb744938f623d29f38396165a1694fee78c3d32
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10376
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
It was reversed between Lenovo and non-Lenovo cases.
Change-Id: I52c3b928abda2851e97ec0b40b7da5c5191217f5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10374
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Apple is named Apple Inc in DMI but is "apple" in coreboot naming.
For other vendors we should follow similar pattern.
Change-Id: I7975b19faaf942c5bd44a704bcee994815499ceb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10372
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This allow an easy creation of standalone "autoport pack".
Change-Id: Ibe9e38aa3b4bbd7260104e1c2a11630790ff4d2f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10370
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This should be able to generate bootable ports for sandy/ivy, possible with
minor fixes. Howto is in readme.md
Change-Id: Ia126cf0939ef2dc2cdbb7ea100d2b63ea6b02f28
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7131
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Change-Id: Ibc06b17f48f72d5f9931437ffce020023ece2445
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10328
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: I0ac0c957738ce512deb0ed82b2219ef90d96d46b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10322
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
We updated the source files, but not the precompiled results.
Change-Id: I49634409d01c8d7cf841944e01d36571ae66c0ac
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10296
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Because new images place the bootblock in a separate region from the
primary CBFS, performing an update-fit operation requires reading an
additional section and choosing a different destination for the write
based on the image type. Since other actions are not affected by these
requirements, the logic for the optional read and all writing is
implemented in the cbfs_update_fit() function itself, rather than
relying on the main() function for writing as the other actions do.
Change-Id: I2024c59715120ecc3b9b158e007ebce75acff023
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10137
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Useful for autoport and other gfx-related developpement.
Change-Id: I1fc0952bc30ab15cd39a4f0c00649714dcf318f3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10276
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.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>
Currently, when the remote master branch of the board-status
repository changes between cloning and pushing, `git push origin`
fails.
This race condition happens quite often with REACTS testing commits at
the same time on different systems.
If that happens, just download the objects and refs from the
board-status repository and rebase the local changes on it. Try that
three times before exiting with an error message.
Change-Id: I628ebce54895f44be6232b622d56acbcc421b847
Helped-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Helped-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10262
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Fix up commit 1b6e7a67 (Updates to the board status script) forgetting
to put `echo` in front of the string.
Change-Id: I7d4dfcc62545dfee2073410ba47489318a9bf5c6
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10265
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Instead of writing to the source tree (which we should generally avoid),
copy the pre-generated files (from lex and yacc) to $(objutil). Adapt
include paths and rules so they're found.
Change-Id: Id33be6d1dccf9a1b5857a29c55120dcc8f8db583
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10252
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While logical, make's handling of multiple targets in a rule isn't
intuitive, and was done wrong in cbfstool's Makefile.
%.c %.h: %.l encourages make to run the rule twice, once to
generate the .c file, once for the .h file. Hilarity ensues.
Change-Id: I2560cb34b6aee5f4bdd764bb05bb69ea2789c7d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10251
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These names will skip the lint-whitespace tests.
Change-Id: If4ac1f8e11fd0ac62f09696f2704477b6eb30046
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10212
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
add handling of PCI IDs for Broadwell-U/Wildcat Point LP,
using same functions as Haswell-U/Lynx Point LP
Change-Id: I1094cbdace3c73f0f85c2e27c676b877b1a04bfe
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: http://review.coreboot.org/10209
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our style discourages unnecessary typedefs, and this one doesn't gain
us anything, nor is it consistent with the surrounding code: there's
a function pointer typedef'd nearby, but non-opaque structs aren't.
BUG=chromium:482652
TEST=None
BRANCH=None
Change-Id: Ie7565240639e5b1aeebb08ea005099aaa3557a27
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Change-Id: I4285e6b56f99b85b9684f2b98b35e9b35a6c4cb7
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10146
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbfstool handling of new-style FMAP-driven "partitioned" images
originally disallowed the use of x86-style top-aligned addresses with
the add.* and layout actions because it wasn't obvious how they should
work, especially since the normal addressing is done relative to each
individual region for these types of images. Not surprisingly,
however, the x86 portions of the build system make copious use of
top-aligned addresses, so this allows their use with new images and
specifies their behavior as being relative to the *image* end---not
the region end---just as it is for legacy images.
Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10136
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These new-style firmware images use the FMAP of the root of knowledge
about their layout, which allows them to have sections containing raw
data whose offset and size can easily be determined at runtime or when
modifying or flashing the image. Furthermore, they can even have
multiple CBFSes, each of which occupies a different FMAP region. It is
assumed that the first entry of each CBFS, including the primary one,
will be located right at the start of its region. This means that the
bootblock needs to be moved into its own FMAP region, but makes the
CBFS master header obsolete because, with the exception of the version
and alignment, all its fields are redundant once its CBFS has an entry
in the FMAP. The version code will be addressed in a future commit
before the new format comes into use, while the alignment will just be
defined to 64 bytes in both cbfstool and coreboot itself, since
there's almost no reason to ever change it in practice. The version
code field and all necessary coreboot changes will come separately.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom and image.bin images with
and without this patch, diff their hexdumps, and note that no
locations differ except for those that do between subsequent builds of
the same codebase. Try working with new-style images: use fmaptool to
produce an FMAP section from an fmd file having raw sections and
multiple CBFSes, pass the resulting file to cbfstool create -M -F,
then try printing its layout and CBFSes' contents, add and remove CBFS
files, and read and write raw sections.
BRANCH=None
Change-Id: I7dd2578d2143d0cedd652fdba5b22221fcc2184a
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 8a670322297f83135b929a5b20ff2bd0e7d2abd3
Original-Change-Id: Ib86fb50edc66632f4e6f717909bbe4efb6c874e5
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10135
Tested-by: build bot (Jenkins)
The rules didn't actually trigger to rebuild the parser.
Change-Id: Id51aaa9816b069204c119622d60f7b728b762cad
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10168
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
They're essentially collected on a stack before they're
parsed. So we push them backwards, then parse them in
the correct order.
Change-Id: Ibf29559389cd19f260d67bae8e0b5ef9f4f58d91
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10169
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Change-Id: Iaec748b4bdbb5da287520fbbd7c3794bf664eff6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10161
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sol Boucher <solb@chromium.org>
Fine tune the following two checks:
- Check for incorrect file permissions
This one had a linux path hard coded, so it would choke on
some commits unnecessarily.
- FILE_PATH_CHANGES seems to not be working correctly. It will
choke on added / deleted files even if the MAINTAINERS file
is touched. Hence, switch from WARN to CHK (as WARN currently
blocks commits as well)
Change-Id: I9fccfbd75e94f420de45cf8b58071e3198065cf3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10123
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The fmd compiler now processes "(CBFS)" annotations, distilling them
into a comma-separated list of the names of sections containing
CBFSes. This list is the only thing printed to standard output to
enable easy capture and machine consumption by other tools.
Additionally, the ability to generate a tiny header with a define for
the primary CBFS's size is implemented and can be requested via a
new command-line switch.
Here's an example of how to use the new features:
$ ./fmaptool -h layout.h layout_arm_8192.fmd layout.fmap 2>/dev/null
FW_MAIN_A,FW_MAIN_B,COREBOOT
The hypothetical fmd file contains three sections annotated as (CBFS),
the names of which are printed to standard output. As before, a binary
FMAP file named layout.fmap is created; however, because the command
was invoked with -h, a header #define ing the offset of its FMAP
section (i.e. where it will be relative to the base of flash once the
boot image is assembled) is also generated.
BUG=chromium:470407
TEST=Verify that fmd files without a "COREBOOT" section or with one
that isn't annotated as "(CBFS)" are not accepted. Ensure that the
list of CBFS sections matches the descriptor file's annotations and
is led by the "COREBOOT" section. Invoke with the header generation
switch and check that output file for reasonableness.
BRANCH=None
Change-Id: I496dd937f69467bfd9233c28df59c7608e89538f
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 9227698adecf675770b2983380eb570676c2b5d2
Original-Change-Id: I8b32f6ef19cabe2f6760106e676683c4565bbaad
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262956
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9967
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The tool now makes use of the ERROR() macros from common.h.
Change-Id: Ie38f40c65f7b6d3bc2adb97e246224cd38d4cb99
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10048
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The buffer API that cbfstool uses to read and write files only directly supports
one-shot operations on whole files. This adds an intermediate partitioned_file
module that sits on top of the buffer system and has an awareness of FMAP
entries. It provides an easy way to get a buffer for an individual region of a
larger image file based on FMAP section name, as well as incrementally write
those smaller buffers back to the backing file at the appropriate offset. The
module has two distinct modes of operation:
- For new images whose layout is described exclusively by an FMAP section, all
the aforementioned functionality will be available.
- For images in the current format, where the CBFS master header serves as the
root of knowledge of the image's size and layout, the module falls back to a
legacy operation mode, where it only allows manipulation of the entire image
as one unit, but exposes this support through the same interface by mapping
the region named SECTION_NAME_PRIMARY_CBFS ("COREBOOT") to the whole file.
The tool is presently only ported onto the new module running in legacy mode:
higher-level support for true "partitioned" images will be forthcoming. However,
as part of this change, the crusty cbfs_image_from_file() and
cbfs_image_write_file() abstractions are removed and replaced with a single
cbfs_image function, cbfs_image_from_buffer(), as well as centralized image
reading/writing directly in cbfstool's main() function. This reduces the
boilerplate required to implement each new action, makes the create action much
more similar to the others, and will make implementing additional actions and
adding in support for the new format much easier.
BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom images with and without this patch
and diff their hexdumps. Ensure that no differences occur at different locations
from the diffs between subsequent builds of an identical source tree. Then flash
a full new build onto nyan_big and watch it boot normally.
BRANCH=None
Change-Id: I25578c7b223bc8434c3074cb0dd8894534f8c500
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 7e1c96a48e7a27fc6b90289d35e6e169d5e7ad20
Original-Change-Id: Ia4a1a4c48df42b9ec2d6b9471b3a10eb7b24bb39
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265581
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10134
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This allows calls to buffer_delete() to work on a buffer that has been
buffer_seek()ed or the buffer created by a buffer_splice(). The same
information could also be useful for other purposes, such as writing
slices back to a file at the offset they originally occupied.
BUG=chromium:470407
TEST=Attempt to perform the following sequence of buffer actions, then run it
through valgrind to check for memory errors:
for (int pos = 0; pos <= 3; ++pos) {
struct buffer seek_test;
buffer_create(&seek_test, 3, "seek_test");
if (pos == 0) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 1) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 2) {
buffer_delete(&seek_test);
continue;
}
buffer_seek(&seek_test, 1);
if (pos == 3) {
buffer_delete(&seek_test);
continue;
}
}
for (int pos = 0; pos <= 14; ++pos) {
struct buffer slice_test;
buffer_create(&slice_test, 3, "slice_test");
if (pos == 0) {
buffer_delete(&slice_test);
continue;
}
struct buffer sliced_once;
buffer_splice(&sliced_once, &slice_test, 1, 2);
if (pos == 1) {
buffer_delete(&slice_test);
continue;
}
if (pos == 2) {
buffer_delete(&sliced_once);
continue;
}
struct buffer sliced_twice;
buffer_splice(&sliced_twice, &sliced_once, 2, 1);
if (pos == 3) {
buffer_delete(&slice_test);
continue;
}
if (pos == 4) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 5) {
buffer_delete(&sliced_twice);
continue;
}
struct buffer sliced_same;
buffer_splice(&sliced_same, &slice_test, 1, 1);
if (pos == 6) {
buffer_delete(&slice_test);
continue;
}
if (pos == 7) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 8) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 9) {
buffer_delete(&sliced_same);
continue;
}
struct buffer sliced_thrice;
buffer_splice(&sliced_thrice, &sliced_twice, 1, 0);
if (pos == 10) {
buffer_delete(&slice_test);
continue;
}
if (pos == 11) {
buffer_delete(&sliced_once);
continue;
}
if (pos == 12) {
buffer_delete(&sliced_twice);
continue;
}
if (pos == 13) {
buffer_delete(&sliced_same);
continue;
}
if (pos == 14) {
buffer_delete(&sliced_thrice);
continue;
}
}
BRANCH=None
Change-Id: Id67734654a62302c0de37746d8a978d49b240505
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 00c40982a21a91a488587dd3cead7109f3a30d98
Original-Change-Id: Ie99839d36500d3270e4924a3477e076a6d27ffc8
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/267467
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10133
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, this function allowed one to pass a size of 0 in order to
indicate that the entire buffer should be copied. However, the
semantics of calling it this way were non-obvious: The desired
behavior was clear when the offset was also 0, but what was the
expected outcome when the offset was nonzero, since carrying over the
original size in this case would be an error? In fact, it turns out
that it always ignored the provided offset when the size was zero.
This commit eliminates all special handling of 0; thus, the resulting
buffer is exactly as large as requested, even if it's degenerate.
Since the only consumer that actually called the function with a size
of 0 was buffer_clone(), no other files required changes.
Change-Id: I1baa5dbaa7ba5bd746e8b1e08816335183bd5d2d
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10132
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The only operation performed on this struct turned out to be sizeof...
Change-Id: I619db60ed2e7ef6c196dd2600dc83bad2fdc6a55
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patches a memory leak on every struct cbfs_image creation that
was introduced by c1d1fd850e. Since that
commit, the CBFS master header has been copied to a separate buffer so
that its endianness could be fixed all at once; unfortunately, this
buffer was malloc()'d but never free()'d. To address the issue, we
replace the structure's struct cbfs_header * with a struct cbfs_header
to eliminate the additional allocation.
Change-Id: Ie066c6d4b80ad452b366a2a95092ed45aa55d91f
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10130
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The function hadn't been updated to account for the fact that we now
copy an endianness-corrected CBFS master header into a separate buffer
from the CBFS data: it still performed pointer arithmetic accross the
two buffers and wrote the copied buffer into the image without
restoring the original endianness.
Change-Id: Ieb2a001f253494cf3a90d7e19cd260791200c4d3
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10122
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the recent rename of documentation -> Documentation, the
checkpatch.pl script broke. Fix the tree check, and change the
user visible output of "kernel" to coreboot.
Change-Id: I34f538d4436e468b1c91eb36aa2f60a2a3308111
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10125
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a compiler for a language whose textual representation of flashmap
regions will be used to describe the layout of flash chips that contain more
than just a single CBFS. Direct integration with cbfstool (via a new
command-line switch for the create action) is forthcoming but will be added
separately.
BUG=chromium:461875
TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for
panther. Using the latter file as a reference, write a corresponding
fmap.fmd file and feed it through fmaptool. Run both binary output files
though the flashmap project's own flashmap_decode utility. Observe only
the expected differences.
BRANCH=None
Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142
Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9942
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is being fixed in a separate commit so we can diff against the
library as it existed in its own repo.
Change-Id: Id87cd8f4e015a5ed7dd8a19302cc22ab744fefe8
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10141
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
flashmap was developed in a separate repository until now.
Import the files from the 2012 version of the project [1].
[1] https://code.google.com/p/flashmap
BUG=chromium:461875
TEST=None
BRANCH=None
Change-Id: Ida33f81509abc1cf2e532435adbbf31919d96bd8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: f44e1d1864babe244f07ca49655f0b80b84e890d
Original-Change-Id: Ibf191d34df738449c9b9d7ebccca3d7f4150d4d3
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254801
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9940
Tested-by: build bot (Jenkins)
This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
was resulting in confusing claims about the amount of free space at the end of a
CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
entry by testing whether it would collide with the beginning of the *subsequent*
file header; thus, if a file's end is unaligned, its reported size will not
match the actual available capacity. Although deleted entries always end on an
alignment boundary because `cbfstool remove` expands them to fill the available
space, `cbfstool create` doesn't necessarily size a new entries region to result
in an empty entry with an aligned end.
This problem never resulted in clobbering important data because cbfstool would
blindly reserve 64B (or the selected alignment) of free space immediately after
the all-inclusive empty file entry. This change alters the way this reservation
is reported: only the overhang past the alignment is used as hidden padding, and
the empty entry's capacity is always reported such that it ends at an aligned
address.
Much of the time that went into this patch was spent building trust in the
trickery cbfstool employs to avoid explicitly tracking the image's total
capacity for entries, so below are two proofs of correctness to save others time
and discourage inadvertent breakage:
OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
empty file header is small enough that it won't cross another aligned address.
OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
that its contents end on an aligned address.
THM. 1: Placing a new file within an empty entry located below an existing file
entry will never leave an aligned flash address containing neither the beginning
of a file header nor part of a file.
We can prove this by contradiction: assume a newly-added file neither fills to
the end of the preexisting empty entry nor leaves room for another aligned
empty header after it. Then the first aligned address after the end of the
newly-inserted file...
- CASE 1: ...already contains a preexisting file entry header.
+ Then that address contains a file header.
- CASE 2: ...does not already house a file entry header.
+ Then because CBFS content doesn't fall outside headers, the area between
there and the *next* aligned address after that is unused.
+ By (A), we can fit a file header without clobbering anything.
+ Then that address now contains a file header.
THM. 2: Placing a new file in an empty entry at the very end of the image such
that it fits, but leaves no room for a final header, is guaranteed not to change
the total amount of space for entries, even if that new file is later removed
from the CBFS.
Again, we use contradiction: assume that creating such a file causes a
permanent...
- CASE 1: ...increase in the amount of available space.
+ Then the combination of the inserted file, its header, and any padding
must have exceeded the empty entry in size enough for it to cross at
least one additional aligned address, since aligned addresses are how
the limit on an entry's capacity is determined.
+ But adding the file couldn't have caused us to write past any further
aligned addresses because they are the boundary's used when verifying
that sufficient capacity exists; furthermore, by (B), no entry can ever
terminate beyond where the initial empty entry did when the CBFS was
first created.
+ Then the creation of the file did not result in a space increase.
- CASE 2: ...decrease in the amount of available space.
+ Then the end of the new file entry crosses at least one fewer aligned
address than did the empty file entry.
+ Then by (A), there is room to place a new file entry that describes the
remaining available space at the first available aligned address.
+ Then there is now a new record showing the same amount of available space.
+ Then the creation of the file did not result in a space decrease.
BUG=chromium:473726
TEST=Had the following conversation with cbfstool:
$ ./cbfstool test.image create -s 0x100000 -m arm
Created CBFS image (capacity = 1048408 bytes)
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 null 1048408
$ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
1+0 records in
1+0 records out
1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
E: Failed to add 'toobigmed.bin' into ROM image.
$ truncate -s -1 toobigmed.bin
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
toobig 0x40 raw 1048408
$ ./cbfstool test.image remove
-n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
(empty) 0x40 deleted 1048408
BRANCH=None
Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263962
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9939
Tested-by: build bot (Jenkins)
Add a Linux style MAINTAINERS file and the get_maintainer.pl
script from the Linux kernel source (adapted to work in the
coreboot source tree)
Change-Id: I983e30c20c371d238cfa7c0a074587b731387c63
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10021
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We have discussed dropping lbtdump since 2007, since it was obsoleted
by lxbios (nowadays aka nvramtool) back then.
http://www.coreboot.org/pipermail/coreboot/2007-August/024188.html
Well, it's only eight years later.
Change-Id: I5242118cd3763d1b8c4bdc6f023cf93ae1b5b85d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10121
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility is AMD SC520 specific (and AMD SC520 support has been
dropped from coreboot)
Change-Id: I8ebd52c2e6af113d2110c106f88fdd7c0a672c98
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility was useful on older VIA Epia-M boards, which we
have dropped from the tree a while ago. Hence drop the utility
as well.
Change-Id: Ie0d6303f4f4cfb6b21cd90696c60e124f0a5f4d8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10119
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The Kconfig option list generator was broken by two different changes
to the project in the last few years:
- the switch to git from svn
- allowing wild card includes in Kconfig
Change-Id: I6bc5024a04958e9718d2e3a3a3bb6d69d4277eb6
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10115
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This tool has had its own repository since a long time:
https://code.google.com/p/i915tool/
Drop the obsolete copy we kept in the tree.
Change-Id: Idee4ea3423453f6ced6e95c0bd2e45d95ca61851
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10114
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility links in coreboot code, and has been broken for a long
time. These changes get it to compile again.
Change-Id: I69445a8b3cbfc9a2b560c68b8de2e080837ec502
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10112
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This utility was only used to debug the initial ARM Chromebook bringup,
but it's not really useful anymore.
Change-Id: Icff0a80f244adae3c35a8430c54de9e415fbd7d0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10111
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
OpenBSD refuses to implement it due to security concerns,
so use glob instead.
Change-Id: I7531cfe91deff240f7874d94d5acb340b87e51b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10028
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The file have been updated to warn wiki users to edit
the page as it is generated by a bot.
Change-Id: I5802ff8c7986c0fd93adf58e2353df81de9c2b75
Signed-off-by: David Englund <public@beloved.name>
Reviewed-on: http://review.coreboot.org/8682
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
Currently `xcompile` generates `.xcompile` with the following at the
top.
# platform agnostic and host tools
IASL:=iasl
HOSTCC:=gcc
The assignment `:=` doesn’t allow to override the variable. So use `?=`
instead so the host compiler can be passed to coreboot.
HOSTCC=gcc-5 make
Note, that this is just a hack, as the existence of `gcc` is checked
beforehand.
Change-Id: Iebf3e43eb7eaffa7cf0efe97710d9feb3fe2a989
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/9457
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If the buildgcc is interrupt by Ctrl-C, probably part of
an archive is downloaded. If we run buildgcc again, the
incomplete archive would be considered as cached file
and skipped.
We check file hashes to see if the file is complete. If test
is failed, we need to delete the partially-downloaded file
and download it again.
sha1sum is quite different among the distributions.
Only Linux, Cygwin, Darwin have been tested.
Once new archive is deployed, a new checksum would be created,
which should be uploaded along with the script buildgcc.
Change-Id: Ibb1aa25a0374f774e1e643fe5e698de7bf7cc418
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4511
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 0e53931f (cbfstool: Clean up in preparation for adding new
files) split out the flags and introduced the variable `LINKFLAGS`.
Rename it to `LDFLAGS` which is more commonly used.
Change-Id: Ib6299f8ef5cf30dbe05bfae36f30ae4371f0a738
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10064
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
People were confused about the 'missing toolchain', so
improve the error message.
Change-Id: Icaee338aeedce2255bcfdafe5407c9df02ad9c4a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10036
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Roger Pau Monne