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>
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>
If some error happens in cbfs_payload_make_elf, the code jumps to "out",
and elf_writer_destroy(ew) is called. This may happen before an elf
writer is allocated.
To avoid accessing an uninitialized pointer, initialize ew to NULL;
elf_writer_destroy will perform no action in this case.
Change-Id: I5f1f9c4d37f2bdeaaeeca7a15720c7b4c963d953
Reported-By: Coverity Scan (1361475)
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16124
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Require the user to specify which architecture the payload/stage
was built for before extracting it.
Change-Id: I8ffe90a6af24e76739fd25456383a566edb0da7e
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/15438
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Implement function that automatically converts a SELF payload,
extracted from the CBFS, into an ELF file.
The code has been tested on the following payloads:
Working: GRUB, FILO, SeaBIOS, nvramcui, coreinfo and tint
Currently not working: none
Change-Id: I51599e65419bfa4ada8fe24b119acb20c9936227
Signed-off-by: Antonello Dettori <dettori.an@gmail.com>
Reviewed-on: https://review.coreboot.org/15139
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This avoids re-declaring common macros like ARRAY_SIZE, MIN, MAX and
ALIGN. Also removes the issues around including both files in any
tool.
Also, fix comparison error in various files by replacing int with
size_t.
Change-Id: I06c763e5dd1bec97e8335499468bbdb016eb28e5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14978
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>
cbfstool has a routine to deal with old images that may encourage it to
overwrite the master header. That routine is triggered for
"cbfstool add-master-header" prepared images even though these are not
at risk, and - worse - destroys the chain structure (through a negative
file length), so avoid touching such images.
Change-Id: I9d0bbe3e6300b9b9f3e50347737d1850f83ddad8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13672
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
While assembling CBFS images within the RW slots on Chrome OS
machines the current approach is to 'cbfstool copy' from the
RO CBFS to each RW CBFS. Additional fixups are required such
as removing unneeded files from the RW CBFS (e.g. verstage)
as well as removing and adding back files with the proper
arguments (FSP relocation as well as romstage XIP relocation).
This ends up leaving holes in the RW CBFS. To speed up RW
CBFS slot hashing it's beneficial to pack all non-empty files
together at the beginning of the CBFS. Therefore, provide
the 'compact' command which bubbles all the empty entries to
the end of the CBFS.
Change-Id: I8311172d71a2ccfccab384f8286cf9f21a17dec9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13479
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to more easily process the output of 'cbfstool print'
with other tools provide a -k option which spits out the
tab-separated header and fields:
Name Offset Type Metadata Size Data Size Total Size
ALIGN_UP(Offset + Total Size, 64) would be the start
of the next entry. Also, one can analzye the overhead
and offsets of each file more easily.
Example output (note: tabs aren't in here):
$ ./coreboot-builds/sharedutils/cbfstool/cbfstool test.serial.bin print
-r FW_MAIN_A -k
Performing operation on 'FW_MAIN_A' region...
Name Offset Type Metadata Size Data Size Total Size
cmos_layout.bin 0x0 cmos_layout 0x38 0x48c 0x4c4
dmic-2ch-48khz-16b.bin 0x500 raw 0x48 0xb68 0xbb0
dmic-2ch-48khz-32b.bin 0x10c0 raw 0x48 0xb68 0xbb0
nau88l25-2ch-48khz-24b.bin 0x1c80 raw 0x48 0x54 0x9c
ssm4567-render-2ch-48khz-24b.bin 0x1d40 raw 0x58 0x54 0xac
ssm4567-capture-4ch-48khz-32b.bin 0x1e00 raw 0x58 0x54 0xac
vbt.bin 0x1ec0 optionrom 0x38 0x1000 0x1038
spd.bin 0x2f00 spd 0x38 0x600 0x638
config 0x3540 raw 0x38 0x1ab7 0x1aef
revision 0x5040 raw 0x38 0x25e 0x296
font.bin 0x5300 raw 0x38 0x77f 0x7b7
vbgfx.bin 0x5ac0 raw 0x38 0x32f8 0x3330
locales 0x8e00 raw 0x28 0x2 0x2a
locale_en.bin 0x8e40 raw 0x38 0x29f6 0x2a2e
u-boot.dtb 0xb880 mrc_cache 0x38 0xff1 0x1029
(empty) 0xc8c0 null 0x64 0xadf4 0xae58
fallback/ramstage 0x17740 stage 0x38 0x15238 0x15270
(empty) 0x2c9c0 null 0x64 0xd2c4 0xd328
fallback/payload 0x39d00 payload 0x38 0x12245 0x1227d
cpu_microcode_blob.bin 0x4bf80 microcode 0x60 0x17000 0x17060
(empty) 0x63000 null 0x28 0x37cf98 0x37cfc0
Change-Id: I1c5f8c1b5f2f980033d6c954c9840299c6268431
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13475
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the introduction of flashmap cbfs alignment of files gets
broken because flashmap is located at the beginning of the flash
and cbfstool didn't take care about that offset.
This commit fixes the alignment in cbfs.
Change-Id: Idebb86d4c691b49a351a402ef79c62d31622c773
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/13417
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Adding new files overwrote the header with the empty file (ie 0xff),
so carve out some space.
BUG=chromium:445938
BRANCH=none
TEST=none
Change-Id: I91c292df381c2bac41c6cb9dda74dae99defd81d
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12789
Tested-by: build bot (Jenkins)
These need to go together, so the commit became a bit larger than
typial.
- Add an option -R for the copy source fmap region.
Use: cbfstool copy -r target-region -R source-region.
- Don't generate a CBFS master header because for fmap regions, we
assume that the region starts with a file header.
Use cbfstool add-master-header to add it afterwards, if necessary.
- Don't copy files of type "cbfs master header" (which are what cbfstool
add-master-header creates)
- Leave room for the master header pointer
- Remove -D command line option as it's no longer used.
BUG=chromium:445938
BRANCH=none
TEST=Manual test on image and integration test w/ bundle_firmware
changes.
CQ-DEPEND=CL:313770,CL:313771
Change-Id: I2a11cda42caee96aa763f162b5f3bc11bb7992f9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12788
Tested-by: build bot (Jenkins)
This allows adding support for FMAP based cbfstool copy more easily.
BUG=chromium:445938
Change-Id: I72e7bc4da7d27853e324400f76f86136e3d8726e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/12787
Tested-by: build bot (Jenkins)
If HOSTCC=clang, the -Wtautological-constant-out-of-range-compare is
set automaticaaly. That assume the value of type enum is in the defined
range. Then testing if a type enum is out of range causes build error.
Error:
coreboot/util/cbfstool/cbfs_image.c:1387:16: error:
comparison of constant 4 with expression of type 'enum vb2_hash_algorithm'
is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (hash_type >= CBFS_NUM_SUPPORTED_HASHES)
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
clang version:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Change-Id: I3e1722bf6f9553793a9f0c7f4e790706b6938522
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12330
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When using FMAP regions (with option -r) that were generated with a
master header (as done by cbfstool copy, eg. in Chrome OS' build
system), there were differences in interpretation of the master header's
fields.
Normalize for that by not sanity-checking the master header's size field
(there are enough other tests) and by dealing with region offsets
properly.
BUG=chromium:445938
BRANCH=tot
TEST=`cbfstool /build/veyron_minnie/firmware/image.dev.bin print -r
FW_MAIN_A` shows that region's directory (instead of claiming that
there's no CBFS at all, or showing an empty directory).
Change-Id: Ia840c823739d4ca144a7f861573d6d1b4113d799
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e5364d291f45e4705e83c0331e128e35ab226d3
Original-Change-Id: Ie28edbf55ec56b7c78160000290ef3c57fda0f0e
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/312210
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12416
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
With the previous ELF stage extract support the resulting
ELF files wouldn't handle rmodules correctly in that the
rmodule header as well as the relocations were a part of
the program proper. Instead, try an initial pass at
converting the stage as if it was an rmodule first. If it
doesn't work fall back on the normal ELF extraction.
TEST=Pulled an rmodule out of Chrome OS shellball. Manually
matched up the metadata and relocations.
Change-Id: Iaf222f92d145116ca4dfaa955fb7278e583161f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12222
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of dumping the raw stage data when cbfstool
extract is used on stage create an equivalent ELF file.
Because there isn't a lot of information within a stage
file only a rudimentary ELF can be created.
Note: this will break Chrome OS' current usage of extract
since the file is no longer a cbfs_stage. It's an ELF file.
TEST=Extracted romstage from rom.
Change-Id: I8d24a7fa4c5717e4bbba5963139d0d9af4ef8f52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12219
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to prepare allowing for one to extract a stage
into an ELF file provide an optional -m ARCH option. This
allows one to indicate to cbfstool what architecture type
the ELF file should be in.
Longer term each stage and payload will have an attribute
associated with it which indicates the attributes of
the executable.
Change-Id: Id190c9719908afa85d5a3b2404ff818009eabb4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to actually do something useful with the
resulting file after being extracted decompress stage
files' content. That way one can interrogate the
resulting file w/o having to decompress on the fly.
Note: This change will cause an unexpected change to
Chrome OS devices which package up individual stage
files in the RW slots w/o using cbfs. The result will
be that compressed stages are now decompressed.
Longer term is to turn these files into proper ELF
files on the way out.
Change-Id: I373ecc7b924ea21af8d891a8cb8f01fd64467360
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12174
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently cbfs stage files that are compressed do not have
the decompressed size readily available. Therefore there's
no good way to know actual size of data after it is
decompressed. Optionally return the decompressed data size
if requested.
Change-Id: If371753d28d0ff512118d8bc06fdd48f4a0aeae7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12173
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently, cbfstool regressed that removing a file from CBFS the space
is marked as empty but the filename is still shown, preventing adding a
file with the same name again. [1]
```
$ echo a > a
$ echo b > b
$ ./util/cbfstool/cbfstool test.rom create -m x86 -s 1024
Created CBFS (capacity = 920 bytes)
$ ./util/cbfstool/cbfstool test.rom add -f a -n a -t raw
$ ./util/cbfstool/cbfstool test.rom add -f b -n b -t raw
$ cp test.rom test.rom.original
$ ./util/cbfstool/cbfstool test.rom remove -n
$ diff -up <(hexdump -C test.rom.original) <(hexdump -C test.rom)
--- /dev/fd/63 2015-08-07 08:43:42.118430961 -0500
+++ /dev/fd/62 2015-08-07 08:43:42.114430961 -0500
@@ -1,4 +1,4 @@
-00000000 4c 41 52 43 48 49 56 45 00 00 00 02 00 00 00 50 |LARCHIVE.......P|
+00000000 4c 41 52 43 48 49 56 45 00 00 00 02 ff ff ff ff |LARCHIVE........|
00000010 00 00 00 00 00 00 00 28 61 00 00 00 00 00 00 00 |.......(a.......|
00000020 00 00 00 00 00 00 00 00 61 0a ff ff ff ff ff ff |........a.......|
00000030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
$ ./util/cbfstool/cbfstool test.rom add -f c -n c -t raw
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
c 0x0 raw 2
b 0x40 raw 2
(empty) 0x80 null 792
```
So it is “deteled” as the type changed. But the name was not changed to
match the *(empty)* heuristic.
So also adapt the name when removing a file by writing a null byte to
the beginning of the name, so that the heuristic works. (Though remove
doesn't really clear contents.)
```
$ ./util/cbfstool/cbfstool test.rom remove -n c
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
(empty) 0x0 null 2
b 0x40 raw 2
(empty) 0x80 null 792
```
[1] http://www.coreboot.org/pipermail/coreboot/2015-August/080201.html
Change-Id: I033456ab10e3e1b402ac2374f3a887cefd3e5abf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11632
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.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>
Up to now, if both fmap and a master header existed, the master header
was used. Now, use the master header only if no fmap is found.
Change-Id: Iafbf2c9dc325597e23a9780b495549b5d912e9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11629
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The cbfs_locate_entry() function had a hack in there which
assumed a struct cbfs_stage data was being added in addition
to the struct cbfs_file and name. Move that logic out to the
callers while still maintaining the logic for consistency.
The only impacted commands cbfs_add and cbfs_locate, but
those are using the default 'always adding struct cbfs_stage'
in addition to cbfs_file + name. Eventually those should be
removed when cbfs_locate is removed as cbfs_add has no smarts
related to the cbfs file type provided.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I2771116ea1ff439ea53b8886e1f33e0e637a79d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11668
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We had two mappings of filetype IDs to strings. We shouldn't.
Change-Id: I08e478b92f3316139f14294e50ede657c7d5fb01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Display compressed and decompressed sizes, as well as the compression
algorithm used, when a compressed file is encountered.
Change-Id: I13c2332702c4a5bec379e1ebda72753e06f8e135
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11359
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have tons of file types now that can be safely extracted.
It's pretty much only stages and payloads that aren't.
Change-Id: Ibf58a2c721f863d654537850c6f93d68a8a5bbeb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11360
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
My concern was that compilers may something stupid under the assumption
of a fixed struct size, but filename is already variable, so things are
okay.
Change-Id: I5348faf68f0a7993294e9de4c0b6c737278b28af
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They're passed as part of the header now.
Change-Id: I7cd6296adac1fa72e0708b89c7009552e272f656
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11327
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
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>
Daisuke Nojiri