| Age | Commit message (Collapse) | Author |
|---|
|
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)
|
|
$ superiotool -d
superiotool r4.0-3712-gd549279
Found ITE IT8728F (id=0x8728, rev=0x1) at 0x2e
Register dump:
idx 02 07 20 21 22 23 24 2b 2e 2f
val 00 0a 87 28 01 00 00 40 00 00
def NA NA 87 28 01 00 00 MM 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 00 03 f0 06 02 00 00
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0 f1
val 01 03 f8 04 00 50
def 00 03 f8 04 00 50
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1
val 00 02 f8 03 00 50
def 00 02 f8 03 00 50
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 70 74 f0
val 01 03 78 00 00 07 04 08
def 00 03 78 07 78 07 03 03
LDN 0x04 (Environment controller)
idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f9 fa fb
val 01 0a 30 0a 20 09 00 80 00 00 20 00 f0 48 00 00
def 00 02 90 02 30 09 00 00 00 00 00 MM MM MM MM MM
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 71 f0
val 01 00 60 00 64 01 02 08
def 01 00 60 00 64 01 02 48
LDN 0x06 (Mouse)
idx 30 70 71 f0
val 01 0c 02 00
def 00 0c 02 00
LDN 0x07 (GPIO)
idx 25 26 27 28 29 2a 2c 2d 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc cd ce cf e0 e1 e2 e3 e4 e9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb
val 00 f3 10 00 00 00 80 00 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 00 00 00 21 10 42 00 00 00 00 1c 00 00 00 00 00
def 00 f3 00 00 00 00 03 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 MM 00 00 00 00 00 00 00 00 00 00 00 00
LDN 0x0a (Consumer IR)
idx 30 60 61 70 f0
val 00 03 10 0b 06
def 00 03 10 0b 06
Change-Id: Ifb45d28005d78b2a99d8552b59154d11bdf44f6f
Signed-off-by: Андрей Павлов <7134956@gmail.com>
Reviewed-on: http://review.coreboot.org/2775
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
|
|
This is a bit of a hack but it's very handy. It compiles in your static.c
and then shows what coreboot would see when it is run. It uses your static.c
and functions pulled from src/device/device_util.c.
I've already used it to debug problems with the snow device tree.
I'm waiting someone to tell me this is already written :-)
Change-Id: Ia8c8a5d08d8757bec49eaf70473efa701bc56581
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2767
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
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>
|
|
Instead of trying to map the first megabyte, only map what is
required to read the tables.
Change-Id: I9139dbc8fd1dd768bef7ab85c27cd4c18e2931b3
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/2485
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
Instead, ignore them. One is as non-standard as the other
and ignoring is more convenient since we don't need to
guard prototypes with #ifndef __ROMCC_ all the time.
Change-Id: I7be93a2ed0966ba1a86f0294132a204e6c8bf24f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2424
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Marc Jones <marcj303@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 4610247ef1744ccabbcc6bfc441a3583aa49f7b5
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)
|
|
Ensure that no changes with warnings are committed. Although using
`-Werror` is debatable [1][2].
[1] http://blog.flameeyes.eu/2009/02/future-proof-your-code-dont-use-werror
[2] http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Change-Id: I402f2d82dd4087d8a575b0a85305a02ef04bb537
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2441
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The name lapic_cluster is a bit misleading, since the construct is not local
APIC specific by concept. As implementations and hardware change, be more
generic about our naming. This will allow us to support non-x86 systems without
adding new keywords.
Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The name pci_domain was a bit misleading, since the construct is only
PCI specific in a particular (northbridge/cpu) implementation, but not
by concept. As implementations and hardware change, be more generic
about our naming. This will allow us to support non-PCI systems without
adding new keywords.
Change-Id: Ide885a1d5e15d37560c79b936a39252150560e85
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2376
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
On hosts using non-GNU make as default make program (ex, FreeBSD's default is
BSD make and having GNU make as "gmake"), building acpica will fail. We should
use the correct path of make $(MAKE).
Verified to build on FreeBSD 9.0 with gcc 4.7 from ports. Note, the shipped gcc
in FreeBSD 9.0 is 4.2.1 and needs more patches to remove -Wbad-function-case and
-Wempty-body. That should be fixed in a future patch.
Change-Id: Iacbf5a05e84a8a53d9d3e783a10131de603282c9
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2333
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
In case that the new toolchains don't work well, we can trace back
and reproduce the old tools by checking the xgcc folder. It is useful
when my team members need to get my old toolchains on their own host
machines.
Change-Id: I54e4bc6afcfbbf622165af6eae27bbb6efc2e8cc
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2247
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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>
|
|
Change-Id: Ibf221db4ca60d802b460d56f5fcca95ff49fc542
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2273
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
It's just good hygiene.
Change-Id: Ie7d4557c1d0dcf7fc015852c4c9b2eae29c4acfc
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2232
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
|
|
Added bits/bitfields descriptions and decoding values
into intel_core2_later.c file, which describe
MSRs for Intel processors, based on later Core 2
architecture.
Change-Id: If577c8ed944afe34f86944cc03a780fba6b3dbba
Signed-off-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-on: http://review.coreboot.org/1171
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
reference for Atom MSRs are from
Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3C: System Programming Guide, Part 3
Order Number 326019, January 2013, Table 35-4, 35-5
Has been successfully tested on the targeted cpu.
Change-Id: If94279caeab27121c63ec43c258dc962c167ad51
Signed-off-by: Olivier Langlois <olivier@olivierlanglois.net>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2192
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
$ git stripspace < util/runfw/googlesnow.c > /tmp/bla
$ mv /tmp/bla util/runfw/googlesnow.c
Introduced with original commit.
commit b867281a07addd1eb00f964ff4f8727664e13e19
Author: Ronald G. Minnich <rminnich@gmail.com>
Date: Wed Jan 16 11:59:34 2013 -0600
Utility to run the snow bios in user mode
Change-Id: I146c07a918ef99e8ae3c0dd72cf28fae22312e43
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2183
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This program lets you test run a snow coreboot image in user mode
on a properly equipped arm system (usually an ARM chromebook).
This is a real time saver as you don't have to flash each time.
We've found and fixed some nasty bugs with this one.
Anyway, the instructions on how to use this are in the binary.
Change-Id: Ib555ef51fd7e930905a2ee5cbfda1cc6f068278e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2159
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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 ARMv7 toolchain is now also needed for abuild (at least
if you want to be able to compile ARM images)
Change-Id: If1253203a2198f7dea632ba45540222ba3361932
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2147
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
|
|
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>
|
|
The current path doesn't make much sense (unless you're Sven)
and may also incur a very long access penalty if /home happens
to be on a network mounted filesystem.
Change-Id: I8cfceb3cf237757ce9ea8f1953bce5a72691838a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
In order to provide some insight on what code is executed during
coreboot's run time and how well our test scenarios work, this
adds code coverage support to coreboot's ram stage. This should
be easily adaptable for payloads, and maybe even romstage.
See http://gcc.gnu.org/onlinedocs/gcc/Gcov.html for
more information.
To instrument coreboot, select CONFIG_COVERAGE ("Code coverage
support") in Kconfig, and recompile coreboot. coreboot will then
store its code coverage information into CBMEM, if possible.
Then, run "cbmem -CV" as root on the target system running the
instrumented coreboot binary. This will create a whole bunch of
.gcda files that contain coverage information. Tar them up, copy
them to your build system machine, and untar them. Then you can
use your favorite coverage utility (gcov, lcov, ...) to visualize
code coverage.
For a sneak peak of what will expect you, please take a look
at http://www.coreboot.org/~stepan/coreboot-coverage/
Change-Id: Ib287d8309878a1f5c4be770c38b1bc0bb3aa6ec7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2052
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martin@se-eng.com>
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>
|
|
... without the need for a coreboot table entry for each of them.
Change-Id: I2917710fb9d00c4533d81331a362bf0c40a30353
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2117
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
... and indent it to make output more comprehensible.
Change-Id: If321f3233b31be14b2723175b781e5dd60dd72b6
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2116
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
