Commit Graph

37 Commits

Author SHA1 Message Date
Aaron Durbin 71c60ca482 util/cbfstool: add 'compact' command
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>
2016-01-28 19:25:57 +01:00
Aaron Durbin 5dc628a2ef util/cbfstool: add machine parseable print
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>
2016-01-28 19:25:48 +01:00
Patrick Georgi 214e4af102 cbfstool: Use buffer over offset/size pair for cbfs_copy_instance
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)
2016-01-06 01:12:12 +01:00
Patrick Georgi a73b93157f tree: drop last paragraph of GPL copyright header
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>
2015-10-31 21:37:39 +01:00
Aaron Durbin 1762502929 cbfstool: add optional -m ARCH to extract
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>
2015-10-29 16:59:54 +01:00
Patrick Georgi 89f20340d5 cbfstool: Add support for hashes as file metadata
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>
2015-10-01 20:14:26 +00:00
Aaron Durbin d7339411a9 cbfstool: provide metadata size to cbfs_locate_entry()
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>
2015-09-16 14:11:03 +00:00
Patrick Georgi 2c61506630 cbfstool: add extended file attributes for cbfs_file
cbfs_file_first_attr(struct cbfs_file *) and
cbfs_file_next_attr(struct cbfs_file *, struct cbfs_file_attribute *)
help navigate through extended attributes.

cbfs_add_file_attr(header, tag, size) adds a new file attribute to
header.

Change-Id: I325965286c44f31abd95df684d340cebb0e68b75
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10934
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-01 14:51:09 +00:00
Patrick Georgi f5252f378b cbfstool: don't pass header_size as separate argument (part 2)
It's already present inside struct cbfs_file

Change-Id: Ic9682e93c3d208e2ed458940e4a9f9f5a64b6e98
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11333
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-27 15:07:00 +00:00
Patrick Georgi a60e7b6da5 cbfstool: use struct cbfs_file * instead of void *
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>
2015-08-27 15:01:39 +00:00
Patrick Georgi e590358064 cbfstool: cbfs_add_entry() doesn't need to know filename or type
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>
2015-08-27 15:01:12 +00:00
Patrick Georgi 3ba501b86d cbfstool: move cbfs_file header creation further up the call chain
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>
2015-08-26 12:22:14 +00:00
Patrick Georgi 57edf16be5 cbfstool: factor out creating a cbfs file header
We will want to create headers that live outside the final image at some point
(eg. to build the file before we even know where to place it).

Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11219
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:09:52 +02:00
Patrick Georgi edf25d9076 cbfstool: Make cbfs_create_empty_entry build a more complete header
Pass the file type into it instead of creating an entry, then modifying the
header field again after the fact.

Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11218
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:09:33 +02:00
Patrick Georgi 11ee08f1f1 cbfstool: expose cbfs_calculate_file_header_size()
Headers vary in size soon, and more places need to be able to calculate their
size.

Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11214
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:08:30 +02:00
Patrick Georgi e60b55a570 cbfstool: allow passing a precalculated header size into cbfs_add_entry()
This is in preparation of creating the cbfs_file header much earlier
in the process. For now, size is enough because lots of things need to
move before it makes sense to deal with cbfs_file at a higher level.

Change-Id: I47589247c3011cb828170eaa10ef4a1e0f85ab84
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:08:15 +02:00
Sol Boucher ec42486055 cbfstool: Factor out compression algorithm list
Parse compression algorithm arguments using a single list.

Change-Id: Idc5b14a53377b29964f24221e42db6e09a497d48
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-16 17:39:33 +02:00
Patrick Georgi b890a1228d Remove address from GPLv2 headers
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.

However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.

util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.

$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
	-a \! -name \*.patch \
	-a \! -name \*_shipped \
	-a \! -name LICENSE_GPL \
	-a \! -name LGPL.txt \
	-a \! -name COPYING \
	-a \! -name DISCLAIMER \
	-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +

Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-05-21 20:50:25 +02:00
Sol Boucher 67d5998d97 cbfstool: Support top-aligned addresses for new-format images
The cbfstool handling of new-style FMAP-driven "partitioned" images
originally disallowed the use of x86-style top-aligned addresses with
the add.* and layout actions because it wasn't obvious how they should
work, especially since the normal addressing is done relative to each
individual region for these types of images. Not surprisingly,
however, the x86 portions of the build system make copious use of
top-aligned addresses, so this allows their use with new images and
specifies their behavior as being relative to the *image* end---not
the region end---just as it is for legacy images.

