Commit Graph

130 Commits

Author SHA1 Message Date
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
Aaron Durbin 539aed0646 cbfstool: decompress stage files on extraction
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>
2015-10-27 17:52:57 +01:00
Aaron Durbin 5213c53f6f cbfstool: have decompress functions provide ouput data size
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>
2015-10-25 13:23:15 +01:00
Aaron Durbin 285111f822 cbfstool: Fix removing and adding file with same name
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>
2015-10-17 06:57:50 +00:00
Paul Menzel 831bbe8446 cbfstool/cbfs_image.c: Just use one space before `=`
Change-Id: Id31c889d1e83e7ddfb0f0f98b78601f37b71cfa2
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11631
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-10-17 06:57:42 +00: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
Patrick Georgi 2f953d304e cbfstool: prefer fmap data over cbfs master header if it exists
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>
2015-09-28 10:13:33 +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 dc37dab7fd cbfstool: drop extra copy of filetype->string map
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>
2015-09-14 16:27:36 +00:00
Patrick Georgi 23aeaff41b cbfstool: implement decompression support for cbfstool extract
Change-Id: I5142b03d3c3e028eeb179f225848f762186f94a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11363
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-01 14:52:02 +00:00
Patrick Georgi a71c83fa5c cbfstool: factor out parsing compression file attributes
cbfstool extract also needs it.

Change-Id: I8302bb18c5f797eb0a43ec4e4269790f3d49a896
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11361
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-09-01 14:51:41 +00:00
Patrick Georgi c82725c5b9 cbfstool: support compressed files in cbfstool print
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>
2015-09-01 14:51:29 +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 011b0b3af8 cbfstool: update warning on cbfstool extract
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>
2015-08-27 15:07:36 +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 d5a4afa63d cbfstool: don't pass header_size as separate argument
It's already present inside struct cbfs_file

Change-Id: Ib10663c6601aa02e07b868e440f05da02af9c2d9
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11332
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-27 15:06:51 +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 19c80b2391 cbfstool: drop size argument to cbfs_add_entry_at
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>
2015-08-26 12:21:30 +00:00
Patrick Georgi ae7efb9257 cbfstool: cut down on the debug output
Change-Id: I9a0aad42e4eb67a07c939d7cfa0d2d80838412bb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11323
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-26 12:21:20 +00:00
Patrick Georgi 7a33b53dc0 cbfstool: Don't patch cbfs_file->len, it's already set correctly
->len used to be set to the file data length plus the size of the
padding used for the cbfs_file header. This isn't the case anymore,
so no patching of this field is necessary anymore.

->offset still needs to be patched in that case because its final
value can only be determined when the file's actual location is known.

Change-Id: I1037885f81b4ed3b68898dd7d0e515cf7a9c90a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11322
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-26 12:20:55 +00:00
Patrick Georgi bc39690900 cbfstool: drop unused arguments in internal function
Change-Id: Ie4edc5f9c96ffba7dcf8b974c56851658b9538e4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11321
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-26 12:20:39 +00:00
Patrick Georgi 62c014bcf3 cbfstool: start moving cbfs_file header creation up the call chain
Up to now cbfstool creates the cbfs_file header at the latest possible
time, which is unsuitable when the idea is to add further fields to it
that need to be configured earlier.

Thus, have it ripple up the call chain.

Change-Id: I7c160681c31818bc550ed2098008146043d0ee01
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-26 12:20:24 +00:00
Patrick Georgi 4eb8abeb85 cbfstool: more descriptive variable name
"target", for what? It's the offset where the file header of the currently
added file will be located, name it as such.

Change-Id: I382f08f81991faf660e217566849773d9a7ec227
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-26 12:20:08 +00:00
Patrick Georgi dd2d3f933a cbfstool: unify actual file creation
After the preparation in earlier commits, it is now possible to handle the
more general case of position independent files using the special code path
for fixed location files.

This leads to a single place where non-empty cbfs file headers are actually
written into the image, allowing us to move it up the chain more easily.

Change-Id: I8c1fca5e4e81c20971b2960c87690e982aa3e274
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11222
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:10:53 +02:00
Patrick Georgi aa44dbd364 cbfstool: move tests for fixed-location files earlier
... and the assert is gone.
The actual action of adding a just-right file can be moved after the tests
since it's exactly the condition those tests don't continue or break on.

Change-Id: I6d0e829e0158198301136ada9a0de2f168ceee3f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11221
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:10:27 +02:00
Patrick Georgi db01ddfd49 cbfstool: prepare moving tests earlier
The assert() makes sure the if() holds true. But that assert won't survive for
long.

