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 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>
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>
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>
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)
The 'VERSION' in CBFS header file is confusing and may conflict when being used
in libpayload.
Change-Id: I24cce0cd73540e38d96f222df0a65414b16f6260
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2098
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
to CBFS and adapt coreboot to use it.
Comments by Stefan and Mathias taken into account (except for
the build time failure if the table is missing when it should
exist and the "memory leak" in build_opt_tbl)
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6268 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
If a file "cmos.default", type "cmos default"(0xaa) is in CBFS,
a wrong checksum leads to coreboot rewriting the first 128 bytes
(except for clock data) with the data in cmos.default, then
reboots the system so every component of coreboot works with the
same set of values.
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Acked-by: Stefan Reinauer <stepan@coreboot.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6253 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This is needed on the IP1000T to get VGA output. The VGA option rom will ask
through an SMI for hardware specifics (in form of a VBT, video bios table)
which the SMI handler copies into the VGA option rom.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5177 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
src/lib/ code in coreboot. I.e. the tool changes but the coreboot code
does not.
Currently, as cbfstool manages the ROM, there are files and empty
space. To allocate files, the code does, first, a walk of the headers
and, if that fails, does a brute-force search of the rest of the
space.
We all agree that the brute-force search has lots of problems from a
performance and correctness standpoint.
I've made a slight change. Instead of an "empty space" area with no
valid headers, I've made a header for the empty space.
So cbfs creation looks like this:
- set up the boot block
- create a file, of type CBFS_COMPONENT_NULL, that contains the empty
space. CBFS_COMPONENT_NULL was already defined in cbfs.h
Here's an example:
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs create 1048576 2048
(cbfstool) E: Unable to open (null): Bad address
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
0x0 0xffffffff 1046456
So how do we create a new file?
It's easy: walk the files and find a file of type CBFS_COMPONENT_NULL,
which is as large
or larger than the file you are trying to create. Then you use that file.
- if the file is the same size as the NULL file, then it's easy: take it
- if the file is smaller than the NULL file, you split the NULL file
into two parts.
note that this works in the base case: the base case is that the whole
storage is CBFS_COMPONENT_NULL.
Here's an example of adding a file.
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed t
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
t 0x0 stage 23176
0x5ab0 0xffffffff 1023240
Note that the NULL split and got smaller. But the entire ROM is still
contained by the two files. To walk this entire rom will require two
FLASH accesses.
Add another file:
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs add-stage testfixed tt
[rminnich@xcpu2 cbfstool]$ ./cbfstool testcbfs print
testcbfs: 1024 kB, bootblocksize 2048, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
t 0x0 stage 23176
tt 0x5ab0 stage 23176
0xb560 0xffffffff 1000024
[rminnich@xcpu2 cbfstool]$
So, taking current ROMs as an example, I can reduce FLASH accesses for
cbfs from (potentially) thousands to (typically) less than 10.
Index: fs.c
Changes for readability and cleanliness. Move common blobs of code to functions.
New function: rom_alloc,which allocates files by finding NULL files and using/splitting.
Other changes as needed to support this usage.
Index: util.c
Creating a cbfs archive now requires creation of a NULL file covering the file system space.
Index: cbfs.h
Add a DELETED file type with value 0. Any file can be marked deleted by zero its type; this is a
FLASH-friendly definition for all known FLASH types.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
I think it is a step in the right direction. Could you add the
function prototype to cbfstool.h?
Acked-by: Myles Watson <mylesgw@gmail.com>
(I added the prototype)
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4261 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It's all sed here. romfs->cbfs, ROMFS->CBFS, romtool->cbfstool
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4110 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Ronald G. Minnich