Change-Id: Icecc843f4f8b6bb52aa0ea16df771faa278228d2
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10136
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-13 22:23:37 +02:00
Sol Boucher 67a0a864be cbfstool: New image format w/ required FMAP and w/o CBFS master header
These new-style firmware images use the FMAP of the root of knowledge
about their layout, which allows them to have sections containing raw
data whose offset and size can easily be determined at runtime or when
modifying or flashing the image. Furthermore, they can even have
multiple CBFSes, each of which occupies a different FMAP region. It is
assumed that the first entry of each CBFS, including the primary one,
will be located right at the start of its region. This means that the
bootblock needs to be moved into its own FMAP region, but makes the
CBFS master header obsolete because, with the exception of the version
and alignment, all its fields are redundant once its CBFS has an entry
in the FMAP. The version code will be addressed in a future commit
before the new format comes into use, while the alignment will just be
defined to 64 bytes in both cbfstool and coreboot itself, since
there's almost no reason to ever change it in practice. The version
code field and all necessary coreboot changes will come separately.

BUG=chromium:470407
TEST=Build panther and nyan_big coreboot.rom and image.bin images with
and without this patch, diff their hexdumps, and note that no
locations differ except for those that do between subsequent builds of
the same codebase. Try working with new-style images: use fmaptool to
produce an FMAP section from an fmd file having raw sections and
multiple CBFSes, pass the resulting file to cbfstool create -M -F,
then try printing its layout and CBFSes' contents, add and remove CBFS
files, and read and write raw sections.
BRANCH=None

Change-Id: I7dd2578d2143d0cedd652fdba5b22221fcc2184a
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 8a670322297f83135b929a5b20ff2bd0e7d2abd3
Original-Change-Id: Ib86fb50edc66632f4e6f717909bbe4efb6c874e5
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265863
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10135
Tested-by: build bot (Jenkins)
2015-05-13 22:19:59 +02:00
Sol Boucher e3260a042f cbfstool: Restructure around support for reading/writing portions of files
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>
2015-05-08 20:25:20 +02:00
Sol Boucher 3e060ed112 cbfstool: Fix leak in cbfs_image struct initialization
This patches a memory leak on every struct cbfs_image creation that
was introduced by c1d1fd850e. Since that
commit, the CBFS master header has been copied to a separate buffer so
that its endianness could be fixed all at once; unfortunately, this
buffer was malloc()'d but never free()'d. To address the issue, we
replace the structure's struct cbfs_header * with a struct cbfs_header
to eliminate the additional allocation.

Change-Id: Ie066c6d4b80ad452b366a2a95092ed45aa55d91f
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10130
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:23:23 +02:00
Sol Boucher 0e53931fee cbfstool: Clean up in preparation for adding new files
This enables more warnings on the cbfstool codebase and fixes the
issues that surface as a result. A memory leak that used to occur
when compressing files with lzma is also found and fixed.
Finally, there are several fixes for the Makefile:
 - Its autodependencies used to be broken because the target for
   the .dependencies file was misnamed; this meant that Make
   didn't know how to rebuild the file, and so would silently
   skip the step of updating it before including it.
 - The ability to build to a custom output directory by defining
   the obj variable had bitrotted.
 - The default value of the obj variable was causing implicit
   rules not to apply when specifying a file as a target without
   providing a custom value for obj.
 - Add a distclean target for removing the .dependencies file.

BUG=chromium:461875
TEST=Build an image with cbfstool both before and after.
BRANCH=None

Change-Id: I951919d63443f2b053c2e67c1ac9872abc0a43ca
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 49293443b4e565ca48d284e9a66f80c9c213975d
Original-Change-Id: Ia7350c2c3306905984cfa711d5fc4631f0b43d5b
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257340
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9937
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-04-25 12:14:25 +02:00
Vadim Bendebury 45e5997c61 cbfstool: clean up source code
The following changes were made:

- order commands and options definitions alphabetically
- do not report errors at cbfs_image_from_file() call sites - the
  error is reported by the function itself
- remove the unused parameter in cbfs_create_empty_entry() prototype

BRANCH=storm
BUG=none
TEST=compiled cbfstool, built a storm image, observed that the image
     still boots

Change-Id: I31b15fab0a63749c6f2d351901ed545de531eb39
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a909a50e03be77f972b1a497198fe758661aa9f8
Original-Change-Id: I4b8898dbd44eeb2c6b388a485366e4e22b1bed16
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237560
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18 08:50:38 +02:00
Vadim Bendebury 5e273a4577 cbfstool: add a command to duplicate a cbfs instance
The new command allows to create a file where the original CBFS image
is duplicated at a different offset.