Change-Id: Iab7d2bc7bfebb3f3b3ce70dc5bd041902e14bd7a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11220
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:10:06 +02: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 7fd14184fb cbfstool: honor larger-than-usual header sizes in cbfs_add_entry_at()
If an earlier stage built a larger header, cbfs_add_entry_at() shouldn't
decide to go with the most boring, least featureful header type (and its size)
instead.

Change-Id: Icc5dcd9a797a0f3c42f91cddd21b3b3916095b63
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-08-13 16:09:17 +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
Patrick Georgi 4d1c5aa9f7 cbfstool: Deduplicate code to merge empty files
The code for removing a file had its own merge routine. Use the generic one
instead.

Change-Id: I90ed007ab86f78a2728f529fa0143c5c1dfbbdc3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10967
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-18 15:28:33 +02:00
Patrick Georgi 0d618afc84 cbfstool: rename checksum to attributes_offset
So far it's still unused, but its purpose will change:
It will become an offset to another structure that contains additional file
attributes.

This change is compatible because the binary format doesn't change and so far
the field was always set to 0, which can serve nicely as 'unused' field.

Change-Id: I2dafb06866713d43a236556f9492641526270837
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-18 09:56:08 +02:00
Patrick Georgi 2062473492 cbfstool: move fill value to cbfs.h
Change-Id: Ie05db6d43219c65d08e2221009875f81eb29b630
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-18 09:39:33 +02:00
Sol Boucher 5bb90e6999 cbfstool: Remove extra comma after {0, NULL} list element
Trailing commas are useful for lists that can be extended. These lists are
0-terminated, and there should be no elements following that.

Change-Id: Iea8c6d5579d6363e77e1f5af666948160c4a9bf9
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/10932
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-16 17:39:49 +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 c569b8bfdc cbfstool: use variable length array to model cbfs_file's filename
Change-Id: Ib056983630b2899d7e6cbcb43f6b7153f0f8e282
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10928
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-16 17:38:38 +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 5bad3954bf cbfstool: Eliminate useless cbfs_image_create() local variable
The only operation performed on this struct turned out to be sizeof...

Change-Id: I619db60ed2e7ef6c196dd2600dc83bad2fdc6a55
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10131
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:24:42 +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 297c88c357 cbfstool: Fix cbfs_copy_instance()'s master header endianness
The function hadn't been updated to account for the fact that we now
copy an endianness-corrected CBFS master header into a separate buffer
from the CBFS data: it still performed pointer arithmetic accross the
two buffers and wrote the copied buffer into the image without
restoring the original endianness.

Change-Id: Ieb2a001f253494cf3a90d7e19cd260791200c4d3
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10122
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:22:44 +02:00
Sol Boucher 636cc858bb cbfstool: Make the add action choose an aligned entries capacity
This fixes an inconsistency between `cbfstool create` and `cbfstool add` that
was resulting in confusing claims about the amount of free space at the end of a
CBFS. Calls to `cbfstool add` check whether a file fits under a given empty file
entry by testing whether it would collide with the beginning of the *subsequent*
file header; thus, if a file's end is unaligned, its reported size will not
match the actual available capacity. Although deleted entries always end on an
alignment boundary because `cbfstool remove` expands them to fill the available
space, `cbfstool create` doesn't necessarily size a new entries region to result
in an empty entry with an aligned end.
This problem never resulted in clobbering important data because cbfstool would
blindly reserve 64B (or the selected alignment) of free space immediately after
the all-inclusive empty file entry. This change alters the way this reservation
is reported: only the overhang past the alignment is used as hidden padding, and
the empty entry's capacity is always reported such that it ends at an aligned
address.
Much of the time that went into this patch was spent building trust in the
trickery cbfstool employs to avoid explicitly tracking the image's total
capacity for entries, so below are two proofs of correctness to save others time
and discourage inadvertent breakage:

OBSERVATION (A): A check in cbfs_image_create() guarantees that an aligned CBFS
empty file header is small enough that it won't cross another aligned address.

OBSERVATION (B): In cbfs_image_create(), the initial empty entry is sized such
that its contents end on an aligned address.

