This change moves `read_member` and `write_member` helper functions
out of cse_fpt.c and cse_serger.c into cse_helpers.c to avoid
duplication.
BUG=b:189177186,b:189167923
Change-Id: I7b646b29c9058d892bb0fc9824ef1b4340d2510c
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58201
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a new tool `cse_serger` which can be used to print,
dump and stitch together different components for the CSE region.
BUG=b:189177186
Change-Id: I90dd809b47fd16afdc80e66431312721082496aa
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55503
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a new tool `cse_fpt` which can be used to print and
dump CSE partitions in Flash Partition Table (FPT) format.
BUG=b:189167923
Change-Id: I93c8d33e9baa327cbdab918a14f2f7a039953be6
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add a new tool that that prints elog events.
The tool, as input, accepts either a file with the RW_ELOG contents, or
if the file is not provided it reads the contents of RW_ELOG by calling
the "flashrom" tool.
The tool is based on "mosys eventlog list"[1]. For the moment it only
supports "list", but future commits will add additional functionality.
This commit also adds missing ELOG defines needed for the tool. These
defines are added with the rest of the ELOG defines, in
include/commonlib/bsd/elog.h
The tool is placed inside util/cbfstool. The rationale behind the
decision, is that this tool shares a lot in common with the other tools
located in cbfstool: vboot dependency, shared files like common.o and
valstr.o, and in spirit is similar to some of the tools located in
cbfstool/.
As an example, you call the tool like the following:
$ elogtool list -f rw_elog_dump.bin
[1]: https://chromium.googlesource.com/chromiumos/platform/mosys/+/refs/heads/main/lib/eventlog/elog.c
BUG=b:172210863
Signed-off-by: Ricardo Quesada <ricardoq@google.com>
Change-Id: Ia1fe1c9ed3c4c6bda846055d4b10943b54463935
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Vboot's Makefile is controlled by a ${DEBUG} environment variable.
As the name is very generic, it may be set by accident without any
intention to change the build. Having it set would break reproduci-
bility at least but it also turns out that the hostlib build would
be incomplete so that linking cbfstool fails due to internal calls
to vb2api_fail() which is not built in.
Change-Id: I2a9eb9a645c70451a320c455b8f24bfed197117c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Fixes compilation on FreeBSD CURRENT, and possibly other releases.
The compiler, clang, complained about:
util/cbfstool/cbfstool.c:181:40: error: implicit declaration of function 'memmem' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
util/cbfstool/cbfstool.c:181:31: error: incompatible integer to pointer conversion initializing 'struct metadata_hash_anchor *' with an expression of type 'int' [-Werror,-Wint-conversion]
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Change-Id: I45c02a21709160df44fc8da329f6c4a9bad24478
Reviewed-on: https://review.coreboot.org/c/coreboot/+/53996
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
To support the new CONFIG_CBFS_VERIFICATION feature, cbfstool needs to
update the metadata hash embedded in the bootblock code every time it
adds or removes a CBFS file. This can lead to problems on certain
platforms where the bootblock needs to be specially wrapped in some
platform-specific data structure so that the platform's masked ROM can
recognize it. If that data structure contains any form of hash or
signature of the bootblock code that is checked on every boot, it will
no longer match if cbfstool modifies it after the fact.
In general, we should always try to disable these kinds of features
where possible (they're not super useful anyway). But for platforms
where the hardware simply doesn't allow that, this patch introduces the
concept of "platform fixups" to cbfstool. Whenever cbfstool finds a
metadata hash anchor in a CBFS image, it will run all built-in "fixup
probe" functions on that bootblock to check if it can recognize it as
the wrapper format for a platform known to have such an issue. If so, it
will register a corresponding fixup function that will run whenever it
tries to write back modified data to that bootblock. The function can
then modify any platform-specific headers as necessary.
As first supported platform, this patch adds a fixup for Qualcomm
platforms (specifically the header format used by sc7180), which
recalculates the bootblock body hash originally added by
util/qualcomm/createxbl.py.
(Note that this feature is not intended to support platform-specific
signature schemes like BootGuard directly in cbfstool. For anything that
requires an actual secret key, it should be okay if the user needs to
run a platform-specific signing tool on the final CBFS image before
flashing. This feature is intended for the normal unsigned case (which
on some platforms may be implemented as signing with a well-known key)
so that on a board that is not "locked down" in any way the normal use
case of manipulating an image with cbfstool and then directly flashing
the output file stays working with CONFIG_CBFS_VERIFICATION.)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I02a83a40f1d0009e6f9561ae5d2d9f37a510549a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41122
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support for the new CONFIG_CBFS_VERIFICATION feature to
cbfstool. When CBFS verification is enabled, cbfstool must automatically
add a hash attribute to every CBFS file it adds (with a handful of
exceptions like bootblock and "header" pseudofiles that are never read
by coreboot code itself). It must also automatically update the metadata
hash that is embedded in the bootblock code. It will automatically find
the metadata hash by scanning the bootblock for its magic number and use
its presence to auto-detect whether CBFS verification is enabled for an
image (and which hash algorithm to use).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I61a84add8654f60c683ef213b844a11b145a5cb7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41121
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch reduces some code duplication in cbfstool by switching it to
use the CBFS data structure definitions in commonlib rather than its own
private copy. In addition, replace a few custom helpers related to hash
algorithms with the official vboot APIs of the same purpose.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I22eae1bcd76d85fff17749617cfe4f1de55603f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41117
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
These sources are built but not used by cbfstool. The only .c file in
commonlib/ it really needs is fsp_relocate.c. Get rid of the others.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I6ebbb4161874f6279b6dbaffe7c3144226a6f9b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46253
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Vboot determines openssl through pkgconfig, so pointing its build
system to /bin/true makes the build not break unless it needs to use
valid information about openssl.
Vboot's use of openssl is only for some special features, mostly around
PKCS key format parsing and not needed by cbfstool. While cbfstool
can link vboot, it can't link with openssl because openssl's license
is deliberately incompatible with the GPL.
Change-Id: Ia3825f9625a1964d7cefc47ab3c3a8250ceefafb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42880
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Currently cbfstool cherry-picks a few files from vboot and hopes these
files will work standalone without any dependencies. This is pretty
brittle (for example, CL:2084062 will break it), and could be improved
by building the whole vboot library and then linking against it.
Therefore, this patch creates a new target $(VBOOT_HOSTLIB) and includes
it as a dependency for cbfstool and ifittool.
To prevent building the vboot lib twice (one for cbfstool and the other
for futility) when building coreboot tools together, add the variable
'VBOOT_BUILD' in Makefile to define a shared build path among different
tools so that vboot files don't need to be recompiled.
Also ignore *.o.d and *.a for vboot library.
BRANCH=none
BUG=none
TEST=make -C util/cbfstool
TEST=make -C util/futility
TEST=Run 'make tools' and make sure common files such as 2sha1.c are
compiled only once
TEST=emerge-nami coreboot-utils
Change-Id: Ifc826896d895f53d69ea559a88f75672c2ec3146
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In glibc feature control macros, _DEFAULT_SOURCE is the shorthand to
tell glibc to enable "all the default stuff", meaning POSIX, BSD and
System V interfaces. However, this macro is somewhat recent and older
glibc versions (e.g. 2.12) are still occasionally in use that don't
recognize it yet. For the benefits of users with these versions, let's
also enable the deprecated _BSD_SOURCE and _SVID_SOURCE macros which
essentially achieve the same thing. We must continue to define
_DEFAULT_SOURCE so that newer glibc versions don't throw a deprecation
warning.
This patch should make BSD-style byteswap macros like le32toh()
available on these older glibc versions.
Change-Id: I019bbcf738a1bcdccd7b299bdde29cd4d4ded134
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38638
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This patch creates a new commonlib/bsd subdirectory with a similar
purpose to the existing commonlib, with the difference that all files
under this subdirectory shall be licensed under the BSD-3-Clause license
(or compatible permissive license). The goal is to allow more code to be
shared with libpayload in the future.
Initially, I'm going to move a few files there that have already been
BSD-licensed in the existing commonlib. I am also exracting most
contents of the often-needed <commonlib/helpers.h> as long as they have
either been written by me (and are hereby relicensed) or have an
existing equivalent in BSD-licensed libpayload code. I am also
relicensing <commonlib/compression.h> (written by me) and
<commonlib/compiler.h> (same stuff exists in libpayload).
Finally, I am extracting the cb_err error code definitions from
<types.h> into a new BSD-licensed header so that future commonlib/bsd
code can build upon a common set of error values. I am making the
assumption here that the enum constants and the half-sentence fragments
of documentation next to them by themselves do not meet the threshold of
copyrightability.
Change-Id: I316cea70930f131e8e93d4218542ddb5ae4b63a2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/38420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
If the compiler fails to inline all the FORCE_INLINE functions, it will
complain.
Change-Id: I7b8349c9a3d53c47ac189f02b296600abac8a0cf
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37734
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbfstool depends on vboot headers, and vboot expects to be able to use
modern C features like _Static_assert(). It just so happens that it
doesn't do that in any headers included from cbfstool right now, but
that may change. Let's switch cbfstool to a newer version to prevent
that from becoming a problem.
Change-Id: I884e1bdf4ec21487ddb1bca57ef5dc2104cf8e0e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37666
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a utility to generate a compressed BIOS image for AMD Family 17h.
If the input is an elf file, the utility extracts the program portion
for compression. Otherwise the file is compressed as-is.
In modern AMD systems, the PSP brings up DRAM then uncompresses the
BIOS image into memory prior to x86 beginning execution. The PSP
supports a zlib engine, and interprets the first 256 bytes as a
header, where offset 0x14 containing the uncompressed size. For
further details, see AMD Platform Security Processor BIOS Architecture
Design Guide for AMD Family 17h Processors (NDA only, #55758).
BUG=b:127766506
TEST=Use with WIP Picasso
Change-Id: Id1c54e0a6dae9e4a0362c6635fe8b8aa48a369d8
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The ifittool is used instead. Drop old code.
Change-Id: I70fec5fef9ffd1ba3049badb398783f31aefb02f
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Add the IntelFirmwareInterfaceTable-tool to modify the FIT.
As cbfstool is overloaded with arguments, introduce a new tool
to only modify FIT, which brings it's own command line syntax.
Provide clean interface to:
* Clear FIT
* Add entry to CBFS file
* Add entry to REGION
* Delete entries
* Add support for types other than 1
* Add support to dump current table
* Add support for top-swap
* Sort entries by type
Most code is reused from existing cbfstool and functionality of cbfstool
is kept. It will be removed once the make system uses only ifittool.
Based on "Intel Trusted Execution Technology (Intel TXT) LAB Handout"
and https://github.com/slimbootloader/slimbootloader .
Change-Id: I0fe8cd70611d58823aca1147d5b830722ed72bd5
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
Should include vb2_sha.h header when SHA library functions or
constants are required. This replaces NEED_VB2_SHA_LIBRARY.
BUG=b:124141368, chromium:956474
TEST=make clean && make test-abuild
BRANCH=none
Change-Id: I9f32174dbf3de05fbe5279cb8017888757abf368
Signed-off-by: Joel Kitching <kitching@google.com>
Cq-Depend: chromium:1583820
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32454
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We recently changed all PACKED, __PACKED, __attribute__((packed)) ... to
__packed to gain some consistency. In cbfstool we use compiler.h to
provide that where necessary.
The cross compiler I use doesn't provide __packed by itself, but liblz4
doesn't compensate for that. Therefore include compiler.h, and to avoid
adding dependencies to non-liblz4 code, do so through the command line.
Change-Id: I581e45639ac3e103af7c16793e8effe2e632dec7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/20836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
This replaces all occurrences of a hardcoded vboot path to the
VBOOT_SOURCE variable, that may be overridden from the command line,
witch fallback to the source from 3rdparty.
Change-Id: Ia57d498d38719cc71e17060b76b0162c4ab363ed
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Due to a newer flex version with which the scanner was recreated, we
also have to make the compiler less strict on the generated code.
Change-Id: I3758c0dcb2f5661d072b54a30d6a4ebe094854e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/15482
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
FSP 2.0 uses the same relocate logic as FSP 1.1. Thus, rename
fsp1_1_relocate to more generic fsp_component_relocate that can be
used by cbfstool to relocate either FSP 1.1 or FSP 2.0
components. Allow FSP1.1 driver to still call fsp1_1_relocate which
acts as a wrapper for fsp_component_relocate.
Change-Id: I14a6efde4d86a340663422aff5ee82175362d1b0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14749
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
This reverts commit 272a1f05b9.
In Chrome OS this command's usage was dropped in favor of another
solution. As it's not used drop the support for it.
Change-Id: I58b51446d3a8b5fed7fc391025225fbe38ffc007
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14261
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit 17cb0370a7.
It’s the wrong thing to do, to just disable the warning. The code is
fixed for 32-bit user space now in Change-Id
I85bee25a69c432ef8bb934add7fd2e2e31f03662 (commonlib/lz4_wrapper: Use
correct casts to ensure valid calculations), so enable the warning
again.
Change-Id: I6d1c62c7b4875da8053c25e640c03cedf0ff2916
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/13772
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It seems that the exact behavior of -Wsign-compare changes between GCC
versions... some of them like the commonlib/lz4_wrapper.c code, and some
don't. Since we don't have a well-defined HOSTCC toolchain this slipped
through pre-commit testing. Explicitly silence the warning to ensure
cbfstool still builds on all systems.
Change-Id: I43f951301d3f14ce34dadbe58e885b82d21d6353
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13769
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For the purposes of maintaining integrity of a CBFS allow one to
hash a CBFS over a given region. The hash consists of all file
metadata and non-empty file data. The resulting digest is saved
to the requested destination region.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Integrated with glados chrome os build. vboot verification
works using the same code to generate the hash in the tooling
as well as at runtime on the board in question.
Change-Id: Ib0d6bf668ffd6618f5f73e1217bdef404074dbfc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12790
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch fixes compilation of cbfstool on Cygwin.
As reported in http://review.coreboot.org/#/c/10027
cbfstool on Cygwin likes to be compiled with -D_GNU_SOURCE.
That patch was abandoned because it would unwantedly turn on
more GNU extensions. Instead of doing that, only enable the
define on Cygwin, switch to -std=gnu99 instead of -std=c99 to
make fileno and strdup actually available.
A MINGW32 check that was forgotten in Makefile was copied over
from Makefile.inc to keep the two files in sync.
This patch has no impact on non-Windows builds.
Change-Id: I068b181d67daf9c7280110e64aefb634aa20c69b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11667
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
When adding an FSP blob relocate it to its final
destination. This allows FSP to not be hard coded in
the cbfs. In order for the include paths to work
correctly w/ the edk 2 headers we need to supply
a neutered ProcessorBind.h to match up with the
tool environment such that one can get the UEFI
Platform Initialization type definitions.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados and booted. Also added FSP with -b and manually
adjusted location in fsp cache-as-ram. Booted as well.
Change-Id: I830d93578fdf745a51195109cf18d94a83ee8cd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11778
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Older gcc versions throws a warning when a struct or union is
declared without a valid name (anonymous). This patch enables the
feature for older gcc versions so that no warning will be issued.
Change-Id: Idc5481f4d5723c5090a6f7d7dbb0686a737e11fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
They allow optimizing a verification of a whole CBFS image by only
dealing with the headers (assuming you choose to trust the hash
algorithm(s)).
The format allows for multiple hashes for a single file, and cbfstool
can handle them, but right now it can't generate such headers.
Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/,
but using the compatible file attribute format. vboot is now a hard
dependency of the build process, but we import it into the tree for
quite a while now.
Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11767
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
$(src) is not defined when building directly from the cbfs directory (that is,
when building cbfs as standalone, running make in the cbfs directory), so we
need to define the path to the commonlib include path relative to $(top).
Change-Id: I72e80b030d4a156ec653ded5ab1457b16f612526
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11706
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
It was added to an unused variable.
Change-Id: I869ffdda7e04b5c615931473c760d66b803fb98b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11673
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of going through the locate then add-stage
dance while linking romstage twice allow for adding romstage
with --xip flags to perform the relocation while adding it
into CBFS. The -P (page-size) and -a (alignment) parameters
were added as well so one could specify the necessary
parameters for x86 romstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I585619886f257e35f00961a1574009a51c28ff2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11669
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)
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>
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>
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 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 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>
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>
Furquan Shaikh