In order to support booting a GNU/Linux payload on non x86, the FIT format
should be used, as it is the defacto standard on ARM.
Due to greater complexity of FIT it is not converted to simple ELF format.
Add support for autodecting FIT payloads and add them as new CBFS_TYPE 'fit'.
The payload is included as is, with no special header.
The code can determine the type at runtime using the CBFS_TYPE field.
Support for parsing FIT payloads in coreboot is added in a follow on
commit.
Compression of FIT payloads is not supported, as the FIT sections might be
compressed itself.
Starting at this point a CBFS payload/ can be either of type FIT or SELF.
Tested on Cavium SoC.
Change-Id: Ic5fc30cd5419eb76c4eb50cca3449caea60270de
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25860
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a new "rawcompress" command to cbfs-compression-tool,
that works exactly the same as "compress" except that it doesn't add the
custom 8-byte header to the file. This can be useful if you need to
compress something into a format that coreboot's decompression routines
can work with, but it's not supposed to go into CBFS.
Change-Id: I18a97a35bb0b0f71f3226f97114936dc81d379eb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds two minor improvements to the way cbfs-compression-tool
parses the compression algorithm type that is passed through the -t
option of the 'compress' subcommand. These improvements are intended
to prevent accidents and unexpected behavior when using the
cbfs-compression-tool, in particular in automated contexts such as a
Makefile rule.
In the first part of this patch, a return statement is inserted after
the 'if (algo->name == NULL)' check of the compress() function. This
causes the function to exit immediately and subsequently abort the
program when the algorithm type was not detected correctly. Previously,
execution would continue with the 'algo' pointer pointing to the zeroed
out stopper entry of the types_cbfs_compression[] array. The ultimate
effect of this would be to pass 0 as 'algo->type' to the
compression_function() function, which happens to be the same
enumeration value as is used for CBFS_COMPRESS_NONE, leading to a valid
compression function result that matches the behavior of no compression.
Thus, if a script calling cbfs-compression-tool compress contained a
typo in the -t parameter, it would continue running with an unintended
compression result rather than immediately exiting cleanly.
In the second part of this patch, the strcmp() function is replaced with
strcasecmp() when comparing 'algo->name' with the 'algoname' parameter
that was passed to the compress() function. strcasecmp() uses an
identical function signature as strcmp() and is thus suitable as a
drop-in replacement, but it differs in behavior: rather than only
returning a result of 0 when the two NULL-terminated input strings are
character by character identical, the strcasecmp() function applies a
weaker concept of identity where characters of the latin alphabet
(hexadecimal ranges 0x41 through 0x5a and 0x61 through 0x7a) are also
considered identical to other characters that differ from them only in
their case. This causes the -t parameter of cbfs-compression-tool
compress to also accept lowercase spellings of the available compression
algorithms, such as "lz4" instead of "LZ4" and "lzma" instead of "LZMA".
As an unintended but harmless side-effect, mixed-case spellings such as
"lZ4" or "LZmA" will also be recognized as valid compression algorithms.
(Note that since the character "4" (hexadecimal 0x34) of the "LZ4"
compression type name is not part of the above-mentioned ranges of latin
alphabet characters, no new substitutions become valid for that part of
the "LZ4" string with this patch.)
Change-Id: I375dbaeefaa0d4b0c5be81bf7668f8f330f1cf61
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/26389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
It seems this was never used and the usage doesn't mention it either.
Change-Id: I9240c0ed5453beff6ae46fae3748c68a0da30477
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/26324
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This reverts commit 717ba74836.
This breaks seabios and a few other payloads. This is not
ready for use.
Change-Id: I48ebe2e2628c11e935357b900d01953882cd20dd
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/26310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, adding a payload to CBFS using the build system, the warning
below is shown.
W: Unknown type 'payload' ignored
Update payload type from "simple elf" to "simple_elf" and rename the
word "payload" to "simple_elf" in all Makefiles.
Fixes: 4f5bed52 (cbfs: Rename CBFS_TYPE_PAYLOAD to CBFS_TYPE_SELF)
Change-Id: Iccf6cc889b7ddd0c6ae04bda194fe5f9c00e495d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/26240
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In preparation of having FIT payloads, which aren't converted to simple ELF,
rename the CBFS type payload to actually show the format the payload is
encoded in.
Another type CBFS_TYPE_FIT will be added to have two different payload
formats. For now this is only a cosmetic change.
Change-Id: I39ee590d063b3e90f6153fe655aa50e58d45e8b0
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/25986
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The layout command prints all FMAP regions in the final image among with
the region size. Extend this command to show the offset of each region
in the image.
Change-Id: I5f945ba046bd2f1cb50a93e90eb887f60c6fde8a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/25851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The list of supported architectures in the usage output of cbfstool is
currently hardcoded and outdated.
Use the arch_names array in common.c to provide and up-to-date list.
Change-Id: I3e7ed67c3bfd928b304c314fcc8e1bea35561662
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25590
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, "cbfstool -h | less" doesn't show any file types under
"TYPEs:". That's because the file types are printed with
print_supported_filetypes, which uses LOG, which prints to stderr. Use
printf print_supported_filetypes, and thus print to stdout, to make the
usage output more normal.
Change-Id: I800c9205c59383b63a640bc0798a1bd9117b0f99
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25589
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This automatically generates an FMAP region for the MRC_CACHE driver
which is easier to handle than a cbfsfile.
Adds some spaces and more comments to Makefile.inc to improve
readability.
Tested on Thinkpad x200 with some proof of concept patches.
Change-Id: Iaaca36b1123b094ec1bbe5df4fb25660919173ca
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23150
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial lookup for cbfs location for xip stages is implicitly
using the ELF size assuming it's relatively equivalent. However,
if the ELF that is being converted contains debug information or
other metadata then the location lookup can fail because the ELF is
considerably bigger than the real footprint.
BUG=b:70801221
Change-Id: I47024dcd8205a09885d3a3f76e255eb5e3c55d9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/22936
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds '-p' to the 'add' command. It allows the add
command to specify the size of the padding added with the file
being added. This is useful to reserve an extra space in case
the file is too big to be relocated.
BUG=b:68660966
BRANCH=none
TEST=emerge-fizz coreboot &&
cbfstool image.bin add -n ecrw -f EC_RW.bin -p 0x10 ...
Verify image.bin has extra space in the file header.
Change-Id: I64bc54fd10a453b4da467bc69d9590e61b0f7ead
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/22239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch adds a column to the print command to show the compression
algorithm used for the file.
Name Offset Type Size Comp
fallback/romstage 0x0 stage 56236 none
ecrw 0xf2380 raw 62162 LZMA (131072 decompressed)
BUG=b:66956286
BRANCH=none
TEST=Run 'cbfstool image.bin print'
Change-Id: I4bbb60ab467adac4ae5486ddafec86ad9682a40e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/22196
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It does the opposite to "expand", removing a trailing empty file from
CBFS. It also returns the size of the CBFS post processing on stdout.
BUG=b:65853903
BRANCH=none
TEST=`cbfstool test.bin truncate -r FW_MAIN_A` removes the trailing
empty file in FW_MAIN_A. Without a trailing empty file, the region is
left alone (tested using COREBOOT which comes with a master header
pointer).
Change-Id: I0c747090813898539f3428936afa9d8459adee9c
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/21608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
vboot images come with multiple regions carrying CBFS file systems. To
expedite hashing (from slow flash memory), the FW_MAIN_* regions are
truncated since they typically have pretty large unused space at the
end that is of no interest.
For test purposes it can be useful to re-engage that space, so add a
command that creates a new empty file entry covering that area (except
for the last 4 bytes for the master header pointer, as usual).
BUG=b:65853903
BRANCH=none
TEST=`cbfstool test.bin expand -r FW_MAIN_A` creates a new empty file of
the expected size on a Chrome OS firmware image.
Change-Id: I160c8529ce4bfcc28685166b6d9035ade4f6f1d1
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/21598
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
An internal index `i` was previously allocated as
Elf64_Half which is uint16_t. Bumping to uint64_t
increases the number of allowed symbols and prevents
a segfault in processing a larger ramstage.debug file.
Also introduce a separate counter for the number of sections.
Change-Id: I9ad2f64c452cef2e7bf957f766600891cb5ae798
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/21360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Using sys/cdefs.h would come to mind,
however this include would not solve the build error.
Built and runtime tested on FreeBSD 12.0-CURRENT, r322031
Change-Id: I6ec9bc7fea72aa69a41439e002f381bd5e5b6bc6
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: https://review.coreboot.org/20924
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
the __must_check function attribute is pretty much straight from the
linux kernel - used to encourage callers to consume function return
values.
Change-Id: I1812d957b745d6bebe2a8d34a9c4862316aa8530
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://review.coreboot.org/20881
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>
It's rather normal that a few bytes are skipped.
Change-Id: I9371afdbb3ad05de7645bfbf257e4f4bfa2feddb
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/20469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's irritating when adding tianocore payloads - those are not
ELF, but that's deliberate.
Change-Id: I76d9367b28545348f526e5f0b8216f9ff2a3d636
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/20468
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The word 'coreboot' should always be written in lowercase, even at the
start of a sentence.
Change-Id: I0a024d82d331c0794fe087e440b4e1924129a13c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20030
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GCC7 has a new feature called -Wimplicit-fallthrough enabled by
default which checks for fallthrough in switch statements which is a
common error. When a fallthrough is actually intended a comment saying
so will satisfy GCC.
Fixes cbfstool not building with GCC7.
Change-Id: I83252fc96be7ce0971d4251b0fc88fbbd7440e71
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/20036
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If CONSOLE_SPI_FLASH config is enabled, we write the cbmem
messages to the 'CONSOLE' area in FMAP which allows us to grab the
log when we read the flash.
This is useful when you don't have usb debugging, and
UART lines are hard to find. Since a failure to boot would
require a hardware flasher anyways, we can get the log
at the same time.
This feature should only be used when no alternative is
found and only when we can't boot the system, because
excessive writes to the flash is not recommended.
This has been tested on purism/librem13 v2 and librem 15 v3 which
run Intel Skylake hardware. It has not been tested on other archs
or with a driver other than the fast_spi.
Change-Id: I74a297b94f6881d8c27cbe5168f161d8331c3df3
Signed-off-by: Youness Alaoui <youness.alaoui@puri.sm>
Reviewed-on: https://review.coreboot.org/19849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Not all systems have sizeof(time_t) == sizeof(long), so
cast the delta here to a long to match the %ld format.
Change-Id: If235577fc35454ddb15043c5a543f614b6f16a9e
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://review.coreboot.org/19902
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@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>
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>
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>
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>
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)
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>
We never specified what value add-int should write by default.
Change-Id: I240be4842fc374690c4a718fc4d8f0a03d63003c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/17796
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ic5a3be1128f2f9a53d21e0a2c577192962260df6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/17018
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a --force/-F option and enable it for cbfstool write, where it has
the effect of not testing if the fmap region contains a CBFS or if the
data to write is a CBFS image.
Change-Id: I02f72841a20db3d86d1b67ccf371bd40bb9a4d51
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16998
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
We were not setting the init_size for linux payloads.
A proper value of init_size is required if the kernel
is x86_64.
This is tested in qemu and fixes the observed problem
that 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda and later would not
boot, and would in fact fail in head_64.S.
Change-Id: I254c13d16b1e014a6f1d4fd7c39b1cfe005cd9b0
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://review.coreboot.org/16781
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch adds functionality to compile a C data structure into a raw
binary file, add it to CBFS and allow coreboot to load it at runtime.
This is useful in all cases where we need to be able to have several
larger data sets available in an image, but will only require a small
subset of them at boot (a classic example would be DRAM parameters) or
only require it in certain boot modes. This allows us to load less data
from flash and increase boot speed compared to solutions that compile
all data sets into a stage.
Each structure has to be defined in a separate .c file which contains no
functions and only a single global variable. The data type must be
serialization safe (composed of only fixed-width types, paying attention
to padding). It must be added to CBFS in a Makefile with the 'struct'
file processor.
Change-Id: Iab65c0b6ebea235089f741eaa8098743e54d6ccc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16272
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Patrick Rudolph