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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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)
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>
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>
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>
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>
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>
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>
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>
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>
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>
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)
- 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)
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>
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)
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)
Aaron Durbin