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)
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The "offset" in cbfs-mkpayload should be printed as type %lu
instead of %d as `gcc` rightfully warns about.
gcc -g -Wall -D_7ZIP_ST -c -o /srv/filme/src/coreboot/util/cbfstool/cbfs-mkpayload.o cbfs-mkpayload.c
cbfs-mkpayload.c: In function ‘parse_fv_to_payload’:
cbfs-mkpayload.c:284:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
cbfs-mkpayload.c:296:3: warning: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘long unsigned int’ [-Wformat]
This warning was introduced in the following commit.
commit 4610247ef1
Author: Patrick Georgi <patrick@georgi-clan.de>
Date: Sat Feb 9 13:26:19 2013 +0100
cbfstool: Handle alignment in UEFI payloads
Reviewed-on: http://review.coreboot.org/2334
Change-Id: I50c26a314723d45fcc6ff9ae2f08266cb7969a12
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2440
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Tiano for X64 is much cleaner to start up when using higher alignments in
firmware volumes. These are implemented using padding files and sections
that cbfstool knew nothing about. Skip these.
Change-Id: Ibc433070ae6f822d00af2f187018ed8b358e2018
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2334
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On platforms with CBFS data filling end of ROM image without bootblock in the
end (ex, ARM), calculation of "next valid entry" may exceed ROM image buffer in
memory and raise segmentation fault when we try to compare its magic value.
To fix this, always check if the entry address is inside ROM image buffer.
Verified to build and boot successfully on qemu/x86 and armv7/snow.
Change-Id: I117d6767a5403be636eea2b23be1dcf2e1c88839
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2330
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
For arm/snow, current bootblock is larger than previously assigned CBFS offset
and will fail to boot. To prevent this happening again in future, cbfstool now
checks if CBFS will overlap bootblock.
A sample error message:
E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000)
E: Failed to create build/coreboot.pre1.tmp.
arm/snow offset is also enlarged and moved to Kconfig variable.
Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2295
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Right now cbfstool only accepts firmware volumes with
a x86 SEC core and refuses an x86-64 SEC core because
some magic values and the extended PE header are
different. With this patch, both IA32/x64 images are
supported. (No check is done whether the mainboard
actually supports 64bit CPUs, so careful!)
This needs another patch to Tiano Core that switches
to long mode after jumping to the 64bit entry point.
Right now that code assumes we're already in 64bit code
and the machine crashes.
Change-Id: I1e55f1ce1a31682f182f58a9c791ad69b2a1c536
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2283
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
The "add" command is compatible with all legacy usage. Also, to support
platforms without top-aligned address, all address-type params (-b, -H, -l) can
now be ROM offset (address < 0x8000000) or x86 top-aligned address (address >
0x80000000).
Example:
cbfstool coreboot.rom add -f config -n config -t raw -b 0x2000
cbfstool coreboot.rom add -f stage -n newstage -b 0xffffd1c0
Verified boot-able on both ARM(snow) and x86(QEMU) system.
Change-Id: I485e4e88b5e269494a4b138e0a83f793ffc5a084
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2216
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Usage Changes: To support platforms with different memory layout, "create" takes
two extra optional parameters:
"-b": base address (or offset) for bootblock. When omitted, put bootblock in
end of ROM (x86 style).
"-H": header offset. When omitted, put header right before bootblock,
and update a top-aligned virtual address reference in end of ROM.
Example: (can be found in ARM MAkefile):
cbfstool coreboot.rom create -m armv7 -s 4096K -B bootblock.bin \
-a 64 -b 0x0000 -H 0x2040 -o 0x5000
Verified to boot on ARM (Snow) and X86 (QEMU).
Change-Id: Ida2a9e32f9a459787b577db5e6581550d9d7017b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2214
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To support platforms without top-aligned address mapping like ARM, "locate"
command now outputs platform independent ROM offset by default. To retrieve x86
style top-aligned virtual address, add "-T".
To test:
cbfstool coreboot.rom locate -f stage -n stage -a 0x100000 -T
# Example output: 0xffffdc10
Change-Id: I474703c4197b36524b75407a91faab1194edc64d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2213
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Old cbfstool may produce CBFS image with calculation error in size of last empty
entry, and then corrupts master header data when you really use every bit in
last entry. This fix will correct free space size when you load ROM images with
cbfs_image_from_file.
Change-Id: I2ada319728ef69ab9296ae446c77d37e05d05fce
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2211
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To delete a component (file) from existing CBFS ROM image.
To test:
cbfstool coreboot.rom remove -n fallback/romstage
# and compare with old cbfstool output result.
Change-Id: If39ef9be0b34d8e3df77afb6c9f944e02f08bc4e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2208
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change the "extract" command to use cbfs_export_entry API. Nothing changed in
its usage.
To verify, run "cbfstool coreboot.rom extract -f blah -n blah" and check if the
raw type file is correctly extracted.
Change-Id: I1ed280d47a2224a9d1213709f6b459b403ce5055
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2207
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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 syntax of cbfstool has been changed for a while (using getopt). Updated
EXAMPLE file to show the right way to test cbfstool.
Change-Id: I5cb41b76712d8c2403fffc9fdad83c61fb2af98c
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2215
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
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>
Calling basename(3) may modify content. We should allocate another buffer to
prevent corrupting input buffer (full file path names).
Change-Id: Ib4827f887542596feef16e7829b00444220b9922
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2203
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Currently "cbfstool locate" outputs a hex number without "0x" prefix.
This makes extra step (prefix 0x, and then generate another temp file) in build
process, and may be a problem when we want to allow changing its output format
(ex, using decimal). Adding the "0x" in cbfstool itself should be better.
Change-Id: I639bb8f192a756883c9c4b2d11af6bc166c7811d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2201
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
cbfs-mk*.c does not work with real files / command line so header files with
file I/O and getopt can be removed.
Change-Id: I9d93152982fd4abdc98017c983dd240b81c965f5
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2200
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
cbfstool.c uses lots of global variables for command line options and all named
as "rom*". This may be confusing when other global variables also start with
rom, ex: int size = rom_size + romsize;
(rom_size is from command line and romsize is the size of last loaded ROM image).
If we pack all rom_* into a struct it may be more clear, ex:
do_something(param.cbfs_name, param.size, &romsize);
Change-Id: I5a298f4d67e712f90e998bcb70f2a68b8c0db6ac
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2195
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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)
This replaces hard-coded bootblock offsets using the new scheme.
The assembler will place the initial branch instruction after BL1,
skip 2 aligned chunks, and place the remaining bootblock code after.
It will also leave an anchor string, currently 0xdeadbeef which
cbfstool will find. Once found, cbfstool will place the master CBFS
header at the next aligned offset.
Here is how it looks:
0x0000 |--------------|
| BL1 |
0x2000 |--------------|
| branch |
0x2000 + align |--------------|
| CBFS header |
0x2000 + align * 2 |--------------|
| bootblock |
|--------------|
TODO: The option for alignment passed into cbfstool has always been
64. Can we set it to 16 instead?
Change-Id: Icbe817cbd8a37f11990aaf060aab77d2dc113cb1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2148
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This tidies up the ARMV7 case when creating cbfs:
- Calculate the offset using the size of the master header and offsets
rather than using a magic constant.
- Re-order some assignments so things happen in a logical order.
Change-Id: Id9cdbc3389c8bb504fa99436c9771936cc4c1c23
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2125
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
From index(3):
CONFORMING TO 4.3BSD; marked as LEGACY in POSIX.1-2001. POSIX.1-2008
removes the specifications of index() and rindex(), recommending
strchr(3) and strrchr(3) instead.
Change-Id: I3899b9ca9196dbbf2d147a38dacd7e742a3873fe
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/2112
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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)
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>
The "offs" provided on the command-line was not taken into account
when creating an image for armv7...
Change-Id: I1781bd636f60c00581f3bd1d54506f0f50bb8ad0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2092
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Otherwise cbfstool will segfault if you try to add an x86
payload to an ARM image.
Change-Id: Ie468005ce9325a4f17c4f206c59f48e39d9338df
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2028
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The output of cbfstool is a little inconsistent in some places.
This patch fixes it.
Change-Id: Ieb643cb769ebfa2a307bd286ae2c46f75ac5e1c1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1955
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
This removes almost all C++ code (except the wrapper)
Change-Id: I0f84070e3b6dc57c98d49a53150a140479b3221f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1799
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Example:
cbfstool image-link.bin add-flat-binary u-boot.bin fallback/payload \
0x100000 0x100020
will add u-boot.bin as fallback/payload with a load address of 0x100000
and an entry-point of 0x10002.
Change-Id: I6cd04a65eee9f66162f822e168b0e96dbf75a2a7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1792
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
cbfstool was not looking at any dependencies when building
by running make in util/cbfstool. By fixing this it's not
required to make clean every time you edit a file in there.
Change-Id: I544fd54d4b9dd3b277996c21ade56dc086b84800
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1707
Reviewed-by: Marc Jones <marcj303@gmail.com>
Tested-by: build bot (Jenkins)
The default gcc on mingw will process the __attribute__ ((packed)) in
a different way other than non-win system.
Change-Id: Iac9f4476c922472d0b447f1c3ef60e8e13bd902f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1603
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use the right data types to fix compiler warnings.
Change-Id: Id23739421ba9e4a35599355fac9a17300ae4bda9
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/1236
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
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)
Accessing the memory of a char array through a uint32_t pointer breaks
strict-aliasing rules as it dereferences memory with lower alignment
requirements than the type of the pointer requires. It's no problem on
x86 as the architecture is able to handle unaligned memory access but
other architectures are not.
Fix this by doing the test the other way around -- accessing the first
byte of a uint32_t variable though a uint8_t pointer.
Change-Id: Id340b406597014232741c98a4fd0b7c159f164c2
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/1234
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The ChromeOS build system provides a set of CXXFLAGS, however those do
not contain -DCOMPACT. This breaks the compilation of cbfstool in
coreboot-utils.
This fix overrides CXXFLAGS so that coreboot-utils compiles again.
Change-Id: If9495bdd815fe2cdaeba5386afa953558742467b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
While at it, also make the array static - no need to export this symbol.
Change-Id: I7fdcda2b80150b6f32b5bc3e0957998a4fd43fce
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/892
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
This command removes the first file it finds with the given name by changing
its type to CBFS_COMPONENT_NULL and setting the first character of its name to
a null terminator. If the "files" immediately before or after the target file
are already marked as empty, they're all merged together into one large file.
Change-Id: Idc6b2a4c355c3f039c2ccae81866e3ed6035539b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/814
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In bios_log, find that the first segment of the payload is shown
as code rather than data.
Sample:
Got a payload
Loading segment from rom address 0xfff29378
code (compression=1)
...
Change-Id: I82eaad23f08c02f4ed75744affa8835255cf5c17
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/767
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
When the romstage.bin becomes bigger than the size of XIP, the
cbfstool can not allocate the romstage in the CBFS. But it doesn't
report an error. It will take quite a while to find out the root
cause.
Change-Id: I5be2a46a8b57934f14c5a0d4596f3bec4251e0aa
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/650
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
If a file can't be added by cbfstool, print the type and name of the file
in the error message.
Change-Id: I369d6f5be09ec53ee5beea2cfea65a80407f0ba3
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/271
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@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
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
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
the build tree.
Allow separate build tree for utils
Use separate build tree for utils in abuild
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@5453 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
SECONDEXPANSION feature of GNU make (and we rely on GNU make for lots of
things already)
File paths are relative to the root directory, which simplifies
debugging (make V=1 gives shorter command lines) and helps ccache
finding matches for checkouts in different directories (even though it
should normalize paths itself)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5304 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
This makes the output look a lot nicer, e.g.
/home/uwe/foo/bar/baz/whatever/build/coreboot.rom: 256 kB, bootblocksize 65536, romsize 262144, offset 0x0
now becomes:
coreboot.rom: 256 kB, bootblocksize 65536, romsize 262144, offset 0x0
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5112 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- if crt0s is empty (eg. because crt0-y is still used),
break the build, and say where that behaviour changed
- if a stage is unusable for cbfstool because it's placed
outside the ROM space (linked to 0 is somewhat notorious),
warn about it, give some hints and exit instead of crashing.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stefan.reinauer@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5077 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Introduce the tiny bootblock infrastructure and use it on QEmu.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4989 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
to be stated in kilobytes or megabytes. Usage is
cbfstool coreboot.rom create 1048576 coreboot.bootblock
cbfstool coreboot.rom create 1024k coreboot.bootblock
cbfstool coreboot.rom create 1m coreboot.bootblock
to get an 1048576 bytes = 1024kb = 1mb image.
Kconfig also uses this instead of calculating bytes from kilobytes itself.
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@4987 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This should improve programming speed a bit.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4975 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
- don't pretend to create a bootblock as large
as the ROM in Kconfig (it's 64k at most)
- don't pretend to accept a bootblocksize value
in cbfstool create (it ignored it)
- patch up the build systems to keep it working
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4934 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
Also, remove one missing hardcoded "build" dir in the distclean target,
and clean up files generated by sconfig in 'make clean'.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4880 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
directory with "build/" for consistency (trivial, sort of).
Also, drop printing of "config.g" input file, we usually only print
generated/output files in the build output.
Finally, rename non-existing COMPRESSFLAG variable to
CBFS_PAYLOAD_COMPRESS_FLAG in a printf line. The build output now says
PAYLOAD payload.elf l
for payloads (the "l" specifies LZMA compression).
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4875 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
and report the correct error code, and a hopefully helpful
error message.
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@4692 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
bad: It brings a certain amount of code duplication (some of which can be
cleaned up again, or get rid of by proper refactoring).
On the other hand now there's a very simple code flow for each command, rather
than for each operation. ie.
adding a file to a cbfs means:
- open the cbfs
- add the file
- close the cbfs
rather than
open the cbfs:
- do this for add, remove, but not for create
create a new lar
- if we don't have an open one yet
add a file:
- if we didn't bail out before
close the file:
- if we didn't bail out before
The short term benefit is that this fixes a problem where cbfstool was trying
to add a file if you gave a non-existing command because it bailed out on
known, not on unknown commands.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4654 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
section header which could lead to corrupted malloc arena.
Also, make cbfstool always build with debugging on. Performance
is not an issue here. Don't strip it either.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4641 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
from any symbol information.
Variant of Ron's patch.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4637 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfstool. (trivial)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4634 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4631 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
$(Q) in front of every silent line.
make V=1 or make Q="" still make make noisy again.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4581 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- Whitespace fixes, remove trailing whitespace, use TABs for identation
(except in Kconfig "help" lines, which start with one TAB and two spaces
as per Linux kernel style)
- Kconfig: Standardize on 'bool' (not 'boolean').
- s/lar/cbfs/ in one Kconfig help string.
- Reword various Kconfig menu entries for a more usable and consistent menu.
- Fix incorrect comment of NO_RUN in devices/Kconfig.
- superio/serverengines/Kconfig: Incorrect config name.
- superio/Makefile.inc: s/serverengine/serverengines/.
- superio/intel/Kconfig: s/SUPERIO_FINTEK_I3100/SUPERIO_INTEL_I3100/.
- mainboard/via/vt8454c/Kconfig: Fix copy-paste error in help string.
- mainboard/via/epia-n/Kconfig: Fix "bool" menu text.
- console/Kconfig: Don't mention defaults in the menu string, kconfig
already displays them anyway.
- Kill "Drivers" menu for now, it only confuses users as long as it's emtpy.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Acked-by: Uwe Hermann <uwe@hermann-uwe.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4567 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CBFS uses sprintf, which requires vtxprintf, which requires (in the
current design) a nested function. That works on x86, but on PPC this
requires a trampoline. In the ROM stage, this is not available, so
remove the single use of sprintf and replace it with a direct string
handler - it's only used to fill in fixed-length hex values.
20090819-3-more-noreturns-in-romcc:
Mark two more functions in romcc as noreturn. Helps clang's scan-build a
bit
20090819-4-cbfsify-ppc:
Make PPC use CBFS. Support big endian ELF in cbfs-mkstage. Untested and
not complete yet.
20090819-5-fix-ppc-build:
The CBFS build system requires ROM_IMAGE_SIZE to have a somewhat
plausible value.
With fixes to tohex* functions as discussed on the list, and correct
function names.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4558 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Thomas Jourdan <thomas.jourdan@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4547 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
probably others). Only select them for AMD
- Make the bootblock smaller (only one copy of it), and don't pad the
bootblock using dd(1), but top-align inside cbfstool, to reduce
dependencies on unix tools.
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@4542 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Works on Kontron, qemu, and serengeti.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
tested on abuild only.
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4534 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- update, add, and improve comments
- whitespace here and there
- remove unused or write-only variables
- improve debug output
- only build payload.{nrv2b,lzma} for non-cbfs
- improved error checking in cbfstool
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4466 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Kconfig)
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@4384 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It's basically done with the following script and some manual fixup:
VARS=`grep ^define src/config/Options.lb | cut -f2 -d\ | grep -v ^CONFIG | grep -v ^COREBOOT |grep -v ^CC`
for VAR in $VARS; do
find . -name .svn -prune -o -type f -exec perl -pi -e "s/(^|[^0-9a-zA-Z_]+)$VAR($|[^0-9a-zA-Z_]+)/\1CONFIG_$VAR\2/g" {} \;
done
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@4381 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
didn't look into it enough to know why fssize is 32 bytes larger than the
offset. There may be another bug here. Maybe something with the CBFS header
not being included or excluded from the calculation?
Anyway, this patch fixes it for all cases size > 32.
I also changed the error message so that it doesn't look like the ROM is full
just because it can't find room for a file.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4370 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
[base address] parameter is supplied on the command line... This patch fixes
random segfaults when using 'cbfstool add'.
Signed-off-by: Ward Vandewege <ward@gnu.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4363 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfs files at fixed addresses.
I call this transitional as the approach I am taking is to add
capability to cbfstool but not change code in a way that will break
existing usages. Later, once we're sure nothing has broken, we can start to
smooth the edges.
Right now, fixed address file are only supported via the add command.
There is one additional command syntax, so, example:
cbfstool add rom romstrap optionrom 0xffffd000
Will add the file to that fix location for a romstrap.
The assumption is that the ROM is based at the end of a 32-bit address
space. As you can see from the code, that assumption can easily be
over-ridden, if we ever need to, with a command option.
Here is one example output result.
rminnich@xcpu2:~/src/bios/coreboot-v2/util/cbfstool$ ./cbfstool x.cbf print
x.cbf: 1024 kB, bootblocksize 32768, romsize 1048576, offset 0x0
Alignment: 16 bytes
Name Offset Type Size
h 0x0 optionrom 251
0x130 free 917120
h3 0xdffe0 optionrom 251
0xe0110 free 97960
The way this is implemented is pretty simple. I introduce a new
operator, split, that splits an unallocated area into two unallocated
areas. Then, allocation merely becomes a matter of 0, 1, or 2 splits:
0 split -- the free area is the exact fit
1 splits -- need to split some off the front or back
2 splits -- need to split off BOTH the front and back
I think you'll be able to see what I've done. I call this transitional
because, in the end state, we only need one allocate function; for now
I've left two in, to make sure I don't break compatibilty.
Why I like this better than ldscript approach: I like having the
ROMSTRAP located by cbfs, not linker scripts. For one thing, it makes
romstrap visible as a first class object. I think I would have latched
onto a problem I was having much more quickly had I remembered the
ROMSTRAP. It gets lost in the linker scripts.
At this point, we should be able to start removing special ROMSTRAP location
code from linker scripts.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4351 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
with an error code now.
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@4329 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
* remove some dead code
* fix indentation
* comment in some destructors and fix some other warnings
* use HOSTCC instead of CC (not all the way cosmetic, but very simple)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4299 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It makes the write part of flashrom dramatically faster with small
payloads like filo; and it also eliminates unnecessary wear on flash
by not writing zeros (it's unlikely this really matters; let me know
next time you flash a BIOS flash 100,000 times!).
More importantly, it allows for future partial flash upgrades with cbfs.
Note that uninitialized_flash_value is a global that can, if we ever need it,
be set by an argument in main. Assuming we ever see a flash where the
"erased" value is 0, not 0xff.
At the same time, "erased" value has been "1" on every EEPROM or
FLASH I've used for some time now.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4290 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
command.
Make use of it in config.g (Myles)
Signed-off-by: Ward Vandewege <ward@gnu.org>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4282 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
It is nearly trivial.
Signed-off-by: Myles Watson<mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4279 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Tested to booting linux with qemu.
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Acked-by: Myles Watson<mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4276 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Change sizes from unsigned int to int.
Clean up some usage and parameter checking.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4262 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
I didn't try to remove "defined but not used" warnings because there are too
many ifdefs to be sure I wouldn't break something.
For shadowed variable declarations I renamed the inner-most variable.
The one in src/pc80/keyboard.c might need help. I didn't change the
functionality but it looks like a bug.
I boot tested it on s2892 and abuild tested it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4240 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
anything that was there. For ck804 or mcp55-based machines that was the
romstrap.
The fix is simple:
1. Put the master cbfs record above the bootblock instead of on it.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4209 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
caused a seg fault, sometimes executed somewhere else. Also add an error if
the algorithm is unknown.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ward Vandewege <ward@gnu.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4198 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
cbfstool extract [FILE] [NAME]
It also factors out the csize calculation in rom_add, and fixes rom_delete so
that it can handle deleting the last entry.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4144 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
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@4114 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
I noticed this before sed, but forgot to change it back after sed.
Signed-off-by: Peter Stuge <peter@stuge.se>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4111 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
Hung-Te Lin