The required options of the new command are -D, the offset where the
copy CBFS header is placed, and -s, the size of the new CBFS copy.

When a CBFS is copied, the bootblock area of the source CBFS is
ignored, as well as empty and deleted files in the source CBFS. The
size of the destination CBFS is calculated as the rombase size of the
source CBFS less the bootblock size.

The copy instance can be created in the image only above the original,
which rules out the use of this new command for x86 images. If
necessary, this limitation could be addressed later.

As with other cbfstool commands, unless explicitly specified the
lowest CBFS instance in the image is considered the source. If
necessary, the user can specify the source CBFS using the -H option.

BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run multiple cbfstool commands on a storm image:
  $ cd /tmp
  $ cp /build/storm/firmware/image.serial.bin storm.bin
  $ cbfstool storm.bin print
  storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
  alignment: 64 bytes, architecture: arm

  Name                           Offset     Type         Size
  cdt.mbn                        0x8700     raw          416
  ddr.mbn                        0x8900     raw          25836
  rpm.mbn                        0xee40     raw          78576
  tz.mbn                         0x22180    raw          85360
  fallback/verstage              0x36f40    stage        41620
  fallback/romstage              0x41240    stage        19556
  fallback/ramstage              0x45f00    stage        25579
  config                         0x4c340    raw          2878
  fallback/payload               0x4cec0    payload      64811
  u-boot.dtb                     0x5cc40    (unknown)    2993
  (empty)                        0x5d840    null         75608
  $ cbfstool storm.bin copy -D 0x420000
  E: You need to specify -s/--size.
  $ cbfstool  storm.bin copy -D 0x420000 -s 0x70000
  $ cbfstool  storm.bin print
  W: Multiple (2) CBFS headers found, using the first one.
  storm.bin: 8192 kB, bootblocksize 34472, romsize 458752, offset 0x8700
  alignment: 64 bytes, architecture: arm

  Name                           Offset     Type         Size
  cdt.mbn                        0x8700     raw          416
  ddr.mbn                        0x8900     raw          25836
  rpm.mbn                        0xee40     raw          78576
  tz.mbn                         0x22180    raw          85360
  fallback/verstage              0x36f40    stage        41620
  fallback/romstage              0x41240    stage        19556
  fallback/ramstage              0x45f00    stage        25579
  config                         0x4c340    raw          2878
  fallback/payload               0x4cec0    payload      64811
  u-boot.dtb                     0x5cc40    (unknown)    2993
  (empty)                        0x5d840    null         75608
  cbfstool  storm.bin print  -H 0x420000
  storm.bin: 8192 kB, bootblocksize 0, romsize 4784128, offset 0x420040
  alignment: 64 bytes, architecture: arm

  Name                           Offset     Type         Size
  cdt.mbn                        0x420040   raw          416
  ddr.mbn                        0x420240   raw          25836
  rpm.mbn                        0x426780   raw          78576
  tz.mbn                         0x439ac0   raw          85360
  fallback/verstage              0x44e880   stage        41620
  fallback/romstage              0x458b80   stage        19556
  fallback/ramstage              0x45d840   stage        25579
  config                         0x463c80   raw          2878
  fallback/payload               0x464800   payload      64811
  u-boot.dtb                     0x474580   (unknown)    2993
  (empty)                        0x475180   null         110168
  $ cbfstool storm.bin remove -n config -H 0x420000
  $ cbfstool  storm.bin copy  -H 0x420000 -D 0x620000 -s 0x70000
  $ cbfstool  storm.bin print -H 0x620000
  storm.bin: 8192 kB, bootblocksize 0, romsize 6881280, offset 0x620040
  alignment: 64 bytes, architecture: arm

  Name                           Offset     Type         Size
  cdt.mbn                        0x620040   raw          416
  ddr.mbn                        0x620240   raw          25836
  rpm.mbn                        0x626780   raw          78576
  tz.mbn                         0x639ac0   raw          85360
  fallback/verstage              0x64e880   stage        41620
  fallback/romstage              0x658b80   stage        19556
  fallback/ramstage              0x65d840   stage        25579
  fallback/payload               0x663c80   payload      64811
  u-boot.dtb                     0x673a00   (unknown)    2993
  (empty)                        0x674600   null         113112

  $ cbfstool /build/storm/firmware/image.serial.bin extract -n fallback/payload -f payload1
  [..]
  $ cbfstool storm.bin extract -H 0x620000  -n fallback/payload -f payload2
  [..]
  $ diff payload1 payload2

