Commit Graph

349 Commits

Author SHA1 Message Date
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
Patrick Georgi c7a8c3835d cbfstool: fix 32bit host issue
Change-Id: Iaec748b4bdbb5da287520fbbd7c3794bf664eff6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10161
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Sol Boucher <solb@chromium.org>
2015-05-09 14:58:13 +02:00
Patrick Georgi 94383da335 fmap: request libc compatibility level that includes memccpy
Change-Id: I928efe6f63305a0099d64e83091aa80768582f48
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10160
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2015-05-09 14:57:55 +02:00
Sol Boucher 023e829423 fmaptool: Add listing of annotated CBFS sections and generate header
The fmd compiler now processes "(CBFS)" annotations, distilling them
into a comma-separated list of the names of sections containing
CBFSes. This list is the only thing printed to standard output to
enable easy capture and machine consumption by other tools.
Additionally, the ability to generate a tiny header with a define for
the primary CBFS's size is implemented and can be requested via a
new command-line switch.

Here's an example of how to use the new features:
 $ ./fmaptool -h layout.h layout_arm_8192.fmd layout.fmap 2>/dev/null
 FW_MAIN_A,FW_MAIN_B,COREBOOT
The hypothetical fmd file contains three sections annotated as (CBFS),
the names of which are printed to standard output. As before, a binary
FMAP file named layout.fmap is created; however, because the command
was invoked with -h, a header #define ing the offset of its FMAP
section (i.e. where it will be relative to the base of flash once the
boot image is assembled) is also generated.

BUG=chromium:470407
TEST=Verify that fmd files without a "COREBOOT" section or with one
that isn't annotated as "(CBFS)" are not accepted. Ensure that the
list of CBFS sections matches the descriptor file's annotations and
is led by the "COREBOOT" section. Invoke with the header generation
switch and check that output file for reasonableness.
BRANCH=None

Change-Id: I496dd937f69467bfd9233c28df59c7608e89538f
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 9227698adecf675770b2983380eb570676c2b5d2
Original-Change-Id: I8b32f6ef19cabe2f6760106e676683c4565bbaad
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262956
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9967
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:33:47 +02:00
Sol Boucher b974081c13 fmaptool: Conform to cbfstool's error message format
The tool now makes use of the ERROR() macros from common.h.

Change-Id: Ie38f40c65f7b6d3bc2adb97e246224cd38d4cb99
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10048
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:33:22 +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 64c6cd73f3 cbfstool: Add offset field to cbfstool directory's struct buffer
This allows calls to buffer_delete() to work on a buffer that has been
buffer_seek()ed or the buffer created by a buffer_splice(). The same
information could also be useful for other purposes, such as writing
slices back to a file at the offset they originally occupied.

BUG=chromium:470407
TEST=Attempt to perform the following sequence of buffer actions, then run it
through valgrind to check for memory errors:
for (int pos = 0; pos <= 3; ++pos) {
	struct buffer seek_test;
	buffer_create(&seek_test, 3, "seek_test");
	if (pos == 0) {
		buffer_delete(&seek_test);
		continue;
	}
	buffer_seek(&seek_test, 1);
	if (pos == 1) {
		buffer_delete(&seek_test);
		continue;
	}
	buffer_seek(&seek_test, 1);
	if (pos == 2) {
		buffer_delete(&seek_test);
		continue;
	}
	buffer_seek(&seek_test, 1);
	if (pos == 3) {
		buffer_delete(&seek_test);
		continue;
	}
}
for (int pos = 0; pos <= 14; ++pos) {
	struct buffer slice_test;
	buffer_create(&slice_test, 3, "slice_test");
	if (pos == 0) {
		buffer_delete(&slice_test);
		continue;
	}
	struct buffer sliced_once;
	buffer_splice(&sliced_once, &slice_test, 1, 2);
	if (pos == 1) {
		buffer_delete(&slice_test);
		continue;
	}
	if (pos == 2) {
		buffer_delete(&sliced_once);
		continue;
	}
	struct buffer sliced_twice;
	buffer_splice(&sliced_twice, &sliced_once, 2, 1);
	if (pos == 3) {
		buffer_delete(&slice_test);
		continue;
	}
	if (pos == 4) {
		buffer_delete(&sliced_once);
		continue;
	}
	if (pos == 5) {
		buffer_delete(&sliced_twice);
		continue;
	}
	struct buffer sliced_same;
	buffer_splice(&sliced_same, &slice_test, 1, 1);
	if (pos == 6) {
		buffer_delete(&slice_test);
		continue;
	}
	if (pos == 7) {
		buffer_delete(&sliced_once);
		continue;
	}
	if (pos == 8) {
		buffer_delete(&sliced_twice);
		continue;
	}
	if (pos == 9) {
		buffer_delete(&sliced_same);
		continue;
	}
	struct buffer sliced_thrice;
	buffer_splice(&sliced_thrice, &sliced_twice, 1, 0);
	if (pos == 10) {
		buffer_delete(&slice_test);
		continue;
	}
	if (pos == 11) {
		buffer_delete(&sliced_once);
		continue;
	}
	if (pos == 12) {
		buffer_delete(&sliced_twice);
		continue;
	}
	if (pos == 13) {
		buffer_delete(&sliced_same);
		continue;
	}
	if (pos == 14) {
		buffer_delete(&sliced_thrice);
		continue;
	}
}
BRANCH=None

Change-Id: Id67734654a62302c0de37746d8a978d49b240505
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 00c40982a21a91a488587dd3cead7109f3a30d98
Original-Change-Id: Ie99839d36500d3270e4924a3477e076a6d27ffc8
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/267467
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10133
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:25:11 +02:00
Sol Boucher 1a3349ffd1 cbfstool: Simplify the common buffer_splice() function's interface
Previously, this function allowed one to pass a size of 0 in order to
indicate that the entire buffer should be copied. However, the
semantics of calling it this way were non-obvious: The desired
behavior was clear when the offset was also 0, but what was the
expected outcome when the offset was nonzero, since carrying over the
original size in this case would be an error? In fact, it turns out
that it always ignored the provided offset when the size was zero.
This commit eliminates all special handling of 0; thus, the resulting
buffer is exactly as large as requested, even if it's degenerate.
Since the only consumer that actually called the function with a size
of 0 was buffer_clone(), no other files required changes.

Change-Id: I1baa5dbaa7ba5bd746e8b1e08816335183bd5d2d
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10132
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 20:25:03 +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 69b88bf127 fmaptool: Introduce the fmd ("flashmap descriptor") language and compiler
This adds a compiler for a language whose textual representation of flashmap
regions will be used to describe the layout of flash chips that contain more
than just a single CBFS. Direct integration with cbfstool (via a new
command-line switch for the create action) is forthcoming but will be added
separately.

BUG=chromium:461875
TEST=Use Chromium OS's cros_bundle_firmware script on the fmap.dts file for
panther. Using the latter file as a reference, write a corresponding
fmap.fmd file and feed it through fmaptool. Run both binary output files
though the flashmap project's own flashmap_decode utility. Observe only
the expected differences.
BRANCH=None

