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>
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>
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>
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>
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>
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>
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 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>
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>
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 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>
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>
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>
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>
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>
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>
Most hton and noth functions are already available
through the system headers we include on OS X, causing
the compiler to warn about duplicate definitions.
Change-Id: Id81852dfc028cf0c48155048c54d431436889c0e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2106
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This is an initial re-factoring of CBFS code to enable multiple
architectures. To achieve a clean solution, an additional field
describing the architecture has to be added to the master header.
Hence we also increase the version number in the master header.
Change-Id: Icda681673221f8c27efbc46f16c2c5682b16a265
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/1944
Tested-by: build bot (Jenkins)
- Adding more and more optional and non-optional parameters
bloated cbfstool and made the code hard to read with a lot
of parsing in the actual cbfs handling functions. This change
switches over to use getopt style options for everything but
command and cbfs file name.
- This allows us to simplify the coreboot Makefiles a bit
- Also, add guards to include files
- Fix some 80+ character lines
- Add more detailed error reporting
- Free memory we're allocating
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9137942deb8d26bbb30068e6de72466afe9b0a7
Reviewed-on: http://review.coreboot.org/1800
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
CBFS allows coreboot rom images that are only partially covered
by the filesystem itself. The intention of this feature was to
allow EC / ME / IMC firmware to be inserted easily at the beginning
of the image. However, this was never implemented in cbfstool.
This patch implements an additional parameter for cbfstool.
If you call cbfstool like this:
cbfstool coreboot.rom create 8192K bootblock.bin 64 0x700000
it will now create an 8M image with CBFS covering the last 1M of
that image.
Test:
cbfstool coreboot.rom create 8192K bootblock.bin 64 0x700000
creates an 8M image that is 7M of 0xff and 1M of CBFS.
Change-Id: I5c016b4bf32433f160b43f4df2dd768276f4c70b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1708
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To complement commit e1bb49e (Add a "remove" command to cbfstool) and
fix a compiler warning provide a prototype for remove_file_from_cbfs.
Change-Id: Ied8eac956de5fed3f9d82ce1e911ee1fec52db15
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/1235
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
It dumps everything you ask for, but you might not
get what you expect if the file is compressed or
otherwise converted (eg. payloads in SELF format).
(Originally it would only extract "raw" files.
This is a change by me, as filetypes are commonly used
to differentiate raw data files --Patrick)
Signed-off-by: Aurelien Guillaume <aurelien@iwi.me>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6250 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* use relative paths in ldscript.ld and crt0_includes.h
* avoid use of dd(1) in xcompile
* build libregex for kconfig, if necessary
* work around missing utsname on win32
* unlink targets before rename on win32
* implement (crude) mkstemp for win32
* avoid open/read/close, use fopen/fread/fclose instead
* don't free certain data structures in romcc on win32 to
avoid crashes (likely use-after-free())
* handle "\CRLF" and win32 style absolute paths (X:/ or X:\)
in romcc
* make lzma (part of cbfstool) build on XP
* implement ntohl/htonl on win32
* handle CRLF in awk script
* set larger stack for romcc on win32
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4952 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
out a suitable address to put a XIP stage to.
Specifically, you pass it the file (to get its filesize), its filename
(as the header has a variable length that depends on it), and the
granularity requirement it has to fit in (for XIP).
The granularity is MTRR-style: when you request 0x10000, cbfstool looks
for a suitable place in a 64kb-aligned 64kb block.
cbfstool simply prints out a hex value which is the start address of a
suitably located free memory block. That value can then be used with
cbfs add-stage to store the file in the ROM image.
It's a two-step operation (instead of being merged into cbfs add-stage)
because the image must be linked twice: First, with some bogus, but safe
base address (eg. 0) to figure out the target address (based on file
size). Then a second time at the target address.
The work flow is:
- link file
- cbfstool locate
- link file again
- cbfstool add-stage.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4929 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* fix an issue that could lead to cbfstool writing outside of its allocated
memory
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4653 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
supports fixed location files. Some parts are salvaged
from the pre-commit version (esp. stage and payload creation),
others are completely rewritten (eg. the main loop that handles
file addition)
Also adapt newconfig (we don't need cbfs/tools anymore) and fix
some minor issues in the cbfstool-README.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4630 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Gabe Black