Currently cbfstool would reject non-alpanumeric characters in
image names. Underscore is not alphanumeric and is used in some
default fmaps. This change allows image names to contain all
"printable" characters except spaces.
Change-Id: I6ba2b581d5623f5b028149ece0169892ea63fd04
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: http://review.coreboot.org/11807
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When adding an FSP blob relocate it to its final
destination. This allows FSP to not be hard coded in
the cbfs. In order for the include paths to work
correctly w/ the edk 2 headers we need to supply
a neutered ProcessorBind.h to match up with the
tool environment such that one can get the UEFI
Platform Initialization type definitions.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados and booted. Also added FSP with -b and manually
adjusted location in fsp cache-as-ram. Booted as well.
Change-Id: I830d93578fdf745a51195109cf18d94a83ee8cd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11778
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For shared compilation units between coreboot proper
and cbfstool that means one needs to provide printk
logging. Therefore, provide printk() at <console/console.h>
to mimic coreboot's environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built cbfstool with code that includes and uses
<console/console.h>.
Change-Id: I8e54d403526a397e4fd117738a367a0a7bb71637
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11774
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Older gcc versions throws a warning when a struct or union is
declared without a valid name (anonymous). This patch enables the
feature for older gcc versions so that no warning will be issued.
Change-Id: Idc5481f4d5723c5090a6f7d7dbb0686a737e11fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
They allow optimizing a verification of a whole CBFS image by only
dealing with the headers (assuming you choose to trust the hash
algorithm(s)).
The format allows for multiple hashes for a single file, and cbfstool
can handle them, but right now it can't generate such headers.
Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/,
but using the compatible file attribute format. vboot is now a hard
dependency of the build process, but we import it into the tree for
quite a while now.
Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11767
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We need to emit some hex strings.
Change-Id: I9e7e184282f6ad0470f2e269f5dc874e78f8b697
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11766
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now, if both fmap and a master header existed, the master header
was used. Now, use the master header only if no fmap is found.
Change-Id: Iafbf2c9dc325597e23a9780b495549b5d912e9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11629
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On x86, the bootblock can (and will) become part of the regular file
system, so there's no distinct fixed-size region for the bootblock
there.
Change-Id: Ie139215b73e01027bc0586701361e9a0afa9150e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11691
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
$(src) is not defined when building directly from the cbfs directory (that is,
when building cbfs as standalone, running make in the cbfs directory), so we
need to define the path to the commonlib include path relative to $(top).
Change-Id: I72e80b030d4a156ec653ded5ab1457b16f612526
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11706
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
endian.h lives in under sys on the BSDs. Replace htole32() with
swab32(htonl(..)) as a proxy for little endian operations.
Change-Id: I84a88f6882b6c8f14fb089e4b629e916386afe4d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11695
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Since fmap doesn't come with a checksum, we resort to a number of
heuristics to determine if a given location hosts an fmap (instead of
another data structure that happens to store the fmap magic string at
the right location).
The version test is particularly effective against strings containing
the magic (which either terminate with 0, or have some other ASCII data,
but rarely a '\001' byte inside the string).
Change-Id: Ic66eb0015c7ffdfe25e0054b7838445b8ba098e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11690
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The command adds a new cbfs file, fills in the CBFS meta data in cbfs
master header format, then points the master header pointer (which
resides at the last 4 bytes of the CBFS region) to the data area of the
new file.
This can leak some space in CBFS if an old-style CBFS with native master
header gets the treatment, because a new header is created and pointed
at. flashmap based images have no such header, and the attempt to create
a second file with the (hardcoded) name will fail.
Change-Id: I5bc7fbcb5962b35a95261f30f0c93008e760680d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11628
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Let's move x86 style bootblocks (and later the others) and the master header
into the CBFS structure. Prepare for this by adding file types.
Change-Id: I1b4149c7f3b8564ee358a2c18ba91e6a7a6797da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11627
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
fileno() is a mess on some operating systems. Don't
deliberately convert between FILE * and file handles.
Change-Id: I5be62a731f928333ea2e5843d81f541453fdb396
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11636
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There's no need to maintain two lists of dependencies that need to be
changed every. single. time.
Change-Id: I26bb8c884e98afe74fd9df11464bcf88e130cd92
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11674
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It was added to an unused variable.
Change-Id: I869ffdda7e04b5c615931473c760d66b803fb98b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11673
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The locate command was previously being used for x86 romstage
linking as well as alignment handling of files. The add command
already supports alignment so there's no more users of the
locate command. Remove the command as well as the '-T' (top-aligned)
option.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Noted microcode being directly added.
Change-Id: I3b6647bd4cac04a113ab3592f345281fbcd681af
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11671
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of going through the locate then add-stage
dance while linking romstage twice allow for adding romstage
with --xip flags to perform the relocation while adding it
into CBFS. The -P (page-size) and -a (alignment) parameters
were added as well so one could specify the necessary
parameters for x86 romstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I585619886f257e35f00961a1574009a51c28ff2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11669
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbfs_locate_entry() function had a hack in there which
assumed a struct cbfs_stage data was being added in addition
to the struct cbfs_file and name. Move that logic out to the
callers while still maintaining the logic for consistency.
The only impacted commands cbfs_add and cbfs_locate, but
those are using the default 'always adding struct cbfs_stage'
in addition to cbfs_file + name. Eventually those should be
removed when cbfs_locate is removed as cbfs_add has no smarts
related to the cbfs file type provided.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I2771116ea1ff439ea53b8886e1f33e0e637a79d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11668
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to allow cbfstool to add XIP romstage on x86 without
doing the 'cbfstool locate', relink, then 'cbfstool add' dance
expose the core logic and of rmodule including proving an optional
filter. The filter will be used for ignoring relocations to the
.car.global region.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I192ae2e2f2e727d3183d32fd3eef8b64aacd92f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11598
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The core logic of the rmodule parser is ideal for
processing romstage ELF files for XIP. To that
end start the work of exposing the logic from
rmodule so cbfstool can take advantage of it.
The properties that both need require:
- Single program segment
- Relocation information
- Filter relocation processing
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I176d0ae0ae1933cdf6adac67d393ba676198861a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11595
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We had two mappings of filetype IDs to strings. We shouldn't.
Change-Id: I08e478b92f3316139f14294e50ede657c7d5fb01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Andrey Petrov