Change-Id: I06b32d138dbef0a4e5ed43c81bd31c796fd5d669
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: 005ab67eb594e21489cf31036aedaea87e0c7142
Original-Change-Id: Ia08f28688efdbbfc70c255916b8eb7eb0eb07fb2
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/255031
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/9942
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 19:55:42 +02:00
Sol Boucher fa7a45524f cbfstool: Fix strange flashmap whitespace
This is being fixed in a separate commit so we can diff against the
library as it existed in its own repo.

Change-Id: Id87cd8f4e015a5ed7dd8a19302cc22ab744fefe8
Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10141
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-08 19:45:55 +02:00
Sol Boucher 65d9520e15 cbfstool: Import minimal set of files from flashmap
flashmap was developed in a separate repository until now.
Import the files from the 2012 version of the project [1].

[1] https://code.google.com/p/flashmap

BUG=chromium:461875
TEST=None
BRANCH=None

Change-Id: Ida33f81509abc1cf2e532435adbbf31919d96bd8
Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Commit-Id: f44e1d1864babe244f07ca49655f0b80b84e890d
Original-Change-Id: Ibf191d34df738449c9b9d7ebccca3d7f4150d4d3
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254801
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9940
Tested-by: build bot (Jenkins)
2015-05-08 19:45:27 +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
Paul Menzel 6548ae9f99 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS`
Commit 0e53931f (cbfstool: Clean up in preparation for adding new
files) split out the flags and introduced the variable `LINKFLAGS`.
Rename it to `LDFLAGS` which is more commonly used.

Change-Id: Ib6299f8ef5cf30dbe05bfae36f30ae4371f0a738
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10064
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-04 12:09:59 +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
Stefan Tauner d0398f135f cbfstool: remove gcc-specific -Og flag
The new -Og optimization level is only available in gcc version 4.8
or higher. Clang fails on this too as of now (with "invalid integral
value 'g' in '-Og'"). The gain of this does not outweigh this
limitation at all. The flag was added in 0e53931.

Change-Id: I2b2dfc786369653d768f25be94b53329451ae1b4
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/9999
Tested-by: build bot (Jenkins)
Reviewed-by: Sol Boucher <solb@chromium.org>
2015-04-27 23:04:16 +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 1161473ecb cbfstool: add the missing 'break'
The previous patch introduced a bug where the new added case statement
was missing the break. There was no problem testing, because an
unrelated parameter structure field was being modified as a result.

BRANCH=storm
BUG=none
TEST=compiles and runs

Change-Id: Iaeb328048f61ffd57057ebce47f2ac8e00fc5aac
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 27ecc130569e4252e4627052f617130a2017c645
Original-Change-Id: Ib3e6c4c2b5c37588c612b8ab2672f6845c1b4ecb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239598
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
2015-04-18 08:48:46 +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
Furquan Shaikh de77e6a99f ARM64 rmodule: Add new reloc type R_AARCH64_LDST8_ABS_LO12_NC
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.

Change-Id: Id7b0dfb5a51c2f29bdb031b98606940c118959ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a1c4d2f35c135d542708c4dabcca5e8c1d453c0
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: If132323885f23d75e1fcde064398e85c2c17f257
Original-Reviewed-on: https://chromium-review.googlesource.com/231560
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8809
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21 08:41:42 +01:00
Julius Werner a807f83936 cbfstool: Remove empty line that looks out of place
BRANCH=None
BUG=None
TEST=Manual

Change-Id: I8b31a0b194d353ea3e7863513f2e36f3e032fad8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ccba49a7c2372cdfff6e2947e417d4d4f5436c2
Original-Change-Id: I9beebdf29e4fc4aa645581146fdc61c659de72df
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/8808
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21 08:41:28 +01:00
Aaron Durbin a47898ef6c rmodtool: add another aarch64 relocation
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.

Change-Id: Ie367c348fbf59465e238e5fa60f217f5373501b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a754bc1fe39c19ab8b2f7be9648cccb06156b0ef
Original-Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218843
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8807
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21 08:41:17 +01:00
Furquan Shaikh d2338bad95 rmodtool: Add support for aarch64
BUG=chrome-os-partner:31615
BRANCH=None
TEST=Compiles succesfully, rmodule created and loaded for ryu

Change-Id: Icc80b845fe43a012665d77c3ef55bd30784fd3fc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24ad4383a9ea75ba6beb084451b74e8a8735085b
Original-Change-Id: I4f3a5dbb8fc8150aa670d2e6fed56a6774feb4a6
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214329
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8806
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-21 08:41:10 +01:00
Furquan Shaikh c4f08f7f9c cbfstool: Add relocation codes for arm mode
Add relocation codes required for arm mode. These are required by armv4.

BUG=chrome-os-partner:30784
BRANCH=None
TEST=Compiles successfully for rush

Original-Change-Id: Ie7c5b3e07689c85091036a619a65f9fea1918b6b
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209973
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit dc5f411f95e02a02b4a4ef4652303ce62aa220c2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: Ie62ed730080299e474c256371ab88f605b54c10f
Reviewed-on: http://review.coreboot.org/8675
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-17 16:53:50 +01: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
Paul Burton 3318692078 cbfstool: Add the MIPS architecture
Specify a CBFS architecture value for MIPS and allow cbfstool to make
use of it.

Original-Change-Id: I604d61004596b65c9903d444e030241f712202bd
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/207971
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 7c4df61715df3767673841789d02fe5d1bd1d4a0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: Ib30524f5e7e8c7891cb69fc8ed8f6a7e44ac3325
Reviewed-on: http://review.coreboot.org/8519
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-03-03 18:43:51 +01:00
Furquan Shaikh 01f5396bdc cbfstool: Remove arch check for different stages
Remove the arch check for each stage as the arch for different stages can be
different based on the SoC. e.g.: Rush has arm32-based romstage whereas
arm64-based ramstage

BUG=None
BRANCH=None
TEST=Compiles successfully for nyan, link and rush

Original-Change-Id: I561dab5a5d87c6b93b8d667857d5e181ff72e35d
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/205761
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 6a6a87b65fcab5a7e8163258c7e8d704fa8d97c3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: Ic412d60d8a72dac4f9807cae5d8c89499a157f96
Reviewed-on: http://review.coreboot.org/8179
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-13 21:29:38 +01:00
Furquan Shaikh b26fd99087 cbfstool: Fix help display message
For arm64, the machine type is arm64 in cbfstool, however it was displayed as
aarch64 in help message. This patch corrects it.

BUG=None
BRANCH=None
TEST=None

Original-Change-Id: I0319907d6c9d136707ed35d6e9686ba67da7dfb2
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/204379
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 1f5f4c853efac5d842147ca0373cf9b5dd9f0ad0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: I00f51f1d4a9e336367f0619910fd8eb965b69bab
Reviewed-on: http://review.coreboot.org/8144
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-01-09 07:49:53 +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
Kyösti Mälkki f9b8ed86dd cbfstool: Fix update-fit command
Regression in commit 3fcde22 caused parse_microcode_blob() to access
data outside cpu_microcode_blob.bin file in CBFS and create invalid
Intel Firmware Interface Table entries.

Change-Id: I1a687060084c2acd6cac5f5053b74a332b4ac714
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/7958
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-12-28 19:58:35 +01:00
Marcelo Povoa dcc1c86c7f aarch64: Add ELF support
BUG=None
BRANCH=none
TEST=Build coreboot
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>

Original-Change-Id: I38684794fdf5bd95a32f157128434a13f5e2a2d5
Original-Reviewed-on: https://chromium-review.googlesource.com/185271
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Marcelo Póvoa <marcelogp@chromium.org>
Original-Commit-Queue: Marcelo Póvoa <marcelogp@chromium.org>
(cherry picked from commit 67b74d3dc98a773c3d82b141af178b13e9bb6c06)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: Id82a31dc94bb181f2d24eddcbfbfb6d6cdc99643
Reviewed-on: http://review.coreboot.org/7659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-12-09 18:39:58 +01:00
Francis Rowe 3fb8b0d75b util/cbfstool/cbfs-mkstage.c: Fix build issue on 32-bit x86
Fixes regression caused by commit 405304ac
(cbfstool: Add option to ignore section in add-stage)

Change-Id: If9e3eea9ab2c05027f660d0057a635abf981b901
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7545
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-11-21 19:46:18 +01:00
Furquan Shaikh 405304aca3 cbfstool: Add option to ignore section in add-stage
Allow add-stage to have an optional parameter for ignoring any section. This is
required to ensure proper operation of elf_to_stage in case of loadable segments
with zero filesize.

Change-Id: I49ad62c2a4260ab9cec173c80c0f16923fc66c79
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/7304
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-04 00:52:33 +01:00
Furquan Shaikh cc6f84c411 cbfstool: Convert cbfs-mkstage.c into pelf
Change cbfs-mkstage to use parsed elf instead of calling elf_headers. That
allows us to have access to the complete elf including the string table.

Change-Id: Ie767d28bdf41af38d1df0bce54bc0ada45123136
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/7303
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-04 00:52:17 +01:00
Aaron Durbin 785e47bbf3 rmodtool: add support for ARM
Add support for creating ARM rmodules. There are 3 expected
relocations for an ARM rmodule:
- R_ARM_ABS32
- R_ARM_THM_PC22
- R_ARM_THM_JUMP24

R_ARM_ABS32 is the only type that needs to emitted for relocation
as the other 2 are relative relocations.

BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vbootstub for ARM device.

Original-Change-Id: I0c22d4abca970e82ccd60b33fed700b96e3e52fb
Original-Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/190922
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit a642102ba7ace5c1829abe7732199eda6646950a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>

Change-Id: Ib3b3c90ebb672d8d6a537df896b97dc82c6186cc
Reviewed-on: http://review.coreboot.org/7204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-10-28 18:15:18 +01:00
Gabe Black 845aa1416d cbfstool: If compression fails, warn and use the uncompressed data.
The LZMA compression algorithm, currently the only one available, will fail
if you ask it to write more data to the output than you've given it space for.
The code that calls into LZMA allocates an output buffer the same size as the
input, so if compression increases the size of the output the call will fail.
The caller(s) were written to assume that the call succeeded and check the
returned length to see if the size would have increased, but that will never
happen with LZMA.

Rather than try to rework the LZMA library to dynamically resize the output
buffer or try to guess what the maximal size the data could expand to is, this
change makes the caller simply print a warning and disable compression if the
call failed for some reason.

This may lead to images that are larger than necessary if compression fails
for some other reason and the user doesn't notice, but since compression
errors were ignored entirely until very recently that will hopefully not be
a problem in practice, and we should be guaranteed to at least produce a
correct image.

Original-Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/187365
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit b9f622a554d5fb9a9aff839c64e11acb27785f13)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>

Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Reviewed-on: http://review.coreboot.org/6958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-10-28 17:08:29 +01:00
Patrick Georgi 96990a285d cbfstool: free memory
Change-Id: Ic53127a61154460fa3741a92a3b2de0eba446e9f
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6987
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-10-18 14:45:15 +02:00
Ronald G. Minnich 833bf20f92 RISCV: add this architecture to cbfstool
Change-Id: I6d972e595f12585cda08e1a6d2b94b4bf4f212f5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/7067
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-10-16 18:05:13 +02:00
Gabe Black dbd006b082 cbfstool: Propogate compression errors back to the caller.
When compression fails for whatever reason, the caller should know about it
rather than blindly assuming it worked correctly. That can prevent half
compressed data from ending up in the image.

This is currently happening for a segment of depthcharge which is triggering
a failure in LZMA. The size of the "compressed" data is never set and is
recorded as zero, and that segment effectively isn't loaded during boot.

Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187364
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit be48f3e41eaf0eaf6686c61c439095fc56883cec)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6960
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-09-25 20:26:04 +02:00
Furquan Shaikh 7eb809af40 cbfstool: Add AARCH64 reloc types to elf.h
Change-Id: Ifd4726491e01c3acebd3dfc326c1be994b0aefb8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214328
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6955
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2014-09-23 22:28:20 +02:00
Furquan Shaikh b237c10899 rmodtool: Allow rmodules with 0 relocations
Currently, rmodules with 0 relocations are not allowed. Fix this by skipping
addition of .rmodules section on 0 relocs.

Change-Id: I7a39cf409a5f2bc808967d2b5334a15891c4748e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/6774
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2014-09-23 22:26:57 +02:00
Furquan Shaikh 2af76f4bdc coreboot arm64: Add support for arm64 into coreboot framework
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.

Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 033ba96516805502673ac7404bc97e6ce4e2a934)

This patch is essentially a squash of aarch64 changes made by
these patches:

d955885 coreboot: Rename coreboot_ram stage to ramstage
a492761 cbmem console: Locate the preram console with a symbol instead of a sect
96e7f0e aarch64: Enable early icache and migrate SCTLR from EL3
3f854dc aarch64: Pass coreboot table in jmp_to_elf_entry
ab3ecaf aarch64/foundation-armv8: Set up RAM area and enter ramstage
25fd2e9 aarch64: Remove CAR definitions from early_variables.h
65bf77d aarch64/foundation-armv8: Enable DYNAMIC_CBMEM
9484873 aarch64: Change default exception level to EL2
7a152c3 aarch64: Fix formatting of exception registers dump
6946464 aarch64: Implement basic exception handling
c732a9d aarch64/foundation-armv8: Basic bootblock implementation
3bc412c aarch64: Comment out some parts of code to allow build
ab5be71 Add initial aarch64 support

The ramstage support is the only portion that has been tested
on actual hardware. Bootblock and romstage support may require
modifications to run on hardware.

Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6915
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
2014-09-23 18:10:32 +02:00
Ronald G. Minnich 5f43184349 cbfstool: add aarch64 as a name
The aarch64 is not really an arm variant, it's sufficiently
different that it can be considered (for purposes of cbfs, certainly)
to be a new architecture.

Add a constant in cbfs.h and strings to correspond to it.
Note that with the new cbfstool support that we added earlier,
the actual use of aarch64 ELF files actually "just works" (at
least when tested earlier).

Change-Id: Ib4900900d99c9aae6eef858d8ee097709368c4d4
Reviewed-on: https://chromium-review.googlesource.com/180221
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit f836e14695827b2667804bc1058e08ec7b297921)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6896
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-09-15 19:00:12 +02: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
Gabe Black 51edd54738 ARM: Generalize armv7 as arm.
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.

Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>

ARM: Split out ARMv7 code and make it possible to have other arch versions.

We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.

The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.

Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)

Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.

Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
2014-09-08 18:59:23 +02:00
Curt Brune 3c12cb0384 cbfstool:linux_trampoline: config CS and DS segment descriptors
The Linux trampoline code does not set up the segment descriptors for
__BOOT_CS and __BOOT_DS as described in the Linux kernel
documentation:

  ... a GDT must be loaded with the descriptors for selectors
  __BOOT_CS(0x10) and __BOOT_DS(0x18); both descriptors must be 4G
  flat segment; __BOOT_CS must have execute/read permission, and
  __BOOT_DS must have read/write permission;

This is not a problem when launching a Linux payload from coreboot, as
coreboot configures the segment descriptors at selectors 0x10 and
0x18.  Coreboot configures these selectors in the ramstage to match
what the Linux kernel expects (see
coreboot/src/arch/x86/lib/c_start.S).

When the cbfs payload is launched in other environments, SeaBIOS for
example, the segment descriptors are configured differently and the
cbfs Linux payload does not work.

If the cbfs Linux payload is to be used in multiple environments
should the trampoline needs to take care of the descriptors that Linux
requires.

This patch updates the Linux trampoline code to configure the 4G flat
descriptors that Linux expects.  The configuration is borrowed from
the descriptor configs in coreboot/src/arch/x86/lib/c_start.S for
selectors 0x10 and 0x18.

The linux_trampoline code is slightly refractored by defining the
trampoline entry address, 0x40000, as TRAMPOLINE_ENTRY_LOC.  This
definition is moved into a separate header file, linux_trampoline.h.
This header file is now included by both the trampoline assembly
language code and the trampoline loader C code.

The trampoline assembly language code can now use TRAMPOLINE_ENTRY_LOC
as scratch space for the sgdt CPU instruction.

Testing Done:

Verified the Linux payload is booted correctly in the following
environments:

1.  Coreboot -> Linux Payload

2.  Coreboot -> SeaBIOS -> Linux Payload: (previously did not work)

Change-Id: I888f74ff43073a6b7318f6713a8d4ecb804c0162
Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Reviewed-on: http://review.coreboot.org/6796
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-09-04 23:34:32 +02:00
Aaron Durbin 518a322d58 rmodtool: correct final memory size calculation
Apparently when I originally wrote this I confused myself to no end.
The code/data of an rmodule has a set memory size which is associated
with the .payload section. The relocation entries may increase the
overall footprint of the memory size if the rmodule has no bss but
a lot of relocations. Therefore, just compare relocation entries size
plus the file size of the .payload section with the memory size of the
paylod section. The .empty section is added only when we have not met
the final target size.

Change-Id: I5521dff048ae64a9b6e3c8f84a390eba37c7d0f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6767
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
2014-08-27 03:20:27 +02:00
Aaron Durbin bc349b81e9 elfheaders: fix 64-bit ELF writing
The sh_flags for a 64-bit section header entry are
64-bit in size. Correct this.

Change-Id: I2fa79d9a0fb46cc1dfa97c172357bbd2394843e0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6737
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
2014-08-22 21:30:09 +02:00
Patrick Georgi 32eeff4b6e util: replace fseek/ftell/rewind with fstat
It's a more direct approach to get the file size.

Change-Id: If49df26bf4996bd556c675f3a673d0003b4adf89
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6594
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-12 11:53:24 +02:00
Patrick Georgi a65c21eeb5 cbfstool: free stale memory
The process probably terminates not much later, but in
case anyone reuses the function in something with
longer life-time, free unused resources.

Change-Id: I10c471ee3d9dc9a3ebf08fe4605f223ea59b990e
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6559
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-10 08:20:30 +02:00
Patrick Georgi e887ca5a74 cbfstool: fix option parsing
"cbfstool create -B bootblock -s size" (in this order)
would break bootblock selection.

Change-Id: I9a9f5660827c8bf60dae81b519c6f026f3aaa0f3
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6564
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2014-08-09 19:54:09 +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
Daniele Forsi 8e89847af4 util/cbfstool: free buffer on error path
Fix memory leak found by scan-build from clang version 3.2-11.

Change-Id: Id8f9db46cf42012a0eb0a632c9d83a4eec1989a2
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6379
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-30 10:36:00 +02:00
Patrick Georgi 913e1718cd build system: fix another cbfstool race
It just doesn't work to have files depend on their parent
directory: As soon as the files are written, the time stamp
of the directory changes, too.

This led to spurious updates of cbfstool and rmodtool, and
related "permission denied" errors when linker and build
system ran into each other.

Change-Id: I44a7d7b4b1d47a1567ece1f57dfd6745d05ee651
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6276
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-15 14:27:04 +02:00
Edward O'Callaghan 44fd0a0031 utils/cbfstool: No need to pass -g flag twice
Spotted by building with Clang.

Change-Id: I7ab97278d8bd586a71e453c8cc9d26dd6938c8d2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-06-29 04:16:49 +02:00
Paul Menzel 470c37c372 util/cbfstool: Use `%zu` instead of `%ld` for size_t arguments
cbfstool fails to built under 32-bit platforms since commit

    aa2f739a cbfs: fix issues with word size and endianness.

due to the use of '%ld' format specifier on size_t, which on these
platforms is only 32-bit.

No error is seen though, when cbfstool is built, when building a coreboot
image, where it is put in `build/cbfstool`.

Use the length modifier `z` for size_t arguments, and cast to size_t where
appropriate.

Change-Id: Id84a20fbf237376a31f7e4816bd139463800c977
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5388
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-27 15:43:08 +02:00
Aaron Durbin b275757212 cbfstool: account for the trampoline code in bzImage payload
For bzImages the trampoline segment is added unconditionally.
However, that segment wasn't properly being accounted for.
Explicitly add the trampoline segments like the other ones.

Change-Id: I74f6fcc2a65615bb87578a8a3a76cecf858fe856
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5702
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-05-09 08:24:32 +02:00
Wei Hu 2ad6ee9763 util/cbfstool: Fix "Bad segment type 53534220 Could not load payload".
The magic number mismatch was introduced by commit a8a133
(Add section header parsing and use it in the mk-payload step).

Change-Id: I73b0adb969816e9d130f19f48e175c57124e2f3a
Signed-off-by: Wei Hu <wei@aristanetworks.com>
Reviewed-on: http://review.coreboot.org/5528
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-04-18 21:18:05 +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 4f3bb801ed cbfstool: provide structure to linux payload builder
This change started with tracking down a bug where the trampoline
size was not being taken into account for sizing the output buffer
leading to a heap corruption.  I was having a hard time keeping
track of what num_segments actually tracked as well as what parts
were being placed in the output buffer. Here's my attempt at
hopefully providing more clarity.

This change doesn't crash when adding a bzImage:
$ dd if=/dev/zero of=bb.bin bs=64 count=1
$ ./cbfstool tmp.rom create -s 4M -B bb.bin -m x86 -a 64
$ ./cbfstool tmp.rom add-payload -f ~/Downloads/bzImage -C "1" -n
"fallback"/payload

Change-Id: Ib1de1ddfec3c7102facffc5815c52b340fcdc628
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5408
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-28 14:40:53 +01:00
Aaron Durbin 4fde5a66b4 util: add rmodtool for parsing ELF files to rmodules
The current implementation of creating rmodules relies
on invoking the linker in a certain manner with the
relocations overlaid on the BSS section. It's not really
surprising that the linker doesn't always behave the way
one wants depending on the linker used and the architecture.
Instead, introduce rmodtool which takes an ELF file as an
input, parses it, and creates a new ELF file in the format
the rmodule loader expects.

Change-Id: I31ac2d327d450ef841c3a7d9740b787278382bef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5378
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-03-20 21:34:39 +01:00
Aaron Durbin 36be8135d7 cbfstool: add ELF writing support
In order to generate rmodules in the format of ELF files
there needs to be support for writing out ELF files. The
ELF writer is fairly simple. It accpets sections that can
be associated with an optional buffer (file data). For each
section flagged with SHF_ALLOC a PT_LOAD segment is generated.
There isn't smart merging of the sections into a single PT_LOAD
segment.

Change-Id: I4d1a11f2e65be2369fb3f8bff350cbb28e14c89d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5377
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-18 18:59:25 +01:00
Aaron Durbin c078094f39 cbfstool: add symbol table parsing to the ELF parser
Optionally parse the symbol table contained within an ELF
file. It currently assumes there is only one symbol table present,
and it errors out if more than one is found.

Change-Id: I4ac4ad03184a319562576d8ab24fa620e701672a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5376
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-14 21:51:38 +01:00
Aaron Durbin c3e6e14a12 cbfstool: add string table parsing to ELF parser
Optionally parse the string tables within an ELF file.

Change-Id: I89f9da50b4fcf1fed7ac44f00c60b495c35555ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5375
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-14 21:51:27 +01:00
Aaron Durbin ccb5ad8d3c cbfstool: add relocation parsing to ELF parser
Optionally parse the relocation entries found within an ELF
file.

Change-Id: I343647f104901eb8a6a997ddf44aa5d36c31b44b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5374
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-14 21:51:14 +01:00
Aaron Durbin d0f6165923 cbfstool: introduce struct parsed_elf and parse_elf()
In order to make the ELF parsing more flexible introduce
a parse_elf() function which takes a struct parsed_elf
parameter. In addition take a flags parameter which instructs
the ELF parser as to what data within the ELF file should be
parsed.

Change-Id: I3e30e84bf8043c3df96a6ab56cd077eef2632173
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5373
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-14 21:50:42 +01:00
Aaron Durbin 19a11d6fe9 cbfstool: remove incorrect section size check
I was overzealous in checking the section size with respect
to the file size. That check makes no sense as the section only
deals with link sizes -- not on-disk sizes. Remove the check as
it doesn't make any sense.

Change-Id: I348e7847ae3a50badc22693439614f813462445a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5384
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-03-13 23:02:46 +01:00
Aaron Durbin a31ff73e8d cbfstool: elfparsing: check segment and section regions
While parsing the section and program headers ensure the
locations of their contents are within the elf file proper.

Change-Id: I856f7de45f82ac15977abc06e51bedb51c58dde1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5372
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:31:49 +01:00
Aaron Durbin b1b5118c71 cbfstool: elfheaders: use proper parameters to calloc()
Though the result doesn't matter much, the callers of calloc()
should order the parameters correctly. i.e. the first paramter
is the number of elements in an array and the second is the
size of each element.

Change-Id: Ic7c2910d623d96f380feb4e5f6fa432376f49e9b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5371
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:57 +01: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
Aaron Durbin aa8784c2d1 cbfstool: move iself() to eflheaders.c
The only user of iself() was in elfheaders.c. Move it there,
and make it local to the compilation unit.

Change-Id: I0d919ce372f6e2fce75885fb4fcba20d985979b3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5369
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:07 +01:00
Aaron Durbin a983cea5b9 cbfstool: elfheaders: use common checks and buffer helpers
The elfheaders code was manipulating struct buffers. Use
the introduced buffer helper functions. Additionally fix
up offset and size checks for the program headers and section
headers by using common code paths.

Change-Id: I279c77f77aaa1860a0be43fb111df890dd1d84d5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5368
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:27:54 +01:00
Aaron Durbin 6e8c2790bb cbfstool: add struct buffer helper routines
There are some open-coded manipulation of the struct buffer
innards in the elf parsing code. Add helper functions to avoid
reaching into the struct itself.

Change-Id: I0d5300afa1a3549f87f588f976184e880d071682
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5367
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11 19:46:45 +01:00
Aaron Durbin 1240d29209 cbfstool: add bputs() to store a byte stream to a buffer
There was already a bgets() function which operates on a buffer to
copy a byte stream. Provide bputs() to store a byte stream to a
buffer, thus making the API symmetrical.

Change-Id: I6166f6b68eacb822da38c9da61a3e44f4c67136d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5366
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11 19:43:17 +01:00
Aaron Durbin 01650045f4 cbfstool: add get8/put8 variants to xdr structures
In order to provide consistent usage provide the get8()
and put8() callbacks to xdr operations. That way no futzing
needs to be done to handle 8-bit reads and writes.

Change-Id: I1233d25df67134dc5c3bbd1a84206be77f0da417
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5365
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11 19:42:50 +01:00
Aaron Durbin fae75172d1 cbfstool: move verbose to common.c
In order for multiple tools to use the common code found
in common.c place the verbose variable within common.c's
compilation unit.

Change-Id: I71660a5fd4d186ddee81b0da8b57ce2abddf178a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5364
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-11 19:42:30 +01:00
Alexandru Gagniuc 5edfa3779d cbfstool/lzma: Remove dead code under #ifdefs
Remove a bunch of dead code which depends either on commented out
#defines, or compiler definitions. Use this opportunity to remove the
need for "-D_7ZIP_ST" in the compiler flags.

Change-Id: Ib6629002be7bf4cee6d95d7baa724893b5e8ba32
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5083
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-03-02 05:14:30 +01:00
Alexandru Gagniuc 7c9bb41817 cbfstool/lzma: Remove code which depends on commented out defines
These options seem to control the behavior of the encoder/decoder,
with comments citing a trade-off between memory usage and performance.
I removed these in a separate patch to make reverting in the future
easier, if we find these options are useful.

Change-Id: I24cb7101b89e60f4fb96777e3681c03d2a62e3d5
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5084
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-11 20:15:48 +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
Alexandru Gagniuc ed87ebc325 cbfstool/lzma: Remove LITTLE_ENDIAN_AND_UNALIGNED_ACCESS_OK
This was designed as a micro-optimization for x86, but it is only used
once. Let the compiler decide if optimizing this is worth the effort.

Change-Id: I5939efa34f0e9d16643893ca04675247842e7db5
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5085
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-10 05:45:54 +01:00
Alexandru Gagniuc b63b75b0f7 cbfstool: Fix LzmaEnc.c and build with -Wshadow
LzmaEnc.c was full of shadow definitions. Luckily, shadow definitions
were not used after the scope in which they were redefined, so it is
possible to just remove them.

Tested by successfully booting qemu i440fx to grub2 payload.

Change-Id: I01d44db59882114ffe64434b655b931f3beec8e2
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5082
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-10 05:44:12 +01:00
Alexandru Gagniuc ae45a9884b cbfstool: Fix build errors when building with clang
Now that we can set CC to an arbitrary compiler, fix issues that clang
finds. Luckily, there were only two trivial errors.

Change-Id: I0fd1f0f263a8ab7004f39cd36ed42d1a1cba5c04
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5081
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-10 05:43:56 +01:00
Ronald G. Minnich 3fcde22a30 Add an xdr function for the cbfs_file header
And use it in fit.c and remove one more use of htonl.

Change-Id: Ibf18dcc0a7f08d75c2374115de0db7a4bf64ec1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5120
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-05 06:50:41 +01:00
Ronald G. Minnich 818f369da2 Change the linux payload generator to use the standard header generator
When I changed mkpayload, I did not realize we had a duplicate
block of code in the linux payload code. Have it use the same
header generator as the standard payload code does.

Change-Id: Ie39540089ce89b704290c89127da4c7b051ecb0e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/5115
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-05 01:00:34 +01:00
Alexandru Gagniuc 35850ae88e cbfstool: Eliminate global variable "arch"
Now that unused functions have been removed, the global "arch" is only
used in very few places. We can pack "arch" in the "param" structure
and pass it down to where it is actually used.

Change-Id: I255d1e2bc6b5ead91b6b4e94a0202523c4ab53dc
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5105
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-04 19:37:48 +01:00
Alexandru Gagniuc 2bdc0d0bd6 cbfstool: Remove more unused functions from common.c
A lot of the early functions have been re-implemented in a context-
centric mode, rather than relying on global variables. Removing these
has the nice side-effect of allowing us to remove more global
variables.

Change-Id: Iee716ef38729705432dd10d12758c886d38701a8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5104
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-04 19:37:41 +01:00
Alexandru Gagniuc c677c7d6e4 cbfstool: Hide cbfstool_offset from the global namespace
This is part of a larger effort to reduce global variable usage in
cbfstool. cbfstool_offset is particularly easy to hide since it's only
used in common.c .

Change-Id: Ic45349b5148d4407f31e12682ea0ad4b68136711
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5102
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-02-04 19:37:26 +01:00
Alexandru Gagniuc bc06691a3b cbfstool: remove unused function create_cbfs_image()
It's not used anymore. Instead, we have the better replacements
cbfs_image_create() and cbfs_image_from_file().

Change-Id: I7835f339805f6b41527fe3550028b29f79e35d13
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5103
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-03 17:02:38 +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
Alexandru Gagniuc 9ad52fe56e cbfstool/lzma: Avoid use of typedef with structs and enums
When typedef is used with structs, enums, and to create new typenames,
readability suffers. As such, restrict use of typedefs only to
creating new data types.

The 80 character limit is intentionally ignored in this patch in order
to make reviewing easier.

Change-Id: I62660b19bccf234128930a047c754bce3ebb6cf8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5070
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:06:26 +01:00
Alexandru Gagniuc 4a7b115211 cbfstool: Don't assume compiler is gcc, and use $(CC)
Change-Id: I49feb5be885369fca10c8db31329e51d87031641
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4841
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:05:58 +01:00
Alexandru Gagniuc e20f27a098 cbfstool/lzma: Remove windows-specific remnants
Remove checks for MSVC version and references to windows types and
calling conventions. Calling conventions are not needed as functions
are not exported, like in a library.

Change-Id: I884a1502cf56b193de254f017a97275c8612c670
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4836
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:05:42 +01:00
Alexandru Gagniuc 5719bdc81c cbfstool/lzma: Remove C++ remnants
The original lzma code was probably designed as a library, and had
tons of checks for __cplusplus and extern "C". They were not removed
when imported, but remove them now.

Change-Id: I4ae6e7739d191093c57130de8ae40da835e81bd1
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4835
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:05:09 +01:00
Alexandru Gagniuc 91e9f27973 cbfstool/lzma: Use stdint and stdbool types
This is the first patch on a long road to refactor and fix the lzma
code in cbfstool. I want to submit it in small atomic patches, so that
any potential errors are easy to spot before it's too late.

Change-Id: Ib557f8c83f49f18488639f38bf98d3ce849e61af
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4834
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-29 20:04:53 +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
Patrick Georgi 2a1d5b061d cbfstool: cleaner filling fields
The LARCHIVE header isn't a string (not null terminated).
It confused coverity, and while it should be obvious that
we're not aiming for any null bytes after the header, we
can also just not pretend it's a string.

Change-Id: Ibd5333a27d8920b8a97de554f1cd27e28f4f7d0a
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4088
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
2014-01-21 19:07:17 +01:00
Alexandru Gagniuc f87c20a00d cbfstool: Properly handle EOF in update_fit step
During the update_fit step, 'file_length' is used to determine how many
bytes are left in the CBFS file. It was decremented in a loop from an
array 'mcus[num_mcus].size', but 'num_mcus' was incremented right before.
Since 'mcus' is memset(0) externally, 'file_length' was never decremented.

The loop exited when it reached a dummy terminator, usually 48 bytes of 0
which are internationally added to microcode blobs in coreboot. However,
if that terminator is removed, the loop doesn't stop and continues until
it segfaults.

Change-Id: I840727add69379ffef75b694d90402ed89769e3b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-12-09 17:34:25 +01:00
Aaron Durbin 8a0cb8de65 cbfstool: check potential microcode update earlier
The update-fit command takes in a parameter for number of slots
in the FIT table. It then processes the microcobe blob in cbfs
adding those entries to the FIT table. However, the tracking of
the number of mircocode updates was incremented before validating
the update. Therefore, move the sanity checking before an increment
of the number of updates.

Change-Id: Ie8290f53316b251e500b88829fdcf9b5735c1b0e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50319
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4161
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-11-25 23:24:57 +01:00
Ronald G. Minnich 72f15bd2be cbfstool: add a constant for the aarch64
Change-Id: Ide2c8b778447de66d95bd8c55b378aa2051ac2a0
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4091
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-11-18 16:58:58 +01:00
Kyösti Mälkki ecd8424919 Fix whitespace leaked into tree
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.

Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-17 21:04:35 +02:00
Patrick Georgi de36d333c2 Add a (b)zImage parser to cbfstool
In the great tradition of LinuxBIOS this allows adding
a kernel as payload. add-payload is extended to also
allow adding an initial ramdisk (-I filename) and a
command line (-C console=ttyS0).

Change-Id: Iaca499a98b0adf0134e78d6bf020b6531a626aaa
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3302
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-08-31 08:58:34 +02: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
Peter Stuge 3bfd5b8252 cbfstool: Add an add-int command that adds a raw 64-bit integer CBFS file
This simplifies storing SeaBIOS parameters in CBFS.

Change-Id: I301644ba0d7a9cb5917c37a3b4ceddfa59e34e77
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3733
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-08-15 20:46:09 +02:00
Paul Menzel 2c8f81b57b cbfstool: cbfs-mkstage.c: Free `buffer` on error path
Cppcheck warns about a memory leak, present since adding romtool,
which was renamed to cbfstool, in commit 5d01ec0f.

    $ cppcheck --version
    Cppcheck 1.59
    […]
    [cbfs-mkstage.c:170]: (error) Memory leak: buffer
    […]

Indeed the memory pointed to by `buffer` is not freed on the error path,
so add `free(buffer)` to fix this.

Change-Id: I6cbf82479027747c800c5fe847f20b779e261ef4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3069
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-04-12 20:22:39 +02:00
Stefan Reinauer 33e83caff5 cbfstool: completely initialize input and output streams
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:

        commit aa3f7ba36e
        Author: Stefan Reinauer <reinauer@chromium.org>
        Date:   Thu Mar 28 16:51:45 2013 -0700

            cbfstool: Replace C++ code with C code

            Reviewed-on: http://review.coreboot.org/3010

In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.

Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08 21:36:37 +02:00
Stefan Reinauer aa3f7ba36e cbfstool: Replace C++ code with C code
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.

Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-03 02:35:28 +02:00
Stefan Reinauer 60a4a73fcd cbfstool: fix --machine
The help text says --machine, but the code
actually checked for --arch. Fix it!

Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-02 20:27:10 +02:00
Aaron Durbin 6b0d0d6e14 cbfstool: Add update-fit command
Add support for filling in the Firmware Interface Table.
For now it only supports adding microcode entries.

It takes 2 options:
1. Name of file in cbfs where the mircocode is located
2. The number of empty entries in the table.

Verified with go firmware tools. Also commented out updating
microcode in the bootblock. When romstage runs, the CPUs indicate
their microcode is already loaded.

Change-Id: Iaccaa9c226ee24868a5f4c0ba79729015d15bbef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2712
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
2013-03-27 01:25:12 +01: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 e91983767c cbfstool locate: Rename -a align switch to -P for page size
cbfstool usage change:
   The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size".

The "locate" command was used to find a place to store ELF stage image in one
memory page. Its argument "-a (alignment)" was actually specifying the page size
instead of doing memory address alignment. This can be confusing when people are
trying to put a blob in aligned location (ex, microcode needs to be aligned in
0x10), and see this:
  cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000
  # output: 0x44, which does not look like aligned to 0x40000.

To prevent confusion, it's now switched to "-P/--page-size".

Verified by building i386/axus/tc320 (with page limitation 0x40000):
 cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
 # output: 0x44

Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731
Reviewed-on: http://review.coreboot.org/2730
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-03-19 11:12:10 +01:00
Paul Menzel a46a712610 GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.

The following command was used to convert all files.

    $ git grep -l 'MA  02' | xargs sed -i 's/MA  02/MA 02/'

[1] http://www.gnu.org/licenses/gpl-2.0.txt

Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-01 10:16:08 +01:00
Hung-Te Lin 7b654a9702 cbfstool: Fix compile warnings caused by incorrect data types.
The "offset" in cbfs-mkpayload should be printed as type %lu
instead of %d as `gcc` rightfully warns about.

    gcc -g -Wall -D_7ZIP_ST -c -o /srv/filme/src/coreboot/util/cbfstool/cbfs-mkpayload.o cbfs-mkpayload.c
    cbfs-mkpayload.c: In function ‘parse_fv_to_payload’:
    cbfs-mkpayload.c:284:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
    cbfs-mkpayload.c:296:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]

This warning was introduced in the following commit.

    commit 4610247ef1
    Author: Patrick Georgi <patrick@georgi-clan.de>
    Date:   Sat Feb 9 13:26:19 2013 +0100

        cbfstool: Handle alignment in UEFI payloads

        Reviewed-on: http://review.coreboot.org/2334

Change-Id: I50c26a314723d45fcc6ff9ae2f08266cb7969a12
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2440
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
2013-02-18 12:28:43 +01:00
Paul Menzel 475d42a16c cbfstool: Add `-Werror` to make all warnings into errors
Ensure that no changes with warnings are committed. Although using
`-Werror` is debatable [1][2].

[1] http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror
[2] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

Change-Id: I402f2d82dd4087d8a575b0a85305a02ef04bb537
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2441
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-02-18 12:10:44 +01:00
Patrick Georgi 4610247ef1 cbfstool: Handle alignment in UEFI payloads
Tiano for X64 is much cleaner to start up when using higher alignments in
firmware volumes. These are implemented using padding files and sections
that cbfstool knew nothing about. Skip these.

Change-Id: Ibc433070ae6f822d00af2f187018ed8b358e2018
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2334
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-09 20:58:22 +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
Stefan Reinauer e87641840f cbfstool: Add support for 64bit UEFI
Right now cbfstool only accepts firmware volumes with
a x86 SEC core and refuses an x86-64 SEC core because
some magic values and the extended PE header are
different. With this patch, both IA32/x64 images are
supported. (No check is done whether the mainboard
actually supports 64bit CPUs, so careful!)

This needs another patch to Tiano Core that switches
to long mode after jumping to the 64bit entry point.
Right now that code assumes we're already in 64bit code
and the machine crashes.

Change-Id: I1e55f1ce1a31682f182f58a9c791ad69b2a1c536
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2283
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-02-06 00:37:26 +01:00
Stefan Reinauer 543a682458 cbfstool: support parsing UEFI firmware volumes
This removes the hack implemented in http://review.coreboot.org/#/c/2280
(and should make using 64bit Tiano easier, but that's not yet supported)

Change-Id: Ie30129c4102dfbd41584177f39057b31f5a937fd
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2281
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:43:23 +01:00
Hung-Te Lin c13e4bf3e1 cbfstool: Use cbfs_image API for "add-*" (add-payload, add-stage, ...) commands.
add-payload, add-stage, and add-flat-binary are now all using cbfs_image API.
To test:
	cbfstool coreboot.rom add-stage -f FILE -n fallback/romstage -b 0xXXXX
	cbfstool coreboot.rom add-payload -f FILE -n fallback/pyload
And compare with old cbfstool.

Verified to boot on ARM(snow) and X86(qemu-i386).

Change-Id: If65cb495c476ef6f9d90c778531f0c3caf178281
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2220
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:27:20 +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
Hung-Te Lin 3cfacbf196 cbfstool: Add buffer management API.
Many functions in cbfstool need to deal with a memory buffer - both location and
size. Right now it's made by different ways: for ROM image using global variable
(romsize, master_header); and in cbfs-* using return value for size and char**
to return memory location.

This may cause bugs like assuming incorrect return types, ex:
	uint32_t file_size = parse();	// which returns "-1" on error
	if (file_size <= 0) { ...
And the parse error will never be caught.

We can simplify this by introducing a buffer API, to change
	unsigned int do_something(char *input, size_t len, char **output, ...)
into
	int do_something(struct buffer *input, struct buffer *output, ...)

The buffer API will be used by further commits.

Change-Id: Iaddaeb109f08be6be84c6728d72c6a043b0e7a9f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2205
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-05 22:24:45 +01:00
Hung-Te Lin 5be66730cf cbfstool: Update example file.
The syntax of cbfstool has been changed for a while (using getopt). Updated
EXAMPLE file to show the right way to test cbfstool.

Change-Id: I5cb41b76712d8c2403fffc9fdad83c61fb2af98c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2215
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-04 11:12:15 +01:00
Hung-Te Lin 332795cc59 cbfstool: Make endian detection functions to work without prior setup.
The 'host_bigendian' variable (and functions relying on it like ntohl/htonl)
requires host detection by calling static which_endian() first -- which may be
easily forgotten by developers.  It's now a public function in common.c and
doesn't need initialization anymore.

Change-Id: I13dabd1ad15d2d6657137d29138e0878040cb205
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2199
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-02-01 06:50:17 +01:00
Hung-Te Lin 05dccae75d cbfstool: move flat-binary parsing to cbfs-mkpayload.
The ELF parsing and payload building in add-flat-binary command should be
isolated just like mkpayload and mkstage.

Since the add-flat-binary command creates a payload in the end , move payload
processing to cbfs-mkpayload.c.

To test:
   cbfstool coreboot.rom add-flat-binary -f u-boot.bin -n fallback/payload \
	-l 0x100000 -e 0x100020

To verify, get output from "cbfstool coreboot.rom print -v":
   fallback/payload               0x73ccc0   payload      124920
   INFO:     code  (no compression, offset: 0x38, load: 0x1110000, length:..)

Change-Id: Ia7bd2e6160507c0a1e8e20bc1d08397ce9826e0d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2197
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-01 06:06:41 +01:00
Hung-Te Lin 4d87d4e09b cbfstool: Add -v (verbose) output.
Add -v (verbose) to every command, and allow printing debug messages.

Revise logging and debugging functions (fprintf(stderr,...), dprintf...)
and verbose message printing with following macros:
	ERROR(xxx):	E: xxx
	WARN(xxx)	W: xxx
	LOG(xxx)	xxx
	INFO(...)	INFO: xxx  (only when runs with -v )
	DEBUG(...)	DEBUG: xxx (only when runs with more than one -v)

Example:
	cbfstool coreboot.rom print -v
	cbfstool coreboot.rom add -f file -n file -t raw -v -v

Normal output (especially for parsing) should use printf, not any of these
macros (see usage() and cbfs_locate(), cbfs_print_directory() for example).

Change-Id: I167617da1a6eea2b07075b0eb38e3c9d85ea75dc
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2196
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-01 05:54:24 +01:00
Hung-Te Lin 5a9f45c757 cbfstool: Prevent file name to be corrupted by basename().
Calling basename(3) may modify content. We should allocate another buffer to
prevent corrupting input buffer (full file path names).

Change-Id: Ib4827f887542596feef16e7829b00444220b9922
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2203
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-01-30 03:07:34 +01:00
Hung-Te Lin 657ea6a13d cbfstool: Change "locate" output to prefix "0x".
Currently "cbfstool locate" outputs a hex number without "0x" prefix.
This makes extra step (prefix 0x, and then generate another temp file) in build
process, and may be a problem when we want to allow changing its output format
(ex, using decimal). Adding the "0x" in cbfstool itself should be better.

Change-Id: I639bb8f192a756883c9c4b2d11af6bc166c7811d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2201
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-01-29 06:08:31 +01:00
Hung-Te Lin 4505cebdad cbfstool: Remove unused header files.
cbfs-mk*.c does not work with real files / command line so header files with
file I/O and getopt can be removed.

Change-Id: I9d93152982fd4abdc98017c983dd240b81c965f5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2200
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-01-29 04:14:43 +01:00
Hung-Te Lin d173962c6e cbfstool: Store global variables into struct.
cbfstool.c uses lots of global variables for command line options and all named
as "rom*". This may be confusing when other global variables also start with
rom, ex:	int size = rom_size + romsize;
(rom_size is from command line and romsize is the size of last loaded ROM image).

If we pack all rom_* into a struct it may be more clear, ex:
	do_something(param.cbfs_name, param.size, &romsize);

Change-Id: I5a298f4d67e712f90e998bcb70f2a68b8c0db6ac
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2195
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-01-28 19:59:40 +01:00
Stefan Reinauer db5b893569 Add more information to the cbfstool print
Show what's in a stage or payload. This will let people better understand
what's in a stage or payload.

Change-Id: If6d9a877b4aedd5cece76774e41f0daadb20c008
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2176
Tested-by: build bot (Jenkins)
2013-01-19 02:19:14 +01:00
David Hendricks 0b23d47ffd armv7: Place reset vector + CBFS header + bootblock dynamically
This replaces hard-coded bootblock offsets using the new scheme.
The assembler will place the initial branch instruction after BL1,
skip 2 aligned chunks, and place the remaining bootblock code after.

It will also leave an anchor string, currently 0xdeadbeef which
cbfstool will find. Once found, cbfstool will place the master CBFS
header at the next aligned offset.

Here is how it looks:

             0x0000 |--------------|
                    |     BL1      |
             0x2000 |--------------|
                    |    branch    |
    0x2000 + align  |--------------|
                    |  CBFS header |
0x2000 + align * 2  |--------------|
                    |   bootblock  |
                    |--------------|

TODO: The option for alignment passed into cbfstool has always been
64. Can we set it to 16 instead?

Change-Id: Icbe817cbd8a37f11990aaf060aab77d2dc113cb1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-01-17 01:06:43 +01:00