There are currently 2 uses for rmodule programs: stand alone
programs that are separate from the coreboot stages and a
relocatable ramstage. For the ramstage usage there's no reason
to require a rmodule parameter section. Therefore make this
optional.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built ramstage w/ normal linking (w/o a rmodule parameter
section). No error.
Change-Id: I5f8a415e86510be9409a28068e3d3a4d0ba8733e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11523
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Whenever we want to add a file to CBFS with a specific alignment, we
have to do two cbfstool invocations: one to find a place for the file,
and another to actually add the file to CBFS. Get rid of this nonsense
and allow this to be done in one step.
Change-Id: I526483296b494363f15dc169f163d93a6fc71bb0
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11525
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
According to https://gcc.gnu.org/gcc-4.6/changes.html it's only in gcc 4.6,
not 4.5, which I mistakenly believed.
Change-Id: I8212e7921bd9d1436a0ba491cbe6c4d473228956
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11476
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Tested-by: build bot (Jenkins)
This isn't required for correct execution, and doesn't need to be tested
on every single compiler out there.
Since GCC < 4.5 has no idea about _Static_assert, hide it there. Our
build tests will make sure that the test is run before changes are
submitted to master.
Change-Id: I4141f4aa23b140d2d1017ca7b4dace5aa7db0c04
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11475
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Display compressed and decompressed sizes, as well as the compression
algorithm used, when a compressed file is encountered.
Change-Id: I13c2332702c4a5bec379e1ebda72753e06f8e135
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11359
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, compression is only allowed at subheader level (e.g. cbfs_stage,
cbfs_payload_segment). This change adds compression field to each file's
header so that any cbfs file can be compressed.
With the necessary additions in coreboot and libpayload, the following sample
code can load a compressed file:
const char *name = "foo.bmp";
struct cbfs_file *file = cbfs_get_file(media, name);
void *dst = malloc(ntohl(file->uncompressed_size));
dst = cbfs_get_file_content(media, name, type, file, dst);
cbfs_stage and cbfs_payload_segment continue to support compression at
subheader level because stages and payloads have to be decompressed to the load
address, which is stored in the subheader. For these, file level compression
should be turned off.
Change-Id: I9a00ec99dfc68ffb2771bb4a3cc5ba6ba8a326f4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have tons of file types now that can be safely extracted.
It's pretty much only stages and payloads that aren't.
Change-Id: Ibf58a2c721f863d654537850c6f93d68a8a5bbeb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11360
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
My concern was that compilers may something stupid under the assumption
of a fixed struct size, but filename is already variable, so things are
okay.
Change-Id: I5348faf68f0a7993294e9de4c0b6c737278b28af
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They're passed as part of the header now.
Change-Id: I7cd6296adac1fa72e0708b89c7009552e272f656
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11327
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The header is now created before the "converters" are run.
Adding new capabilities (and fields to the header) will happen there,
so we're close.
Change-Id: I0556df724bd93816b435efff7d931293dbed918f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11326
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These functions can do all kinds of things, such as converting an ELF
image into SELF, or (in the future) compress or checksum entire files.
This may require changing or adding fields to the header, so they
need to have access to it.
The header_size parameter that was provided (but never used) is
equivalent to cbfs_file's offset field.
Change-Id: I7c10ab15f3dff4412461103e9763a1d78b7be7bb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11325
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's sole use was comparing it to the header's "len" field.
Change-Id: Ic3657a709dee0d2b9288373757345a1a56124f37
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11324
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
->len used to be set to the file data length plus the size of the
padding used for the cbfs_file header. This isn't the case anymore,
so no patching of this field is necessary anymore.
->offset still needs to be patched in that case because its final
value can only be determined when the file's actual location is known.
Change-Id: I1037885f81b4ed3b68898dd7d0e515cf7a9c90a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11322
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now cbfstool creates the cbfs_file header at the latest possible
time, which is unsuitable when the idea is to add further fields to it
that need to be configured earlier.
Thus, have it ripple up the call chain.
Change-Id: I7c160681c31818bc550ed2098008146043d0ee01
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
"target", for what? It's the offset where the file header of the currently
added file will be located, name it as such.
Change-Id: I382f08f81991faf660e217566849773d9a7ec227
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
After the preparation in earlier commits, it is now possible to handle the
more general case of position independent files using the special code path
for fixed location files.
This leads to a single place where non-empty cbfs file headers are actually
written into the image, allowing us to move it up the chain more easily.
Change-Id: I8c1fca5e4e81c20971b2960c87690e982aa3e274
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11222
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
... and the assert is gone.
The actual action of adding a just-right file can be moved after the tests
since it's exactly the condition those tests don't continue or break on.
Change-Id: I6d0e829e0158198301136ada9a0de2f168ceee3f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11221
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The assert() makes sure the if() holds true. But that assert won't survive for
long.
Change-Id: Iab7d2bc7bfebb3f3b3ce70dc5bd041902e14bd7a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11220
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We will want to create headers that live outside the final image at some point
(eg. to build the file before we even know where to place it).
Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11219
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pass the file type into it instead of creating an entry, then modifying the
header field again after the fact.
Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11218
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If an earlier stage built a larger header, cbfs_add_entry_at() shouldn't
decide to go with the most boring, least featureful header type (and its size)
instead.
Change-Id: Icc5dcd9a797a0f3c42f91cddd21b3b3916095b63
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The idea is that they can at some point add extended attributes to the header.
That also needs to be passed, but let's start simple.
Change-Id: I80359843078b149ac433ee3d739ea192592e16e7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It will at some point create the header, and pass it with its size. We can
start with the size already.
Change-Id: I8f26b2335ffab99a664d1ff7bc88e33ed62cf9ca
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11215
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Headers vary in size soon, and more places need to be able to calculate their
size.
Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11214
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is in preparation of creating the cbfs_file header much earlier
in the process. For now, size is enough because lots of things need to
move before it makes sense to deal with cbfs_file at a higher level.
Change-Id: I47589247c3011cb828170eaa10ef4a1e0f85ab84
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to read the file before bailing out.
Change-Id: Ida7226c6ec227e1105724cdb1e5a0927217a69c7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11212
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a generic structure, not unlike the cbtables design, based on which we
can build specialized TLV data structures.
Change-Id: I98a75eef19f049ad67d46cdc2790949dcd155797
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code for removing a file had its own merge routine. Use the generic one
instead.
Change-Id: I90ed007ab86f78a2728f529fa0143c5c1dfbbdc3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10967
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So far it's still unused, but its purpose will change:
It will become an offset to another structure that contains additional file
attributes.
This change is compatible because the binary format doesn't change and so far
the field was always set to 0, which can serve nicely as 'unused' field.
Change-Id: I2dafb06866713d43a236556f9492641526270837
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10933
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Trailing commas are useful for lists that can be extended. These lists are
0-terminated, and there should be no elements following that.
Change-Id: Iea8c6d5579d6363e77e1f5af666948160c4a9bf9
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10932
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Parse compression algorithm arguments using a single list.
Change-Id: Idc5b14a53377b29964f24221e42db6e09a497d48
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10931
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With introducing hash algorithms, 'algo' is ambiguous, so rename it to
'compression' instead.
Change-Id: Ief3d39067df650d03030b5ca9e8677861ce682ed
Signed-off-by: Sol Boucher <solb@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Change-Id: I1a117a9473e895feaf455bb30d0f945f57de51eb
Original-Signed-off-by: Sol Boucher <solb@chromium.org>
Reviewed-on: http://review.coreboot.org/10930
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Lock down its size and document some of the fields
Change-Id: I09fd6c80185345da0ae17d0f4498b50995fd1ec5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10927
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
It's not like we _ever_ changed it, so drop the option and make cbfstool
use the default. always.
Change-Id: Ia1b99fda03d5852137a362422e979f4a4dffc5ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10918
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
rmodule.c: In function ‘rmodule_create’:
rmodule.c:287:29: error: ‘phdr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
(phdr->p_vaddr + phdr->p_memsz))) {
^
rmodule.c:204:14: note: ‘phdr’ was declared here
Elf64_Phdr *phdr;
^
Change-Id: I94a235253610348484eef218ec855103a3bb5da5
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Reviewed-on: http://review.coreboot.org/10881
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
On Windows systems, structs can be packed gcc style or ms style.
Make sure we use the same one (gcc style) in our user space tools
that we use in coreboot.
Change-Id: I7a9ea7368f77fba53206e953b4d5ca219ed4c12e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10794
Tested-by: build bot (Jenkins)
Aaron Durbin