Change-Id: Ieb9205848aec361bb870de0d284dff06c597564f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b8d3c1b09a47ca24d2d2effc6de0e89d1b0a8903
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Change-Id: I227e607ccf7a9a8e2a1f3c6bbc506b8d29a35b1b
Original-Reviewed-on: https://chromium-review.googlesource.com/237561
Reviewed-on: http://review.coreboot.org/9742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18 08:48:22 +02:00
Vadim Bendebury 458a12e52b cbfstool: allow user to explicitly specify header location
There potentially could be multiple CBFS instances present in the
firmware image. cbfstool should be able to operate on any of them, not
just the first one present.

To accomplish that, allow all CBFS commands to accept the -H parameter
(which specifies the exact CBFS header location in the image).

If this parameter is specified, the image is not searched for the CBFS
header, only the specified location is checked for validity, If the
location is valid, it is considered to be the CBFS header, if not -
the tool exits with an error status.

Note, that default behavior of the tool does not change.

BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run the following experiments:

  - examined an image with three CBFS instances, was able to print all
    of them.

  - built a rambi coreboot image and tried the following (cbfstool output abbreviated):

  $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print
  coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
  alignment: 64 bytes, architecture: x86

  Name                           Offset     Type         Size
  cmos_layout.bin                0x700000   cmos_layout  1164
  ...
  (empty)                        0x7ec600   null         77848
  $ \od -tx4 -Ax /build/rambi/firmware/coreboot.rom | tail -2
  7ffff0 fff67de9 000000ff fff6dfe9 fffff650
  800000
  $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print  -H 0x7ff650
  coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
  alignment: 64 bytes, architecture: x86

  Name                           Offset     Type         Size
  cmos_layout.bin                0x700000   cmos_layout  1164
  ...
  (empty)                        0x7ec600   null         77848
  $ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print  -H 0x7ff654
  E: /build/rambi/firmware/coreboot.rom does not have CBFS master header.
  E: Could not load ROM image '/build/rambi/firmware/coreboot.rom'.
  $

Change-Id: I64cbdc79096f3c7a113762b641305542af7bbd60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86b88222df6eed25bb176d653305e2e57e18b73a
Original-Change-Id: I486092e222c96c65868ae7d41a9e8976ffcc93c4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237485
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-18 08:48:05 +02:00
Alexandru Gagniuc c1d1fd850e cbfstool: Deserialize CBFS master header when reading image
Rather than  using [hn]to[nh] whenever accessing a member of the CBFS
header, deserialize the header when opening the CBFS image. The header
is no longer a pointer inside the CBFS buffer, but a separate struct,
a copy of the original header in a host-friendly format. This kills
more of the ntohl usage.

Change-Id: I5f8a5818b9d5a2d1152b1906249c4a5847d02bac
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5121
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-11 20:14:39 +01:00
Ronald G. Minnich b5adeee1cc cbfstool: add code to serialize the header using the new xdr functions
This change adds a header serialization function. Programmers can thus just
set up a header as needed, without worrying about forgetting if and how to
use the [hn]to[hn]* functions.

In the long term, we will work to remove swab.h, i.e. we need to get to the
point where programmers don't have to try to remember [hn]to[nh]* and where
it goes. To date, even the best programmers we have have made an error with
those functions, and those errors have persisted for 6 or 7 years now. It's
very easy to make that mistake.

BUG=None
TEST=Build a peppy image and verify that it's bit for bit the same. All
     chromebooks use this code and build and boot correctly.
BRANCH=None

Change-Id: I0f9b8e7cac5f52d0ea330ba948650fa0803aa0d5
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181552
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/5100
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-02 23:48:18 +01:00
Hung-Te Lin e4ea2ca18d cbfstool locate: Implement alignment switch --align/-a
cbfstool usage change:
 "-a" for "cbfstool locate" can specify base address alignment.

To support putting a blob in aligned location (ex, microcode needs to be aligned
in 0x10), alignment (-a) is implemented into "locate" command.

Verified by manually testing a file (324 bytes) with alignment=0x10:
 cbfstool coreboot.rom locate -f test -n test -a 0x10
 # output: 0x71fdd0
 cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0
 cbfstool coreboot.rom print -v -v
 # output: test                           0x71fd80   raw          324
 # output:  cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144