THM. 1: Placing a new file within an empty entry located below an existing file
entry will never leave an aligned flash address containing neither the beginning
of a file header nor part of a file.
 We can prove this by contradiction: assume a newly-added file neither fills to
 the end of the preexisting empty entry nor leaves room for another aligned
 empty header after it. Then the first aligned address after the end of the
 newly-inserted file...
  - CASE 1: ...already contains a preexisting file entry header.
    + Then that address contains a file header.
  - CASE 2: ...does not already house a file entry header.
    + Then because CBFS content doesn't fall outside headers, the area between
      there and the *next* aligned address after that is unused.
    + By (A), we can fit a file header without clobbering anything.
    + Then that address now contains a file header.

THM. 2: Placing a new file in an empty entry at the very end of the image such
that it fits, but leaves no room for a final header, is guaranteed not to change
the total amount of space for entries, even if that new file is later removed
from the CBFS.
 Again, we use contradiction: assume that creating such a file causes a
 permanent...
  - CASE 1: ...increase in the amount of available space.
    + Then the combination of the inserted file, its header, and any padding
      must have exceeded the empty entry in size enough for it to cross at
      least one additional aligned address, since aligned addresses are how
      the limit on an entry's capacity is determined.
    + But adding the file couldn't have caused us to write past any further
      aligned addresses because they are the boundary's used when verifying
      that sufficient capacity exists; furthermore, by (B), no entry can ever
      terminate beyond where the initial empty entry did when the CBFS was
      first created.
    + Then the creation of the file did not result in a space increase.
  - CASE 2: ...decrease in the amount of available space.
    + Then the end of the new file entry crosses at least one fewer aligned
      address than did the empty file entry.
    + Then by (A), there is room to place a new file entry that describes the
      remaining available space at the first available aligned address.
    + Then there is now a new record showing the same amount of available space.
    + Then the creation of the file did not result in a space decrease.

BUG=chromium:473726
TEST=Had the following conversation with cbfstool:
$ ./cbfstool test.image create -s 0x100000 -m arm
Created CBFS image (capacity = 1048408 bytes)
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm

Name                           Offset     Type         Size
(empty)                        0x40       null         1048408
$ dd if=/dev/zero of=toobigmed.bin bs=1048409 count=1
1+0 records in
1+0 records out
1048409 bytes (1.0 MB) copied, 0.0057865 s, 181 MB/s
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
E: Could not add [toobigmed.bin, 1048409 bytes (1023 KB)@0x0]; too big?
E: Failed to add 'toobigmed.bin' into ROM image.
$ truncate -s -1 toobigmed.bin
$ ./cbfstool test.image add -t 0x50 -f toobigmed.bin -n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm

Name                           Offset     Type         Size
toobig                         0x40       raw          1048408
$ ./cbfstool test.image remove
-n toobig
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm

Name                           Offset     Type         Size
(empty)                        0x40       deleted      1048408
$ ./cbfstool test.image print
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm

Name                           Offset     Type         Size
(empty)                        0x40       deleted      1048408
BRANCH=None

Change-Id: I118743e37469ef0226970decc900db5d9b92c5df
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: e317ddca14bc36bc36e6406b758378c88e9ae04e
Original-Change-Id: I294ee489b4918646c359b06aa1581918f2d8badc
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263962
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9939
Tested-by: build bot (Jenkins)
2015-05-08 19:45:21 +02:00
Patrick Georgi cccc9d4087 cbfstool: compare pointer difference with ptrdiff_t value
Fixes building cbfstool in 32bit environments.

Change-Id: I3c94afc9c961eb8b41d1e08f4a16e5cab2a6bb8b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10015
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-28 22:13:24 +02:00
Sol Boucher 057256541b cbfstool: Fix ability to add files at offsets near the end of empty spaces
Because cbfs_add_entry_at() previously *assumed* it would have to create a
trailing empty entry, it was impossible to add files at exact offsets close
enough to the end of an existing empty entry that they occupied the remainder
of its space. This addresses the problem by skipping the step of creating the
trailing empty entry if doing so would place it at the start offset of whatever
already followed the original empty section.

BUG=chromium:473511
TEST=Run the following commands:
$ ./cbfstool test.image create -s 0x100000 -m arm
$ dd if=/dev/zero of=twok.bin bs=1 count=2048
$ ./cbfstool test.image add -t 0x50 -f twok.bin -n at_end -b 0xff7c0
$ ./cbfstool test.image add -t 0x50 -f twok.bin -n near_end -b 0xfef80
$ ./cbfstool test.image print
There shouldn't be any assertions, and the output should be:
test.image: 1024 kB, bootblocksize 0, romsize 1048576, offset 0x40
alignment: 64 bytes, architecture: arm

