This fixes at least one warning on my machine where "llx" is replaced by PRIx64.
Change-Id: Iee3e5027d327d4d5f8e6d8b2d53d051f74bfc354
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3024
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Cppcheck [1], a static code analysis tool, warns about the
following.
$ cppcheck --version
Cppcheck 1.59
$ cppcheck --enable=all .
[…]
Checking cpu.c...
[cpu.c:951]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[cpu.c:962]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[…]
And indeed, `core` is an unsigned integer and `man 3 printf` tells
the following about conversion specifiers.
d, i The int argument is converted to signed decimal notation. […]
o, u, x, X
The unsigned int argument is converted to unsigned octal (o), unsigned decimal (u), or unsigned hexadecimal (x and X)
notation.
So use `u` and Cppcheck does not complain anymore.
[1] http://cppcheck.sourceforge.net/
Change-Id: If8dd8d0efe75fcb4af2502ae5100e3f2062649e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3026
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When building inteltool under x86-32, the following warnings are
shown.
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
Nico Huber commented the following [1].
I don't see those warnings because I build for x86-64. I guess
they could be fixed by casting to `ptrdiff_t` (from stddef.h)
instead of `uint64_t`.
And indeed, using `ptrdiff_t` fixes the warning. But as Stefan
Reinauer commented in [2], `intptr_t` is more appropriate as this
is just a pointer and no pointer difference.
So `intptr_t` is taken, which fixes these issues warned about too.
These warnings were introduced in commit »inteltool: Add support for
dumping AMB registers« (4b7b320f) [3].
[1] http://review.coreboot.org/#/c/2996/1//COMMIT_MSG
[2] http://review.coreboot.org/#/c/3002/1/util/inteltool/amb.c
[3] http://review.coreboot.org/525
Change-Id: I2ea1a31dc1e3db129e767d6a9e0433fd75a77d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3002
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When buidling inteltool with GCC, the following warning is printed.
$ make
[…]
gcc -O2 -g -Wall -W -c -o memory.o memory.c
memory.c: In function ‘print_mchbar’:
memory.c:287:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
[…]
This was introduced in commit »inteltool: Add support for H65 Express
chipset« (c7fc4422) [1].
Address this warning, by using `%llx` instead of `%lx`.
[1] http://review.coreboot.org/1258
Change-Id: I4f714edce7e8b405e1a7a417d02fa498322c88a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2994
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The help text says --machine, but the code
actually checked for --arch. Fix it!
Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Allow to override the variables `CC`, `INSTALL`, `PREFIX`,
`CFLAGS` and `LDFLAGS`. Though append `-lpci -lz` to `LDFLAGS`.
This way for example a different compiler can easily be used.
CC=clang make
As a side note, Clang in contrast to GCC does *not* issue the
following warnings.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
These are only shown under 32-bit and not 64-bit
$ uname -m
i686
and are going to be fixed in a separate patch.
Change-Id: Id75dea081ecb35390f283520a7e5dce520f4c98d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2996
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the power management register definitions for Intel's Cougar
Point and Panther Point platform controller hubs (PCH). The definitions
are actually a subset of the older ICH10R registers: I've added just
those that are mentioned in the public specifications in [1] and [2].
I've tested dumping with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: Ia6945fe96cd96b568ed5191e91dbba5556e1ee95
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the PCI IDs of Intel's Cougar Point and Panther Point platform
controller hubs (PCH) to the dumping of the root complex configuration
under the root complex base address (RCBA). Those PCHs are handled exactly
as the older ICHs which can be seen in [1] and [2]. I've tested dumping
with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I2296caae57e614171300362d41715deecec77762
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2986
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This way for example a different compiler can easily be used.
CC=clang make
Change-Id: I50b83554fd4826d00d87e60a30eb1f6a88834397
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2935
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds the GPIO register definitions for Intel's Cougar Point and
Panther Point platform controller hubs (PCH). All information is taken
from the public specifications in [1] and [2]. I've tested it with an
H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I31711e24f852e68b3c113e3bd9243dc7e89ac197
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2961
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds correspondings #defines for the PCI IDs of the LPC device on
Intel's Cougar Point and Panther Point platform controller hubs. Those
will be used more in later commits.
I've checked all those IDs against the specification updates [1] and [2].
[1] Intel 6 Series Chipset and Intel C200 Series Chipset Specification
Update
Document-Number: 324646-019
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH)
Family - Datasheet Specification Update
Document-Number: 326777-010
Change-Id: Ibef5a30d283c568c345eb8d8149723e7a3049272
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2960
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If you have a recent version of texinfo installed, building the reference
toolchain fails with the following error:
(in util/crossgcc/build-gcc/crossgcc-build.log)
[...]/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item
Looks like a warning-became-an-error problem in texinfo, to me. Fix that by
making every erroneous @itemx an @item.
Change-Id: I685ae1ecfee889b7c857b148cfab7411a10e7ecd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Add support for filling in the Firmware Interface Table.
For now it only supports adding microcode entries.
It takes 2 options:
1. Name of file in cbfs where the mircocode is located
2. The number of empty entries in the table.
Verified with go firmware tools. Also commented out updating
microcode in the bootblock. When romstage runs, the CPUs indicate
their microcode is already loaded.
Change-Id: Iaccaa9c226ee24868a5f4c0ba79729015d15bbef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2712
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
- The read-only structures are const now
- cosmetic fixes
- put { on a new line for functions
- move code after structures
Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2922
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
In commit e820e5cb3a titled
"Make xcompile support multiple architectures" the LINKER_SUFFIX
variable was introduced to bypass gold if the bfd linker was
available. However, the LINKER_SUFFIX wasn't honored when
the compiler evironment variables were set. Fix the original
intention.
Change-Id: I608f1e0cc3d0bea3ba1e51b167d88c66d266bceb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2879
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When calculating initial CBFS empty entry space, the size of header itself must
be not included (with the reserved space for entry name). This is a regression
of the old cbfstool size bug.
Before this fix, in build process we see:
OBJCOPY cbfs/fallback/romstage_null.bin
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
And checking the output binary:
cbfstool build/coreboot.pre1 print -v -v
DEBUG: read_cbfs_image: build/coreboot.pre1 (262144 bytes)
DEBUG: x86sig: 0xfffffd30, offset: 0x3fd30
W: CBFS image was created with old cbfstool with size bug.
Fixing size in last entry...
DEBUG: Last entry has been changed from 0x3fd40 to 0x3fd00.
coreboot.pre1: 256 kB, bootblksz 688, romsize 262144, offset 0x0 align: 64
Name Offset Type Size
(empty) 0x0 null 261296
DEBUG: cbfs_file=0x0, offset=0x28, content_address=0x28+0x3fcb0
After this fix, no more alerts in build process.
Verified to build successfully on x86/qemu and arm/snow configurations.
Change-Id: I35c96f4c10a41bae671148a0e08988fa3bf6b7d3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2731
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cbfstool usage change:
"-a" for "cbfstool locate" can specify base address alignment.
To support putting a blob in aligned location (ex, microcode needs to be aligned
in 0x10), alignment (-a) is implemented into "locate" command.
Verified by manually testing a file (324 bytes) with alignment=0x10:
cbfstool coreboot.rom locate -f test -n test -a 0x10
# output: 0x71fdd0
cbfstool coreboot.rom add -f test -n test -t raw -b 0x71fdd0
cbfstool coreboot.rom print -v -v
# output: test 0x71fd80 raw 324
# output: cbfs_file=0x71fd80, offset=0x50, content_address=0x71fdd0+0x144
Also verified to be compatible with old behavior by building i386/axus/tc320
(with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
cbfstool coreboot.rom locate -f x.bin -n romstage -P 0x40000 -a 0x30
# output: 0x60
Change-Id: I78b549fe6097ce5cb6162b09f064853827069637
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2824
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
cbfstool usage change:
The "-a" parameter for "cbfstool locate" is switched to "-P/--page-size".
The "locate" command was used to find a place to store ELF stage image in one
memory page. Its argument "-a (alignment)" was actually specifying the page size
instead of doing memory address alignment. This can be confusing when people are
trying to put a blob in aligned location (ex, microcode needs to be aligned in
0x10), and see this:
cbfstool coreboot.rom locate -f test.bin -n test -a 0x40000
# output: 0x44, which does not look like aligned to 0x40000.
To prevent confusion, it's now switched to "-P/--page-size".
Verified by building i386/axus/tc320 (with page limitation 0x40000):
cbfstool coreboot.rom locate -f romstage_null.bin -n romstage -P 0x40000
# output: 0x44
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Change-Id: I0893adde51ebf46da1c34913f9c35507ed8ff731
Reviewed-on: http://review.coreboot.org/2730
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
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 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)
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>
Stefan Tauner