Also verified to be compatible with old behavior by building i386/axus/tc320
(with page limitation 0x40000):
 cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
 # output: 0x44
 cbfstool coreboot.rom locate -f x.bin -n romstage -P 0x40000 -a 0x30
 # output: 0x60

Change-Id: I78b549fe6097ce5cb6162b09f064853827069637
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2824
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-20 05:47:32 +01:00
Hung-Te Lin 408aefd176 cbfstool: Fix crash on image without bootblock in end of ROM.
On platforms with CBFS data filling end of ROM image without bootblock in the
end (ex, ARM), calculation of "next valid entry" may exceed ROM image buffer in
memory and raise segmentation fault when we try to compare its magic value.

To fix this, always check if the entry address is inside ROM image buffer.

Verified to build and boot successfully on qemu/x86 and armv7/snow.

Change-Id: I117d6767a5403be636eea2b23be1dcf2e1c88839
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2330
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-09 06:30:10 +01:00
Hung-Te Lin 5f3eb26d85 cbfstool: Use cbfs_image api for "add" command.
The "add" command is compatible with all legacy usage. Also, to support
platforms without top-aligned address, all address-type params (-b, -H, -l) can
now be ROM offset (address < 0x8000000) or x86 top-aligned address (address >
0x80000000).

Example:
	cbfstool coreboot.rom add -f config -n config -t raw -b 0x2000
	cbfstool coreboot.rom add -f stage -n newstage -b 0xffffd1c0

Verified boot-able on both ARM(snow) and x86(QEMU) system.

Change-Id: I485e4e88b5e269494a4b138e0a83f793ffc5a084
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2216
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:27:13 +01:00
Hung-Te Lin f56c73f1e1 cbfstool: Use cbfs_image API for "create" command.
Usage Changes: To support platforms with different memory layout, "create" takes
two extra optional parameters:

    "-b": base address (or offset) for bootblock. When omitted, put bootblock in
          end of ROM (x86  style).
    "-H": header offset. When omitted, put header right before bootblock,
          and update a top-aligned virtual address reference in end of ROM.

  Example: (can be found in ARM MAkefile):
    cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \
             -a 64 -b 0x0000 -H 0x2040 -o 0x5000

Verified to boot on ARM (Snow) and X86 (QEMU).

Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2214
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:27:08 +01:00
Hung-Te Lin 215d1d7c9b cbfstool: Use cbfs_image API for "locate" command.
To support platforms without top-aligned address mapping like ARM, "locate"
command now outputs platform independent ROM offset by default.  To retrieve x86
style top-aligned virtual address, add "-T".

To test:
	cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T
	# Example output: 0xffffdc10

Change-Id: I474703c4197b36524b75407a91faab1194edc64d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2213
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:27:03 +01:00
Hung-Te Lin c03d9b0c43 cbfstool: Use cbfs_image API for "remove" command.
To delete a component (file) from existing CBFS ROM image.

To test:
	cbfstool coreboot.rom remove -n fallback/romstage
	# and compare with old cbfstool output result.

Change-Id: If39ef9be0b34d8e3df77afb6c9f944e02f08bc4e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2208
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:26:53 +01:00
Hung-Te Lin 0f8af71f1a cbfstool: Use cbfs_image API for "extract" command.
Change the "extract" command to use cbfs_export_entry API. Nothing changed in
its usage.

To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the
raw type file is correctly extracted.

Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2207
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:25:20 +01:00
Hung-Te Lin 3bb035b095 cbfstool: Use cbfs_image API for "print" command.
Process CBFS ROM image by new cbfs_image API.
To verify, run "cbfstool coreboot.rom print -v" and compare with old cbfstool.

Change-Id: I3a5a9ef176596d825e6cdba28a8ad732f69f5600
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2206
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:25:13 +01:00
Hung-Te Lin eab2c81949 cbfstool: Add cbfs_image new CBFS image manipulation API.
Current cbfstool implementation is relying on global variables to pass processed
data, and the calculation of address is based on x86 architecture (ex, always
assuming 0x0000 as invalid address), not easy to be used on platforms without
top-aligned memory mapping. This CL is a first step to start a new cbfstool
without global variables, and to prevent assuming memory layout in x86 mode.

The first published APIs are for reading and writing existing CBFS ROM image
files (and to find file entries in a ROM file).

Read cbfs_image.h for detail usage of each API function.

Change-Id: I28c737c8f290e51332119188248ac9e28042024c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2194
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:25:02 +01:00