There potentially could be multiple CBFS instances present in the
firmware image. cbfstool should be able to operate on any of them, not
just the first one present.
To accomplish that, allow all CBFS commands to accept the -H parameter
(which specifies the exact CBFS header location in the image).
If this parameter is specified, the image is not searched for the CBFS
header, only the specified location is checked for validity, If the
location is valid, it is considered to be the CBFS header, if not -
the tool exits with an error status.
Note, that default behavior of the tool does not change.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=run the following experiments:
- examined an image with three CBFS instances, was able to print all
of them.
- built a rambi coreboot image and tried the following (cbfstool output abbreviated):
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ \od -tx4 -Ax /build/rambi/firmware/coreboot.rom | tail -2
7ffff0 fff67de9 000000ff fff6dfe9 fffff650
800000
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff650
coreboot.rom: 8192 kB, bootblocksize 2448, romsize 8388608, offset 0x700000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x700000 cmos_layout 1164
...
(empty) 0x7ec600 null 77848
$ ./util/cbfstool/cbfstool /build/rambi/firmware/coreboot.rom print -H 0x7ff654
E: /build/rambi/firmware/coreboot.rom does not have CBFS master header.
E: Could not load ROM image '/build/rambi/firmware/coreboot.rom'.
$
Change-Id: I64cbdc79096f3c7a113762b641305542af7bbd60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 86b88222df6eed25bb176d653305e2e57e18b73a
Original-Change-Id: I486092e222c96c65868ae7d41a9e8976ffcc93c4
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237485
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/9741
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This check verifies that all mainboard vendors
and boards have a Kconfig.name entry.
Change-Id: I3ed3bfa0d3f78e55a8d54918f5f3f29f51068e48
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9707
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With the Storm image layout reworked, the very first blob read out of
NOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation
of three binaries: one to run on RPM, another one to run on AP, and
the third one - the actual coreboot bootblock.
This layout allows to greatly reduce the size and complexity of the
two first blobs, as they do not need to include the SPI driver.
The first binary in the input file list starts with the combined
header, describing the rest of the blob. This utility copies the first
input file into output, updating the combined header with the total
size of the concatenated binaries.
The second and third binaries in the combined image are required to be
aligned at 256 byte offsets in the file as counted from the end of
the combined header. The new utility allows to concatenate two or
three files, always expecting the first file to be prepended by the
combined header.
For further reference below is the utility's help message:
mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock]
Concatenates up to three mbn files: two SBLs and a coreboot bootblock
-h This message
-v verbose
-o Output file name, (default: sbl-ro.mbn)
BRANCH=none
BUG=chrome-os-partner:34161
TEST=run the new utility and compare the result with the output of
the vendor provided tool. The output files are exactly the same.
Change-Id: I1d3b3634ecc3f46ea88adb9b6c4fbfc017cc06ac
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 94008340bc5eaf19d286b3feaa4091e5c5e285aa
Original-Change-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232047
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9572
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When only one argument is passed on the command line, consider this
argument the name of the BIMG formatted file, and verify its
integrity.
Update the help/usage text to match new behavior.
BRANCH=none
BUG=none
TEST=when the corrupted coreboot BIMG image is passed as the only
argument, this utility reports the problem. With the build fixed,
the check passes without errors (the second invocation below).
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
Data header CRC mismatch at 0
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
$
Change-Id: I9f0672caa38e3d27917471fc5137ede4ca466e9a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3e631c311dbf2fb04714e437f95c41629155527f
Original-Change-Id: Ie56f87f99838891d8e341d7989c614efbcabe0cd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227522
Original-Reviewed-by: Zdenko Pulitika <zdenko.pulitika@imgtec.com>
Original-Tested-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/9452
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Switched to CRC 16 as it's 40% faster than CRC x25.
Both CRC 16 and CRC x25 are supported and either can be selected through
define directives.
BUG=chrome-os-partner:31438
TEST=built urara bootblock and verified content of bootblock.bin, observed
expected content; ran it on Pistachio FPGA and observed that its
content is read properly by bootrom.
BRANCH=none
Change-Id: I36dec6ec2d6616343f97cc8b6486c0a3e4ea49ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6d9318097ca9270bc245e7de4aff5f78dfbc1606
Original-Change-Id: If1a78350e0b48d91bfe64ead45f852f44ba3cf9a
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/226840
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9415
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This is a script we have been using to rewrite commit messages when
upstreaming coreboot patches from the Chromium OS tree into coreboot
upstream.
Change-Id: I5442279c099dafe55cc97ccf09ee2bc2df4eca5f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9299
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We have another stage which we need to test for. Not a problem
right now, because it always matches either bootblock or romstage,
but future proof the test.
Change-Id: Id0a16d9bc1270516f2c00f9f8fd049420c9ba354
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9380
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This moves the ram dump behind an argument, but
it's still called by default when no other arguments given.
To hold backward compatibility -i also prints out RAM.
Change-Id: I82648e8cf1eac455e9937bd3669a0e91a3ee87cf
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/8381
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Peter Stuge <peter@stuge.se>
Kconfig's include directive "source" does not support
wildcards (e.g. source src/mainboard/*/Kconfig) which
makes automatic inclusion of all boards a tedious task
and prevents us from implementing "drop in" boards.
In our Makefile.inc files we already include mainboard
directories per wildcard, so let's add the infrastructure
to do the same with Kconfig.
Change-Id: I1988ff6ce3e167e86bb5cb65fc04a13748599dad
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9294
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
make failed while executing "OPTION option_table.h" by printing
nvramtool's usage message when crosscompiling coreboot on the BBB.
The reason is the usage of char for the return value of getopt instead
of int and comparing it to -1 later... although char might be unsigned
as it is usually on ARM.
Change-Id: Ib20fd5ef174d484bbb35f80150b8f898d95d0fe4
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/9307
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's no such thing as "list_struct".
Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Change-Id: Ida39beb7b81801b277b623ff5a40291d643706ee
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9314
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The calloc() and xcalloc() functions takes @nmemb first and then @size. Fix all w/
pattern "calloc\s*(\s*sizeof".
Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1417866043-1877-1-git-send-email-arjun024@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Change-Id: I8b51cc59b3f3631b93b7e215fec5bf140cc2cbf9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9313
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Warning:
In file included from scripts/kconfig/zconf.tab.c:2537:0:
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:590:18: warning: ‘jump’ may be used uninitialized in this function [-Wmaybe-uninitialized]
jump->offset = strlen(r->s);
Simplifies the test logic because (head && local) means (jump != 0)
and makes GCC happy when checking if the jump pointer was initialized.
Signed-off-by: Peter Kümmel <syntheticpp@gmx.net>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I43de391c9573a28c66d17e7dc535033be39060de
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9312
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: I033338a4a3f3a20944feace46b679c85ee32d14e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9310
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Although on some systems va_end is a no-op, it is good practice
to use va_end, especially since the manual states:
"Each invocation of va_start() must be matched by a corresponding
invocation of va_end() in the same function."
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: Ia08a57c37a6294e002cb6ce4c0a010c0d2edf973
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9309
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Imported from upstream linux kernel kconfig.
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ieed948c6b9c5fc40c1f3d652df11fa70ec6e93a0
Original-Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Original-Signed-off-by: Michal Marek <mmarek@suse.cz>
Reviewed-on: http://review.coreboot.org/9308
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This makes "make menuconfig" also work on systems where ncurses is not
installed in a standard location (such as on NixOS).
This patch changes ccflags() so that it tries pkg-config first, and only
if pkg-config fails does it go back to the fallback/manual checks. This
is the same algorithm that ldflags() already uses.
Signed-off-by: Bjørn Forsman <bjorn.forsman@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Change-Id: Ie2372ca35546c1fc2d6cf603614683312ee4ea4c
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9315
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds a few new file types to cbfstool. Currently these
files are being added using bare hex values in the coreboot
makefiles. This patch is just to make the values official and
to help get rid of some confusion in the values used within the
makefiles.
All of these new types are roughly equivalent to raw.
Change-Id: I37c4180a247136cd98080f6f7609d3cf905a62f5
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8977
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Copy $0 contains the path, and we cd into that early.
Change-Id: If4124d16dea97b5eee4996bdfa3eae3d5d94c5d1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9145
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Confirmed to work on FreeBSD using sh from base and bash from ports.
Verified to not break M.O. on Linux.
Change-Id: I3bce724c889c7fb760b30b25e9fc0b74620e2c53
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/9056
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system expects mipsel, and it's the more
precise name, too.
Change-Id: I9e1135385b3f1374b3179ecf5e11a1d60bc17ef7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/9144
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Danube has become Pistachio, let's rename all instances where this SOC
is mentioned.
BUG=none
TEST=board urara still builds
Change-Id: Iea91419121eb6ab5665c2f9f95e82f461905268e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 58696cc7c77a70dca2bfd512d695d143e1097a78
Original-Change-Id: Ie5ede401c4f69ed5d832a9eabac008eeac6db62d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220401
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: http://review.coreboot.org/9048
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This script produces a "minimal" configuration from a full coreboot
configuration, e.g. a configuration file that only contains the differences
between the default configuration of a board and the input configuration
file.
Usage: util/kconfig/miniconfig config.big config.mini
This will read config.big and produce config.mini. If you omit config.mini,
config.big will be changed in place.
Minimal configurations are easier to read and more robust when reusing
them among different versions of coreboot as they reflect exactly the
changes made to the default configuration instead of a full snapshot
of all configuration options.
Change-Id: Ifbee49e0192c2c557b18bcc1a92fe2a5d5164a3a
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8974
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of repeating the ok/failed test all the time,
move it into a function.
Change-Id: I7496dfb5d3d2385316c577e1cf0901950b0e7083
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8987
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The first problem for crossgcc users that encounter build errors is
figuring out what is wrong with the build. Point out where the logs
reside.
Change-Id: I0300ecf6356c1a4ce18ae1e37fe0a56f46210d13
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8982
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ie002c69ab23cfc961b77771c4f2c20e5ae6bea60
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8633
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
* Fix up tree detection to work in a coreboot tree
* Switch C99_COMMENT from ERR to CHK
Change-Id: Ie8d6d1407853b77a4b3e9763f23481bd9402bc61
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8418
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
MIPS targets should be compiled with no position independent code
allowed, as the generated image often does not support short range
components reference.
BUG=chrome-os-partner:31438
TEST=with the rest of the patches included MIPS board urara builds
successfully
Change-Id: I8ac2a2f6979d3b468159c9e29d07e022f48ab18a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e932b203db3e7cb510a7bf862d4538d55b6c7271
Original-Change-Id: I637dd44eb565447c18b2c3cdb022d0933c52fd20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/215677
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8822
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The upcoming MIPS toolchain inside chroot generates elf images of
elf32-tradlittlemips format, whereas readily available tools outside
of chroot generate images of elf32-littlemips format. Both of these
formats are perfectly fine, but xcompile accepts only one format per
CPU architecture.
This patch allows to specify multiple formats per architecture, any
matching format will suffice.
BUG=chrome-os-partner:31438
TEST=emerged arm, x86 and mips targets inside chroot
Change-Id: I2c6b8e46b9299059b8e099b93c8c3dcf0a569899
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7f2f1d51643f33b72ac5e4091669f38662e5b9ce
Original-Change-Id: I22405e71ac72b985fad51e2f5d7cc014107b8a9e
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/214599
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8823
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a new utility named bimgtool, a simple tool which generates boot
images in the BIMG format. This is the format the Danube boot ROM
expects the user supplied code to be wrapped in, it is described by
struct bimg_header in the code.
This utility will be used to wrap the coreboot bootblock when building
Danube targets.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I08ddb1b70d0b1feb1ffb3d62c4e5e6f07f4acdb7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7fe6a9f383b79120f9ae231453d4b3a0f85b4fa7
Original-Change-Id: I63b9f5e09cd1f12765317b38e2a0dd033cdd6d39
Original-Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/207975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8768
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default mapping size is 1MiB of ram. However, not
all systems allow 1MiB of memory to mapped depending on
the kernel's memory map. Therefore, be explicit about
the sizes to mmap().
The only path that wasn't cleaned up was the coverage path
as that needs to handle dynamic cbmem. The correct way to
fix that is to add a global like the timestamps that is set
while parsing cbtable.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Can cbmem -ltc on ryu.
Change-Id: I548afa5ddbe0a859f52bc2ab2d0931186ee378a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: df4991ce1da7f0c25e99d84222cbc8d3189d0d66
Original-Change-Id: I27b70ae8a8fba168d1c1829bbef0135c7b651eac
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/221971
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8829
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BRANCH=None
BUG=None
TEST=Manual
Change-Id: I8b31a0b194d353ea3e7863513f2e36f3e032fad8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ccba49a7c2372cdfff6e2947e417d4d4f5436c2
Original-Change-Id: I9beebdf29e4fc4aa645581146fdc61c659de72df
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/8808
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.
Change-Id: Ie367c348fbf59465e238e5fa60f217f5373501b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a754bc1fe39c19ab8b2f7be9648cccb06156b0ef
Original-Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218843
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8807
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
uio_usbdebug enables you to debug coreboot's usbdebug driver inside a
running operating system (only Linux at this time). This comes very
handy if you're hacking the usbdebug driver and don't have any other
debug output from coreboot itself.
Currently, only Intel chipsets are supported.
Change-Id: Iaf0bcd4b4c01ae0b099d1206d553344054a62f31
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/4695
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We use paths relative to that in the buildgcc script.
Change-Id: I2b79c3d2c75088af7e8e362d18a38274352eb965
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8713
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
You can build your new toolchain with:
$ cd util/crossgcc/
$ ./buildgcc -d /opt/cross -p x86_64-elf -j 16
or
$ make crossgcc-x64
Change-Id: I8eb584166294578d2b33c63e94ed3aca9b5de4f4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8668
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Vadim Bendebury