Name                           Offset     Type         Size
(empty)                        0x40       null         1044184
near_end                       0xfef40    raw          2048
at_end                         0xff780    raw          2048
BRANCH=None

Change-Id: Ic8a6c3dfa4f82346a067c0804afb6c5a5e89e6c8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 1bbd353fddc818f725e488e8f2fb6e967033539d
Original-Change-Id: I15d25df80787a8e34c2237262681720203509c72
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/263809
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9938
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-04-25 12:16:57 +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
Julius Werner efcee767de CBFS: Automate ROM image layout and remove hardcoded offsets
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.

Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).

Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.

BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.

Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14 09:01:27 +02:00
Martin Roth dde307c01a cbfstool: add filetypes for FSP, MRC, SPC and MRC_CACHE
This adds a few new file types to cbfstool.  Currently these
files are being added using bare hex values in the coreboot
makefiles.  This patch is just to make the values official and
to help get rid of some confusion in the values used within the
makefiles.

All of these new types are roughly equivalent to raw.

Change-Id: I37c4180a247136cd98080f6f7609d3cf905a62f5
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8977
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-03-30 21:45:11 +02:00
Stefan Reinauer 2dd161f556 cbfstool: Clean up code
cbfstool has diverged between coreboot upstream and the chromium tree.
Bring in some of the chromium changes, in particular the useful remainders
of cbf37fe (https://chromium-review.googlesource.com/176710)

- fix coding style
- mark unused variables explicitly unused
- remove some dead code

Change-Id: I354aaede8ce425ebe99d4c60c232feea62bf8a11
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2015-03-04 19:53:20 +01:00
Hung-Te Lin 0780d67ffe util/cbfstool: Fix byte-ordering for payload type field.
In https://chromium-review.googlesource.com/181272 the payload->type has been
changed to big-endian (network ordering) but the cbfs_image is still parsing
type as host ordering, which caused printing cbfs image verbosely
(cbfstool imge print -v) to fail to find entry field and print numerous
garbage output.

Payload fields should be always parsed in big-endian (network ordering).

BUG=none
TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly

Original-Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200158
Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 423f7dd28f8b071692d57401e144232d5ee2e479)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: I5a4694e887c7ff48d8d0713bb5808c29256141a9
Reviewed-on: http://review.coreboot.org/8005
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2015-01-03 17:33:13 +01:00
Stefan Reinauer 8f50e53a4b cbfstool: Fix architecture check when adding payload
In the process of rewriting cbfstool for ARM and using
a new internal API a regression was introduced that would
silently let you add an ARM payload into an x86 CBFS image
and the other way around. This patch fixes cbfstool to
produce an error in that case again.

Change-Id: I37ee65a467d9658d0846c2cf43b582e285f1a8f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176711
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 8f74f3f5227e440ae46b59f8fd692f679f3ada2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6879
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-12 22:07:19 +02:00
Aaron Durbin ca63027ef7 cbfstool: process cbfs_payload_segment(s) in host byte order
The printing routines of the cbfs_payload_segment assumed the type
could be accessed in host order. Each of the fields need to be
converted to the host order before inspecting the fields. In addition,
this removes all the ntoh*() calls while processing the
cbfs_payload_segment structures.

cbfstool would crash adding entries or just printing entries
containing a payload when -v was passed on the command line.

Change-Id: Iff41c64a99001b9e3920e2e26828c5fd6e671239
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <gaumless@gmail.com>
2014-08-07 19:05:43 +02:00
Edward O'Callaghan a0f9ece19c util/cbfstool: Make cbfs_image_delete() NULL-tolerant.
This fixes a double free crash that occurs when a call to
cbfs_image_from_file() fails in cbfs_extract() and falls though to
cbfs_image_delete() with a NULL-pointer.

To reproduce the crash pass the following arguments where the files
passed, in fact, do not exist. As follows:
./cbfstool build/coreboot.rom extract -n config -f /tmp/config.txt

Change-Id: I2213ff175d0703705a0ec10271b30bb26b6f8d0a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5353
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-04-07 18:34:33 +02:00
Aaron Durbin 54ef306377 cbfstool: add eflparsing.h
elfparsing.h serves as the header to working with the elf
parser. Additionally, only include what is needed by the other
files. Many had no reason to be including elf.h aside from fixing
compilation problems when including cbfs.h.

Change-Id: I9eb5f09f3122aa18beeca52d2e4dc2102d70fb9d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5370
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-13 05:28:44 +01: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
Ronald G. Minnich a8a133ded3 Add section header parsing and use it in the mk-payload step
This completes the improvements to the ELF file parsing code.  We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.

