- Fix TODO: restrict $1 to allowed values.
- Specifically exclude 'oem' board status directories.
- Exclude any directory that doesn't follow the date format to keep
the script from breaking again in the future if something it doesn't
recognize is pushed. Just ignore it for the wiki.
- Fix shellcheck warnings.
Change-Id: I2864f09f5f1b1f5ec626d06e4849830400ef5814
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/18225
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
me_cleaner is a tool to strip down Intel ME/TXE images by removing all
the non-fundamental code, while keeping the ME/TXE image valid and
suitable for booting the system. The remaining code (ROMP and BUP
modules) is the one responsible for the very basic initialization of
the ME/TXE subsystem and can't be removed.
This tool exploits the fact that:
* Each ME/TXE partition is signed individually and it is possible to
remove both the partition and the signature.
* The ME/TXE modules are not signed directly, instead they are hashed
and the list of their hashes is hashed again and signed: this
means that modifying a module doesn't invalidate the signature,
but only the hash of that single module.
* The modules hashes are checked only when the corresponding module
needs to be executed.
* The system can boot after the execution of the first module (BUP,
inside the FTPR partition), even if the subsequent stages fail.
Currently me_cleaner works on every Intel platform with Intel ME or
Intel TXE with the following limitations:
* Doesn't work when Intel Boot Guard is set in Verified Boot mode.
* Doesn't fully work on Nehalem yet.
* On Skylake and later generations, since the partitions' internal
structure has changed, me_cleaner leaves intact the FTPR
partition, removing all the the other partitions.
This tool has been tested on multiple platforms and architectures by
different users, and seems to be stable. The reports are available
here:
https://github.com/corna/me_cleaner/issues/3
A more in-depth description of me_cleaner is available here:
https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F
Change-Id: I9013799e9adea0dea0775b9afe718de5fc4ca748
Signed-off-by: Nicola Corna <nicola@corna.info>
Reviewed-on: https://review.coreboot.org/18203
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If compression failed, just store the uncompressed data, which is what
cbfstool does as well.
Change-Id: I67f51982b332d6ec1bea7c9ba179024fc5344743
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18201
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
When the ME is hidden (most likely because it was disabled), it cannot
be found until activate_me() is called.
Change-Id: Ie1f65f61eb131577d7254af582e2709660f4da27
Signed-off-by: Dan Elkouby <streetwalrus@codewalr.us>
Reviewed-on: https://review.coreboot.org/18149
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It's a BSD function, also, we missed to include `endian.h`.
Just including `endian.h` doesn't fix the problem for everyone.
Instead of digging deeper, just use our own endian-conversion from
`commonlib`.
Change-Id: Ia781b2258cafb0bcbe8408752a133cd28a888786
Reported-by: Werner Zeh <werner.zeh@siemens.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18157
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The script now automatically discovers the original branch (if known)
and configures itself appropriately.
Additionally, commit messages for changes coming _from_ upstream will
be prefixed with "UPSTREAM: ".
With the optional --cros argument, it also adds a BUG/BRANCH/TEST block
at the right place in the commit message (right above the metadata) if
one doesn't already exist.
Change-Id: I81864ddca62fd99a9eb905d7075e5b53f58c4eb5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18135
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Martin Roth <martinroth@google.com>
cbfstool ... add ... -c precompression assumes the input file to be
created by cbfs-compression-tool's compress command and uses that to add
the file with correct metadata.
When adding the locale_*.bin files to Chrome OS images, this provides a
nice speedup (since we can parallelize the precompression and avoid
compressing everything twice) while creating a bit-identical file.
Change-Id: Iadd106672c505909528b55e2cd43c914b95b6c6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18102
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
cbfs-compression-tool provides a way to benchmark the compression
algorithms as used by cbfstool (and coreboot) and allows to
pre-compress data for later consumption by cbfstool (once it supports
the format).
For an impression, the benchmark's results on my machine:
measuring 'none'
compressing 10485760 bytes to 10485760 took 0 seconds
measuring 'LZMA'
compressing 10485760 bytes to 1736 took 2 seconds
measuring 'LZ4'
compressing 10485760 bytes to 41880 took 0 seconds
And a possible use for external compression, parallel and non-parallel
(60MB in 53 files compressed to 650KB on a machine with 40 threads):
$ time (ls -1 *.* |xargs -n 1 -P $(nproc) -I '{}' cbfs-compression-tool compress '{}' out/'{}' LZMA)
real 0m0.786s
user 0m11.440s
sys 0m0.044s
$ time (ls -1 *.* |xargs -n 1 -P 1 -I '{}' cbfs-compression-tool compress '{}' out/'{}' LZMA)
real 0m10.444s
user 0m10.280s
sys 0m0.064s
Change-Id: I40be087e85d09a895b1ed277270350ab65a4d6d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18099
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This speeds up the lzma encoder approximately four-fold.
Change-Id: Ibf896098799693ddd0f8a6c74bda2e518ecea869
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18098
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There are systems that come with curl but not wget (eg macOS) and they
now have to install one less additional dependency.
Also fix some cosmetic issues in console output and require valid
certificates on https downloads.
Change-Id: Idc2ce892fbb6629aebfe1ae2a95dcef4d5d93aca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/18048
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
When running abuild outside of jenkins, because all of the builds are
printed intermixed, it's easy to miss when a board has failed the build
by looking at the output. This saves a list of failed builds and prints
the list at the end of the run.
- Add a command line option to mark when abuild is being called
recursively.
- Add all failed builds to a list.
- Print the list when a non-recursive abuild run exits.
Change-Id: Icb40ed8083a57bbcde49297d2b0814f98dcbb6c8
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17890
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Variable name of inteltoolArgs was fixed.
The way of passing arguments to inteltool was changed from "-a -f"
to "-af" which is better as the string seems to be parsed
as a single argument.
Change-Id: I0c48fb1e912261748ba9e2b91c291bac28b9e856
Signed-off-by: Sebastian 'Swift Geek' Grzywna <swiftgeek@gmail.com>
Reviewed-on: https://review.coreboot.org/18050
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Gerrit will let you push a patch without a signed-off-by line,
although I believe it can't actually be merged. Instead of catching
it either manually, or when the patch is attempting to be merged,
catch this in the jenkins builder.
Change-Id: I80161befa157266dd4e3209839a06ff398aab6bb
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17941
Tested-by: build bot (Jenkins)
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
That's undefined behavior in C
Change-Id: I671ed8abf02e57a7cc993d1a85354e905f51717d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1229557
Reviewed-on: https://review.coreboot.org/18014
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This allows the make jenkins-build-toolchain to use the
BUILDGCC_OPTIONS variable. Previously, the options were hardcoded.
Change-Id: I5f4c1d3fc8c714ec3640356ae3c86ae157f486d2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17766
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
If we use ccache we have to interpret spaces in $CC as separation
characters. The downside is that we can't support spaces in the
compiler's path. But, well...
Change-Id: I4e6e6324389354669a755f570083a40ff00b1bbf
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/18018
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
argv is only filled for macro->argc > 0.
Change-Id: I5ff21098384afc823efa14be3d5565507fb2b3b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1287089
Reviewed-on: https://review.coreboot.org/18016
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
closure_type is copied then never used again. Close that leak.
Change-Id: Idd4201f7fc6495fde5ad2e1feb7e499e38986e92
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1287073
Reviewed-on: https://review.coreboot.org/18015
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Without this change inteltool cannot read BIOS_CNTL values nor can it
read the SPIBAR values.
Change-Id: I9ff16e060aca66e3cb11c8315a6843ccecd1d3c2
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17979
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The ICH7 SPIBAR offset and registers are different from later
generation.
ICH8 has a different offset from later generation.
ICH6 has no SPI controller.
Change-Id: I7691bce619089b15805114047bcb1fd121a5722b
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17978
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It's usually not too interesting, so hide it behind -v.
Change-Id: Icffb5ea4d70300ab06dfa0c9134d265433260368
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/17899
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On a 32-bit system, pointers are 32-bit wide, and not 64-bit, resulting
in the warning below.
```
mmap.c: In function ‘map_physical_exact’:
mmap.c:26:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
virt_addr = mmap((void*)mapto, len, PROT_WRITE | PROT_READ,
^
```
Fix this by using compatible types.
Change-Id: I4ede26127efcbd5668b978e6880a0535607e373d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/17970
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin Roth <martinroth@google.com>
CXXFLAGS seems to be used a lot and have to be specified independently
from CFLAGS.
Change-Id: Iff4c76e54a46e908299b532fd848165a3dc04d43
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17937
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
GCC 6 can optionally default to building all binaries as position
independent executables (PIE). This breaks linking against static
libraries that are compiled without position independent code (PIC).
Building GMP `--with-pic` in this case seems to be the least fragile
solution.
TEST=Run `make all` and `make BUILDGCC_OPTIONS=-b build-i386` in
util/crossgcc on Debian Stretch.
Change-Id: I5f3185af9c8d599379a628e18724b217b88be974
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17936
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The earlier loop exits gracefully iff i == index. In other cases, member
might be NULL, so check that the scan was successful before using its
results.
Change-Id: I818c233d797d82fa819243c4626dd9c4b7de3ac6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1129147
Reviewed-on: https://review.coreboot.org/17887
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It's later tested for NULL, but never initialized to make that test work
reliably.
Change-Id: Iadee1af224507a6dd39956306f3eafa687895176
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1323515
Reviewed-on: https://review.coreboot.org/17880
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
filebuffer is treated like a string, so it should be zero-terminated
like a string.
Change-Id: I078aa39906394be64023424731fe0c7ae2019899
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1323473
Reviewed-on: https://review.coreboot.org/17878
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To make the generated descriptor compatible with latest libflashrom.
Change-Id: I005159dd24e72da9cc43119103c96c5dd5b90a55
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17447
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We might not care much about this buffer, but we really use it later
on...
Change-Id: Ia16270f836d05d8b454e77de7b5babeb6bb05d6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1294797
Reviewed-on: https://review.coreboot.org/17860
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
- Because $configoptions contains embedded newlines that we want to be
interpreted when we pipe it out to the config file, change that back to
a printf, and tell shellcheck that we want to do it.
- 'make olddefconfig' & 'yes "" | make oldconfig' give us the same
output for the config file, but olddefconfig doesn't generate the log
the way oldconfig does. Go back to the previous behavior.
- Don't overwrite the config log with make savedefconfig.
Change-Id: I4966a3bb2541b452eeb4ca73ac3cd727f8525636
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17853
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
So far, cbfstool write, when used with the -u/-d options (to "fill
upwards/downwards") left the parts of the region alone for which there
was no new data to write.
When adding -i [0..255], these parts are overwritten with the given
value.
BUG=chromium:595715
BRANCH=none
TEST=cbfstool write -u -i 0 ... does the right thing (fill the unused
space with zeroes)
Change-Id: I1b1c0eeed2862bc9fe5f66caae93b08fe21f465c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: baf378c5f2afdae9946600ef6ff07408a3668fe0
Original-Change-Id: I3752f731f8e6592b1a390ab565aa56e6b7de6765
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/417319
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://review.coreboot.org/17787
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Martin Roth