There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.

To maximize the ease of use for users, elf parsing is accomplished with
just one function:

int
elf_headers(const struct buffer *pinput,
	    Elf64_Ehdr *ehdr,
	    Elf64_Phdr **pphdr,
	    Elf64_Shdr **pshdr)

which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.

To satisfy our powerful scripts, I had to remove the ^M from an unrelated
microcode file.

BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same. This was also fully tested across all chromebooks for building and booting and running chromeos.
BRANCH=None

Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5098
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-02-02 20:18:55 +01:00
Ronald G. Minnich aa2f739ae8 cbfs: fix issues with word size and endianness.
Add XDR functions and use them to convert the ELF headers
to native headers, using the Elf64 structs to ensure we accomodate
all word sizes. Also, use these XDR functions for output.

This may seem overly complex but it turned out to be much the easiest
way to do this. Note that the basic elf parsing function
in cbfs-mkstage.c now works over all ELF files, for all architectures,
endian, and word size combinations. At the same time, the basic elf
parsing in cbfs-mkstage.c is a loop that has no architecture-specific
conditionals.

Add -g to the LDFLAGS while we're here. It's on the CFLAGS so there is
no harm done.

This code has been tested on all chromebooks that use coreboot to date.

I added most of the extra checks from ChromeOS and they triggered a
lot of warnings, hence the other changes. I had to take -Wshadow back
out due to the many errors it triggers in LZMA.

BUG=None
TEST=Build and boot for Peppy; works fine. Build and boot for nyan,
     works fine. Build for qemu targets and armv8 targets.
BRANCH=None

Change-Id: I5a4cee9854799189115ac701e22efc406a8d902f
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178606
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/4817
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:03:44 +01:00
Aaron Durbin 1ebc7e943b cbfstool: correct size left calculation for "empty" entries
After removing a file sandwiched between two other files, that file
could no longer be re-added at the same location. cbfstool tried to
add the file, and a new "empty" entry, which, together, would no
longer fit, so it continued checking for the next available space.

Change the behavior to add the file if there is enough space for the
file alone, then only add the "empty" entry if there is enough space
for it.

Change-Id: Iad3897dd28cf12f12ae877cfd83e1990fa7d2f0f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4772
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-24 04:48:05 +01:00
Paul Menzel 4159a8012e Correct spelling of shadow, setting and memory
Change-Id: Ic7d793754a8b59623b49b7a88c09b5c6b6ef2cf0
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3768
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-16 22:25:56 +02:00
Stefan Reinauer dc7bc8e589 cbfstool: Fix cbfs_image.c
- The read-only structures are const now
- cosmetic fixes
  - put { on a new line for functions
  - move code after structures

Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2922
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2013-03-27 01:24:48 +01:00
Hung-Te Lin b02c873190 cbfstool: Fix initial empty space in image creation.
When calculating initial CBFS empty entry space, the size of header itself must
be not included (with the reserved space for entry name). This is a regression
of the old cbfstool size bug.

Before this fix, in build process we see:
 OBJCOPY    cbfs/fallback/romstage_null.bin
 W: CBFS image was created with old cbfstool with size bug.
    Fixing size in last entry...

And checking the output binary:
 cbfstool build/coreboot.pre1 print -v -v
 DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes)
 DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30
 W: CBFS image was created with old cbfstool with size bug.
    Fixing size in last entry...
 DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00.
 coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64
 Name                           Offset     Type         Size
 (empty)                        0x0        null         261296
 DEBUG:  cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0

After this fix, no more alerts in build process.
Verified to build successfully on x86/qemu and arm/snow configurations.

Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22 00:21:41 +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 c5ff6487e6 armv7: Prevent CBFS data overlapping bootblock.
For arm/snow, current bootblock is larger than previously assigned CBFS offset
and will fail to boot. To prevent this happening again in future, cbfstool now
checks if CBFS will overlap bootblock.

A sample error message:
	E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000)
	E: Failed to create build/coreboot.pre1.tmp.

arm/snow offset is also enlarged and moved to Kconfig variable.

Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2295
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-06 10:53:19 +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 49fcd75564 cbfstool: Fix incorrect CBFS free space by old cbfstool.
Old cbfstool may produce CBFS image with calculation error in size of last empty
entry, and then corrupts master header data when you really use every bit in
last entry. This fix will correct free space size when you load ROM images with
cbfs_image_from_file.

Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2211
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:26:58 +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