Using origin/master as the git revision breaks reproducibility, giving
different values depending on when the code was pulled from the
repo at coreboot.org. By using the current revision instead, we get
identical builds.
Change-Id: If4be6e048d6c8e417b8c074199745900ccd82b49
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12807
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
clang version now returns:
coreboot toolchain v1.33 November 25th, 2015 clang version 3.6.1
(tags/RELEASE_361/final) (based on LLVM 3.6.1)
Change-Id: I948d7f4d06c244987342cfc7d5c7e728cbed93bd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12777
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Quoting variables prevents word splitting and glob expansion, and
prevents the script from breaking when input contains spaces, line
feeds, glob characters and such.
See shellcheck warning SC2086.
Change-Id: I7256d2fc2a22bce7723950a534fef6d57cbd097f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12761
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This allows users who build the rom from the board-status repo to
verify that their rom matches the original.
Change-Id: I4e8564e389495909219f92ccdafb8e9568f8f0d0
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12760
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Print what the script is doing so when it asks for the ssh password
several times in a row, it's obvious that it's actually doing different
things, not that the password failed.
- Don't print the output from cbfstool - it's not useful.
Change-Id: I785283475e14f242117682800c26db6b4f9f1e2c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12759
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If the payload_config and payload_version files are in coreboot.rom,
extract and save them.
Change-Id: I36b17ed189f94e2d4e873b0e219e5a9a2abe77a1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12758
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The old serial port read method lost characters from the boot log. This
method works better for me.
- Put get_serial_bootlog arguments into variable names for clarity.
- Fully configure the serial port with stty: disable parity and flow control.
- Change serial port read from reading with 'cat' to reading with 'read'.
- Update help to show current default speed from the variable.
tested under dash, bash, and zsh on several platfoms.
Change-Id: I91ae63a3c226e61019dbdf69c405c3f20ba7db54
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12757
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the coreboot toolchain version to iasl's version output.
% ./xgcc/bin/iasl -v
Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20150619-64
Copyright (c) 2000 - 2015 Intel Corporation
coreboot toolchain v1.33 November 25th, 2015
This won't actually be checked until the next version of
iasl so that we don't have to rebuild again for no reason.
The buildgcc version was intentionally not incremented for
this minor change.
Change-Id: I03a1a777fdb84e34bfceb7b1eb43fffbc1f3a2fc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The constant for ppc64 is 'hotstuff'. For many reasons.
Note that line 2894 of elf.h is not indented. This is because in the
original the line begins with a space. Checkpatch rejects that.
Checkpatch also rejects changing the space to a tab because that makes
it more than 80 chars. I rejected breaking the line because it makes it
even less readable. All the changes forced by checkpatch make the code
less readable.
Herman Hollerith would be proud.
Change-Id: I21f049fe8c655a30f17dff694b8f42789ad9efb7
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/12711
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
We still add a master header for compatibility purposes, and the default
layouts don't cover anything non-coreboot (eg. IFD regions) yet.
The default layouts can be overridden by specifying an fmd file, from
which the fmap is generated.
Future work:
- map IFD regions to fmap regions
- non-x86: build minimalistic trampolines that jump into the first cbfs
file, so the bootblock can be part of CBFS instead of reserving a
whole 64K for it.
- teach coreboot's cbfs code to work without the master header
- teach coreboot's cbfs code to work on different fmap regions
Change-Id: Id1085dcd5107cf0e02e8dc1e77dc0dd9497a819c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/11692
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The former interpretation sprung from the x86 way of doing things
(assuming top-alignment to 4GB). Extend the mechanism to work with CBFS
regions residing elsewhere.
It's compatible with x86 because the default region there resides at the
old location, so things fall in place. It also makes more complex
layouts and non-x86 layouts work with negative base addresses.
Change-Id: Ibcde973d85bad5d1195d657559f527695478f46c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12683
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
I didn't go back through the development guide for this.
But based on test, if the empty entry is filled as 0xFFFFFFFF,
instead of 0, the USB3 port can not be used.
Leave the entries of PSP and PSP2 as 0xFFFFFFFF to be compliant
with the case before the amdfwtool is used.
Change-Id: Icd5f9891e541279dbd551bbceaf091488d22bfef
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/12665
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Until there's a reason to, don't print a warning about the missing
power8 compiler.
Change-Id: I47c60e0a16892f0fa228e1439e0424926bca00a4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12634
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
The help text had gotten kind of sloppy. There was a missing newline
in the add-stage command, some of the lines were too long, etc.
Change-Id: If7bdc519ae062fb4ac6fc67e6b55af1e80eabe33
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
- Including the help targets in the list of NOCOMPILE targets means they
can run even if the toolchain is mucked up. Since they contain info on
building the toolchin, this is useful.
- Separate the three current parts of the help target into individual
components: help_coreboot, help_toolchain, and help_kconfig. This is
mostly for the help_toolchin target which will be printed out by
toolchain.inc.
Change-Id: I365d95fd63e22bddd122fb1fede6f04270e03d63
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12542
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
power8 is set up by ibm as a powerpc subset, so we follow
that rule here: we call it a powerpc but require -mcpu=power8
Change-Id: Ib5212be22db9584b0dc0eeed5c06ec1924347067
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/12624
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ERROR: code indent should use tabs where possible
+^I trampoline_len);$
Change-Id: If46f977e2e07d73e6cfd3038912a172236a7e571
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12620
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It's not needed, so we can remove some extra file mangling, too.
Change-Id: I80d707708e70c07a29653258b4cb6e9cd88d3de3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12508
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add the code necessary to create the linux trampoline blob.
Don't enforce this for the in-coreboot build or use objcopy
to produce linux_trampoline.o as it is a bit trickier to get
all the details right than I had hoped:
- you have to know the elf architecture of the host machine
- you might have to have more tools (xxd, perl, etc) installed
Change-Id: I9b7877c58d90f9fb21d16e0061a31e19fffa2470
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12505
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The existing code used a stale pointer from a previously unmapped
region of memory when parsing the coreboot tables. Use the correct
pointer from the currently mapped memory region when parsing.
Change-Id: Id9a1c70655fe25bc079e5bee55f15adf674694f8
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12619
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The previous code would miss the first of two IS_ENABLED(CONFIG_symbol)
sequences on a line. This patch saves the rest of the line and loops
to check any other entries on the same line of text.
Change-Id: If4e66d5b393cc5703a502887e18f0ac11adff012
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12562
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Combine the file and line number into a combination that editors
understand when opening files. This makes it easier to edit the
errors.
Change-Id: Id2fae6a0a2ca8d726b95e252d80ac918f4edbe23
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12561
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Create subroutines for printing warnings and errors
- Change all the existing warning and error routines to use subroutines
- Add new command line options to suppress errors and to print notes
Change-Id: I04893faffca21c5bb7b51be920cca4620dc283c3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12555
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
By adding the version number of tools, we can help people keep up to
date with their tool versions. This will be used now to determine
whether the IASL version being used is the version supported by
coreboot.
Change-Id: I24a68b01c819871f90403869570125e71b96bd70
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12545
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Mingw doesn't have that this function.
Change-Id: I640ea61ff24fba812e3f10771dd7e468dcfc63dd
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/11724
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This makes the make process look like the one inside
of coreboot's build system.
Change-Id: I48be2df39cad47644e16ce583b27c33a1da81fc3
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/12509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
PSP2 is for Combo BIOS, which is the idea that one image supports 2
kinds of APU.
The PSP2 feature is for the future, not for current products.
The newest document about PSP2 is not available. I made it from the
draft code I made when I was in AMD.
Change-Id: I65328db197c02ee67f3e99faf4ab8acabd339657
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/12474
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Currently running 'make help' just gives help for the kconfig targets.
This adds help for common coreboot and toolchain targets. It stops
printing some of the less common kconfig targets, but still leaves
them in the makefile as documentation.
Change-Id: I2a00fcbc06f05dc4029a91f3dff830c19e4d1329
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12458
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
mma_setup_test.sh is used to set MMA test name and MMA test config
name. After executing this script user needs to reboot the system and
FSP/coreboot would execute the selected MMA test. FSP and coreboot needs
to be built with MMA support.
mma_get_result.sh will get the raw MMA results from cbtable and save it
to bin file.
BRANCH=none
BUG=chrome-os-partner:43731
TEST=Build and Boot kunimitsu (FAB3).
CQ-DEPEND=CL:299476,CL:299475,CL:299474,CL:299509,CL:299508,CL:299507,CL:*230478,CL:*230479
Change-Id: Ie330151535809676167f0b22c504a71975841414
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35469218fe53c1ac211f55bd26a206a05a827453
Original-Change-Id: I7d20aca63982e13edc41be2726f3cc7e41d95bae
Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/299473
Original-Commit-Ready: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Tested-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: http://review.coreboot.org/12483
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Changed following things,
(1) cbmem -l would give both ID and Name for coreboot table along with
START and LENGTH of each entry
e.g.
localhost ~ # cbmem -l
CBMEM table of contents:
NAME ID START LENGTH
<.....>
3. TIME STAMP 54494d45 77ddd000 000002e0
4. MRC DATA 4d524344 77ddb000 00001880
5. ROMSTG STCK 90357ac4 77dd6000 00005000
6. VBOOT WORK 78007343 77dd2000 00004000
7. VBOOT 780074f0 77dd1000 00000c3c
8. RAMSTAGE 9a357a9e 77d13000 000be000
9. REFCODE 04efc0de 77c01000 00112000
10. ACPI GNVS 474e5653 77c00000 00001000
11. SMM BACKUP 07e9acee 77bf0000 00010000
<..etc..>
(2) With this patch, new command line arg "rawdump" or "-r" will be
added to cbmem
user can grab the ID with "cbmem -l" and execute "cbmem -r <ID>" to get
raw dump of cbtable for the <ID> in interest.
This change is needed to get MMA results data from cbtable. Coreboot
stores the MMA results in cbmem. Separate post processing scripts uses
cbmem utility to get the these data.
This feature in the cbmem tool can also help debugging some issues where
some specific ID of cbtable needs examination.
BRANCH=none
BUG=chrome-os-partner:43731
TEST=Build and Boot kunimitsu (FAB3). Cbmem -r and -l works as described.
Not tested on Glados
CQ-DEPEND=CL:299476,CL:299475,CL:299473,CL:299509,CL:299508,CL:299507,CL:*230478,CL:*230479
Change-Id: I70ba148113b4e918646b99997a9074300a9c7876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f60c79d845d4d4afca480b6884c564a0d5e5caf8
Original-Change-Id: I1dde50856f0aa8d4cdd3ecf013bd58d37d76eb72
Original-Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Signed-off-by: Icarus Sparry <icarus.w.sparry@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/299474
Original-Commit-Ready: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Tested-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: http://review.coreboot.org/12482
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Building cbmem with ASan
$ CC=gcc-5 CFLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer" LDFLAGS="-fsanitize=address" make
it sometimes finds a heap-buffer-overflow, while dumping the CBMEM
console.
$ sudo ./cbmem -c
=================================================================
==11208==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb5d5782b at pc 0x0804a4d7 bp 0xbfe23bc8 sp 0xbfe23bbc
WRITE of size 1 at 0xb5d5782b thread T0
#0 0x804a4d6 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:553
#1 0x804a4d6 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134
#2 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62)
#3 0x8048cf0 (/home/joey/src/coreboot/util/cbmem/cbmem+0x8048cf0)
0xb5d5782b is located 50 bytes to the right of 131065-byte region [0xb5d37800,0xb5d577f9)
allocated by thread T0 here:
#0 0xb72c64ce in __interceptor_malloc (/usr/lib/i386-linux-gnu/libasan.so.2+0x924ce)
#1 0x804a407 in dump_console /home/joey/src/coreboot/util/cbmem/cbmem.c:542
#2 0x804a407 in main /home/joey/src/coreboot/util/cbmem/cbmem.c:1134
#3 0xb70a3a62 in __libc_start_main (/lib/i386-linux-gnu/i686/cmov/libc.so.6+0x19a62)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/joey/src/coreboot/util/cbmem/cbmem.c:553 dump_console
Shadow bytes around the buggy address:
0x36baaeb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x36baaef0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
=>0x36baaf00: fa fa fa fa fa[fa]fa fa fa fa fa fa fa fa fa fa
0x36baaf10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36baaf50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
==11208==ABORTING
Fix up commit 06b13a37 (cbmem: Terminate the cbmem console at the cursor
position.) by reverting setting the cursor to 0.
Change-Id: Id614a8e0f1a202671dd091f825d826a17176bfcc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10572
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Bail out if .xcompile is incomplete or can't be regenerated.
Change-Id: I74adeded7a3e849b25bf65c5b02f67820f29c7e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12477
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On system with clang, "as" is available but "objdump" is not by default.
So if ${gccprefix} is empty, "as" can run successfully and the "objdump"
below might report error. Mask that output.
Change-Id: I9940f069f66e097973ed6138cf3c696087fa5531
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11681
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
The second parameter is to set file permissions for the directory, which
is not needed in mingw.
Change-Id: I88e317f075e8a39f0a280b3dd6e597d119f0f741
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11723
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If HOSTCC=clang, the -Wtautological-constant-out-of-range-compare is
set automaticaaly. That assume the value of type enum is in the defined
range. Then testing if a type enum is out of range causes build error.
Error:
coreboot/util/cbfstool/cbfs_image.c:1387:16: error:
comparison of constant 4 with expression of type 'enum vb2_hash_algorithm'
is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (hash_type >= CBFS_NUM_SUPPORTED_HASHES)
~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
clang version:
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
Change-Id: I3e1722bf6f9553793a9f0c7f4e790706b6938522
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12330
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This models gcc's (and other compilers') behavior to not bail
out with an error when one of the include paths does not exist.
Change-Id: Ic93a55cea6b32516fd76da9b49abe7b990829889
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12469
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
- Only build IASL once for the 'all' targets instead of once for each.
- Change the control of what gets built from different targets to
variables on the build line.
- Clean up and correct the list of phony targets
- Don't keep the temporary files around while building all. This
takes up a lot of space. If it's desired behavior, add
BUILDGCC_OPTIONS=-t on the make command line.
- Add comments about CPU= and BUILDGCC_OPTIONS= variables
- Add KEEP_SOURCES option
Change-Id: I7752974e249f25717b42be25a841c69af84d5c69
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Otherwise </testsuite> is missing and jenkins can't make sense of
things.
Change-Id: If11a6d2506efc9d7c915f50896b2714bc66e3b65
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12478
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The function fletcher is moved to amdfwtool.
Change-Id: I39eb05a184d8878a96f8de46caf4b5c6c433dc3a
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12455
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Combine all needed AMD firmware into one single firmware, which going to
be added as one single CBFS module.
Change-Id: Ib044098c1837592b8f7e9c6a7da4ba3a32117e25
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/12419
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's not deprecated if it's still in active use. The code layout is just
"funny" (and could warrant a chipset-side cleanup, but not today)
Change-Id: I5f7776ceba0134f20364a0c4a1ca51382e9877e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12429
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When using FMAP regions (with option -r) that were generated with a
master header (as done by cbfstool copy, eg. in Chrome OS' build
system), there were differences in interpretation of the master header's
fields.
Normalize for that by not sanity-checking the master header's size field
(there are enough other tests) and by dealing with region offsets
properly.
BUG=chromium:445938
BRANCH=tot
TEST=`cbfstool /build/veyron_minnie/firmware/image.dev.bin print -r
FW_MAIN_A` shows that region's directory (instead of claiming that
there's no CBFS at all, or showing an empty directory).
Change-Id: Ia840c823739d4ca144a7f861573d6d1b4113d799
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e5364d291f45e4705e83c0331e128e35ab226d3
Original-Change-Id: Ie28edbf55ec56b7c78160000290ef3c57fda0f0e
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/312210
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12416
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is required to handle certain relative-to-flash-start offsets.
BUG=none
BRANCH=tot
TEST=none
Change-Id: I8b30c7b532e330af5db4b8ed65b21774c6cbbd25
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 596ba1aaa62aedb2b214ca55444e3068b9cb1044
Original-Change-Id: Idc9a5279f16951befec4d84aab35117988f7edb7
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/312220
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12415
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This script generates the rough format for the release notes, and will
add new commits to the top of an existing release notes text file. At
that point, a lot still needs to be done by hand - deciding which
commits deserve to be in the release notes, and which don't.
When updating the existing release notes, The updates are just added
to the top of the file, and need to be placed manually. This just
helps prevent missed commits.
When editing the release notes, don't delete or modify the commit id
lines after they've been classified - Just move them to the bottom of
the file until the notes are ready to publish. This keeps those commits
from re-appearing at the top of the file the next time the script is run
to update the notes.
Change-Id: I0a699c528117f0347a65a3bed4402f3a57309e3c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12318
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This is an update to the script in the blobs repo that converts
individual or multiple files into a microcode binary.
Change-Id: I66fb650bbfa334d1f07e8e3914ef6deb8e72bbb4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12332
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
On mingw, the function glob has some default options
which are not compliant with man page.
If gl_offs is not set as 0, there may be some slots which
is reserved.
If gl_pathc or gl_pathv is not set as 0, the result might
be appended to the list instead of being added as new ones.
Change-Id: I03110c4cdda70578828d6499262a085a81d26313
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11711
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The buildgcc makefile was using the variable 'BUILDJOBS' to pass the
number of cores to use for the build into buildgcc. This is changed
to 'CPUS' to match the variable name for the what-jenkins-does target.
Change-Id: I373c4988e9f096ca2e142afdd5e94d7d806891e3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12299
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbmem utility shouldn't be using the intra coreboot
data structures for obtaining the produced data/information.
Instead use the newly added cbmem records in the coreboot
tables for pulling out the data one wants by using the
generic indexing of coreboot table entries.
BUG=chrome-os-partner:43731
BRANCH=None
TEST=Interrogated cbmem table of contents with updated code.
Change-Id: I51bca7d34baf3b3a856cd5e585c8d5e3d8af1d1c
Reviewed-on: http://review.coreboot.org/11758
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Show laptops and servers before desktop boards since that's where both
the market and coreboot are the most active these days.
Change-Id: I7de63975f3f2ff5e983b19e07558175a58870a1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12292
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
There's the sentiment that the Supported_Motherboards wiki page is
outdated. Point out that the list is current (and drop the table of
contents that became a distraction).
Change-Id: Ib2363fad0b7f6951b07b2ad0c85148d9bc729b55
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12291
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
abuild -t EMULATION_QEMU_UCB_RISCV,EMULATION_SPIKE_UCB_RISCV works now
Change-Id: I49d8cd86e21ede724d8daa441b728efa1f6ea1fa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12281
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
junit reports were kept around (and appended to) in some cases, leading
to duplicate reports on jenkins.
Drop old per-mainboard reports before building said boards, and do the
same for the tools (reported thrice).
Change-Id: I74a035587bbf917dca85ba6fc74621c583efe9a2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Specifying a directory with multiple boards (eg abuild -t google/veyron)
makes abuild run through all of them.
Change-Id: Ifb60f3a1f0c4a727dc43c48671ea90711ffe5585
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12278
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Since we now have multiple boards in a single mainboard directory (eg
google/veyron), we need some other identifier from which to create
output directories and filenames in abuild than the directory name.
Use the wildcard part of CONFIG_BOARD_* instead.
This changes the semantics of payload.sh handling: it's passed the
single new identifier instead of two arguments "vendor" and "board" that
constitute the mainboard directory's path.
Change-Id: I0dc59c6a1ad1ee51d393fa06b98944a6da342cdf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12277
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It only takes a single argument now, which is the directory below the
coreboot-builds directory. Preparation for future work.
The only visible change is in console output.
Change-Id: I4b0fe268ccfb69a0403fa5f8b23444c07843386f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12276
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's passed the mainboard's directory name (below $TARGET) directly
in preparation of more rework in that area.
Change-Id: I3a82b8673fdea07bc5c957f76f4685c34a805334
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12275
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Its hardcoded HTTP endpoint is gone since 2007.
Change-Id: Ib76814d31b571456d950d45f45912036b6fa82d1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12274
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
If you already have a configuration, there's no need to run it through
abuild.
Change-Id: I4dde9a7b96bb0c08ec5c91426a4dd3aa15e74edf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12273
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
checkpatch.pl that we inherited from Linux checks for its absence, so it
may be easiest to follow their style of not caring for the FSF's address
anymore.
TEST=visual check that `git diff` and `git diff |grep "^[+-]" | \
grep -v "^--- " |grep -v "^+++ " |sort | uniq -c |sort -n` look
reasonable (matching number of removed and added comment terminators */,
etc.).
Also, `git grep -A3 "You should have received a copy"` only
returns license texts, imported files, patches and help strings in
applications as remaining copies of that paragraph
Change-Id: I7c43860b6fd7ec526983c24b608994539128cfb9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11887
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Those may collide with strings.h's index(), included transitively
through system headers.
Change-Id: I6b03236844509ea85cfcdc0a37acf1df97d4c5f3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12279
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This timestamp marks that EC verification has completed.
BUG=chromium:537269
TEST=Run cbmem on glados, verify "1030:finished EC verification" is
seen.
BRANCH=None
Change-Id: I0114febae689584ec8b12c169e70f2d3995d8d4d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: deeb2ab8085e5ea0a180633eb8fb1c86aadffe94
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Change-Id: I4f09e970ffedc967c82e6283973cbbcb2fbe037f
Original-Reviewed-on: https://chromium-review.googlesource.com/309280
Original-Commit-Ready: Shawn N <shawnn@chromium.org>
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12230
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: build bot (Jenkins)
Mostly a proof of concept for adding fuzzing to our tree.
Change-Id: I10e5ef3a426b9c74c288d7232a6d11a1ca59833b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/12183
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This is a tool to help identify issues in coreboot's Kconfig structure
and in how the Kconfig symbols are used in the coreboot codebase.
It identifies a number of issues:
- #ifdef used on Kconfig symbol of type bool, hex, or int. These are
always defined.
- #define CONFIG_ in the coreboot code - these should be reserved
for Kconfig symbols.
- Redefinition of Kconfig symbols in the code.
- Use of IS_ENABLED() on non-bool kconfig symbols.
- Use of IS_ENABLED() on values that are not kconfig symbols.
- Attempts to find default values that will not set anything
because of earlier default settings. This needs to be expanded
significantly.
- Kconfig expressions using symbols which are not defined.
- Kconfig symbols that are defined but not used anywhere in the
Kconfig structure or coreboot code.
- Kconfig keywords used incorrectly.
- Whitespace issues
- Kconfig 'source' keyword issues
-- sourcing non-existant directories
-- sourcing Kconfig files multiple times
-- sourcing non-existent files
-- Kconfig files in the codebase that are never sourced
Additionally, it can be used to help debug the Kconfig tree
by putting all the files together into a single file with
their source locations listed.
Run from the coreboot directory:
util/lint/kconfig_lint
Change-Id: Ia53b366461698d949f17502e99265c1f3f3b1443
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12088
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With the previous ELF stage extract support the resulting
ELF files wouldn't handle rmodules correctly in that the
rmodule header as well as the relocations were a part of
the program proper. Instead, try an initial pass at
converting the stage as if it was an rmodule first. If it
doesn't work fall back on the normal ELF extraction.
TEST=Pulled an rmodule out of Chrome OS shellball. Manually
matched up the metadata and relocations.
Change-Id: Iaf222f92d145116ca4dfaa955fb7278e583161f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12222
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to convert rmodules back into ELF files one needs
to add in the relocations so they can be converted back to
rmodules. Because of that requirement symbol tables need
to be present because the relocations reference the symbols.
Additionally, symbol tables reference a string table for the
symbol names. Provide the necessary support for adding all
of those things to an ELF writer.
TEST=Extracted rmodule from a cbfs and compared with the
source ELF file. Confirmed relocations and code sizes
are correct.
Change-Id: I07e87a30b3371ddedabcfc682046e3db8c956ff2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of creating a loadable segment for each section with
SHF_ALLOC flag merge those sections into a single program
segment. This makes more tidy readelf, but it also allows
one to extract an rmodule into an ELF and turn it back into
an rmodule.
TEST=Extracted both regular stages and rmodule stages. Compared
against original ELF files prior to cbfs insert.
Change-Id: I0a600d2e9db5ee6c11278d8ad673caab1af6c759
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12220
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of dumping the raw stage data when cbfstool
extract is used on stage create an equivalent ELF file.
Because there isn't a lot of information within a stage
file only a rudimentary ELF can be created.
Note: this will break Chrome OS' current usage of extract
since the file is no longer a cbfs_stage. It's an ELF file.
TEST=Extracted romstage from rom.
Change-Id: I8d24a7fa4c5717e4bbba5963139d0d9af4ef8f52
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12219
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order for one to extract ELF files from cbfs it's
helpful to have common code which creates a default
executable ELF header for the provided constraints.
BUG=None
TEST=With follow up patch am able to extract out romstage
as an ELF file.
Change-Id: Ib8f2456f41b79c6c0430861e33e8b909725013f1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12218
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to prepare allowing for one to extract a stage
into an ELF file provide an optional -m ARCH option. This
allows one to indicate to cbfstool what architecture type
the ELF file should be in.
Longer term each stage and payload will have an attribute
associated with it which indicates the attributes of
the executable.
Change-Id: Id190c9719908afa85d5a3b2404ff818009eabb4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12217
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to actually do something useful with the
resulting file after being extracted decompress stage
files' content. That way one can interrogate the
resulting file w/o having to decompress on the fly.
Note: This change will cause an unexpected change to
Chrome OS devices which package up individual stage
files in the RW slots w/o using cbfs. The result will
be that compressed stages are now decompressed.
Longer term is to turn these files into proper ELF
files on the way out.
Change-Id: I373ecc7b924ea21af8d891a8cb8f01fd64467360
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12174
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This utility links in coreboot code, and has been broken for a while
again after removing some hacks from coreboot. I hadn't realized how
bad it was broken last time, and since most of this stuff is still
in a pretty bad shape, I decided to throw all of the changes together.
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: If3e4399b1b0e947433b97caa29962ef66ea2993d
Reviewed-on: http://review.coreboot.org/11736
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Currently cbfs stage files that are compressed do not have
the decompressed size readily available. Therefore there's
no good way to know actual size of data after it is
decompressed. Optionally return the decompressed data size
if requested.
Change-Id: If371753d28d0ff512118d8bc06fdd48f4a0aeae7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12173
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If one wants to use buffer_init() for initializing a
struct buffer all the fields should be initialized.
Change-Id: I791c90a406301d662fd333c5b65b2e35c934d0f7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12172
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Have clean remove junit.xml files.
- Remove junit.xml target from cbmem makefile - this is in the top
level Makefile.inc now.
- add distclean targets to makefiles.
- Make sure all makefiles have .PHONY set up.
- rm commands need -f or they will fail if the file they're trying
to remove doesn't exist, causing the build to fail.
Change-Id: I2f0635f2c0a9417e3377a90c8d67103323c4a72f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add minimal Makefile based on cbmem’s Makefile.
The make target `junit.xml` is removed as this is handled differently
since commit de9adebb (Add junit.xml code to top Makefile.inc instead of
utils).
Also the `junit.xml` is removed in the make target `clean`.
Additionally, the make target `distclean` is added, as the current
junit.xml code in the top `Makefile.inc` requires that.
Change-Id: I164b1f7733505bca6248d0711d7ad71d635fa926
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11876
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch fixes compilation of cbfstool on Cygwin.
As reported in http://review.coreboot.org/#/c/10027
cbfstool on Cygwin likes to be compiled with -D_GNU_SOURCE.
That patch was abandoned because it would unwantedly turn on
more GNU extensions. Instead of doing that, only enable the
define on Cygwin, switch to -std=gnu99 instead of -std=c99 to
make fileno and strdup actually available.
A MINGW32 check that was forgotten in Makefile was copied over
from Makefile.inc to keep the two files in sync.
This patch has no impact on non-Windows builds.
Change-Id: I068b181d67daf9c7280110e64aefb634aa20c69b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11667
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This utility should make it easier to complete and maintain
the database of coreboot subsystem maintainers (MAINTAINERS
file)
This will need a bit of tender love and care to print information
in an easily machine readable output for the build system, but its
a first start to query the maintainers database.
Build with:
$ go build util/scripts/maintainers.go
Find a maintainer for a set of files with:
$ ./maintainers Makefile Makefile.inc
Makefile is in subsystem BUILD SYSTEM
Maintainers: [Patrick Georgi <patrick@georgi-clan.de>]
Makefile.inc is in subsystem BUILD SYSTEM
Maintainers: [Patrick Georgi <patrick@georgi-clan.de>]
Check the maintainer database with:
$ ./maintainers
.gitignore has no subsystem defined in MAINTAINERS
.gitmodules has no subsystem defined in MAINTAINERS
.gitreview has no subsystem defined in MAINTAINERS
3rdparty/arm-trusted-firmware has no subsystem defined in MAINTAINERS
3rdparty/blobs has no subsystem defined in MAINTAINERS
3rdparty/vboot has no subsystem defined in MAINTAINERS
COPYING has no subsystem defined in MAINTAINERS
Documentation/AMD-S3.txt has no subsystem defined in MAINTAINERS
Documentation/CorebootBuildingGuide.tex has no subsystem defined in MAINTAINERS
Documentation/Doxyfile.coreboot has no subsystem defined in MAINTAINERS
[..]
Change-Id: I49c43911971152b0e4d626ccdeb33c088e362695
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/12119
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cygwin complains:
cbfstool.c: 1075:5 error: array subscript has type 'char' [-Werror=char-subscripts]
so add an explicit cast.
Change-Id: Ie89153518d6af2bacce3f48fc7952fee17a688dd
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11666
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Those are actually board specific. Keep the old value as defaults,
though. The defaults are included by all affected boards.
Change-Id: Ib865c7b4274f2ea3181a89fc52701b740f9bab7d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Please don't remove chipsets and mainboards without discussion and input
from the owners. Someone was asking about cougar canyon 2 just a couple
of weeks ago - there's obviously still interest.
This reverts commit fb50124d22.
Change-Id: Icd7dcea21fa4a7808b25bb8727020701aeebffc9
Signed-off-by: Martin Roth <martinroth@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/12128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, cbfstool regressed that removing a file from CBFS the space
is marked as empty but the filename is still shown, preventing adding a
file with the same name again. [1]
```
$ echo a > a
$ echo b > b
$ ./util/cbfstool/cbfstool test.rom create -m x86 -s 1024
Created CBFS (capacity = 920 bytes)
$ ./util/cbfstool/cbfstool test.rom add -f a -n a -t raw
$ ./util/cbfstool/cbfstool test.rom add -f b -n b -t raw
$ cp test.rom test.rom.original
$ ./util/cbfstool/cbfstool test.rom remove -n
$ diff -up <(hexdump -C test.rom.original) <(hexdump -C test.rom)
--- /dev/fd/63 2015-08-07 08:43:42.118430961 -0500
+++ /dev/fd/62 2015-08-07 08:43:42.114430961 -0500
@@ -1,4 +1,4 @@
-00000000 4c 41 52 43 48 49 56 45 00 00 00 02 00 00 00 50 |LARCHIVE.......P|
+00000000 4c 41 52 43 48 49 56 45 00 00 00 02 ff ff ff ff |LARCHIVE........|
00000010 00 00 00 00 00 00 00 28 61 00 00 00 00 00 00 00 |.......(a.......|
00000020 00 00 00 00 00 00 00 00 61 0a ff ff ff ff ff ff |........a.......|
00000030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
$ ./util/cbfstool/cbfstool test.rom add -f c -n c -t raw
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
c 0x0 raw 2
b 0x40 raw 2
(empty) 0x80 null 792
```
So it is “deteled” as the type changed. But the name was not changed to
match the *(empty)* heuristic.
So also adapt the name when removing a file by writing a null byte to
the beginning of the name, so that the heuristic works. (Though remove
doesn't really clear contents.)
```
$ ./util/cbfstool/cbfstool test.rom remove -n c
$ ./util/cbfstool/cbfstool test.rom print
test.rom: 1 kB, bootblocksize 0, romsize 1024, offset 0x0
alignment: 64 bytes, architecture: x86
Name Offset Type Size
(empty) 0x0 null 2
b 0x40 raw 2
(empty) 0x80 null 792
```
[1] http://www.coreboot.org/pipermail/coreboot/2015-August/080201.html
Change-Id: I033456ab10e3e1b402ac2374f3a887cefd3e5abf
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/11632
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
When the script was pulled out of the makefile, it was left as it was
written in the makefile to show the continuity with the original. This
patch cleans up issues identified by shellcheck and adds comments.
Change-Id: I5e6573a4fdfbb397e15db38e2e3dfadeb3430573
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11931
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To add lint to jenkins testing, we need junit.xml output. This adds an
optional --junit command line parameter to enable output to an xml file
in the lint directory.
Change-Id: I5588190cb050b9dbe99458cb18a71a147769f50e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11891
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In preparation for adding junit xml to the lint tests, move the
script out of Makefile.inc and into its own file.
Add a copyright, usage, and error checking that was not needed
inside the Makefile.
Change-Id: I32bebc6a5f1f6fa652812c8a014d84006e2e6c8a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11890
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The 'what-jenkins-does' makefile target was renaming the junit filename
after abuild finished. Instead, just add a command line parameter to
send it to a different filename.
Change-Id: I66f7d80d621573d77a5154f36f2db49d7b2e948a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
E.g. on my MacbookAir to generate spd.bin to be used
with coreboot I do:
./inteltool -S spd.bin
Change-Id: If165475ed3e1f3262a8926ef619128d25b1e2896
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11847
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Only one value would work with corresponding gma code currently (which one
depends on board). Going forward, it's possible to compute which number can
be used, so there is no need to keep this info around.
Change-Id: Iadc77ef94b02f892860e3ae8d70a0a792758565d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11862
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Currently cbfstool would reject non-alpanumeric characters in
image names. Underscore is not alphanumeric and is used in some
default fmaps. This change allows image names to contain all
"printable" characters except spaces.
Change-Id: I6ba2b581d5623f5b028149ece0169892ea63fd04
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: http://review.coreboot.org/11807
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The binutils-2.25 has added some new line, making the hunk
move downward a little. The utility patch can fix the offset
with "fuzz" message. So, recreate the patch to avoid that
message.
Change-Id: Ie659a8faf923465f6d47f7c0c0bf903c5eb903ab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11639
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Clang is the default compiler on BSD and OS X. With this
change, we don't have to install gcc any more. Clang can
act as host cc.
This is a known issue on GNU mail list. Please refer
the link below.
https://sourceware.org/bugzilla/show_bug.cgi?id=17473
Change-Id: I0f014b776e86e6d0cbebd560cb17f469f31e1dfb
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11638
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Grep the output of wget, showing only the percentage.
Leave the final "100%" unerased.
Checking return code of wget is removed.
Change-Id: I4559e88d541738a594dce92e23589992f234cb9b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11520
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
This is a sad story. We have three different code paths for
sandybridge and ivybridge: proper native path, google MRC path, and,
everyone's favorite: Intel FSP path. For the purpose of this patch,
the FSP path lives in its own little world, and doesn't concern us.
Since MRC was first, when native files and variables were added, they
were suffixed with "_native" to separate them from the existing code.
This can cause confusion, as the suffix might make the native files
seem parasitical.
This has been bothering me for many months. MRC should be the
parasitical path, especially since we fully support native init, and
it works more reliably, on a wider range of hardware. There have been
a few board ports that never made it to coreboot.org because MRC would
hang.
gigabyte/ga-b75m-d3h is a prime example: it did not work with MRC, so
the effort was abandoned at first. Once the native path became
available, the effort was restarted and the board is now supported.
In honor of the hackers and pioneers who made the native code
possible, rename things so that their effort is the first class
citizen.
Change-Id: Ic86cee5e00bf7f598716d3d15d1ea81ca673932f
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11788
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
When adding an FSP blob relocate it to its final
destination. This allows FSP to not be hard coded in
the cbfs. In order for the include paths to work
correctly w/ the edk 2 headers we need to supply
a neutered ProcessorBind.h to match up with the
tool environment such that one can get the UEFI
Platform Initialization type definitions.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados and booted. Also added FSP with -b and manually
adjusted location in fsp cache-as-ram. Booted as well.
Change-Id: I830d93578fdf745a51195109cf18d94a83ee8cd3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11778
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For shared compilation units between coreboot proper
and cbfstool that means one needs to provide printk
logging. Therefore, provide printk() at <console/console.h>
to mimic coreboot's environment.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built cbfstool with code that includes and uses
<console/console.h>.
Change-Id: I8e54d403526a397e4fd117738a367a0a7bb71637
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11774
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Older gcc versions throws a warning when a struct or union is
declared without a valid name (anonymous). This patch enables the
feature for older gcc versions so that no warning will be issued.
Change-Id: Idc5481f4d5723c5090a6f7d7dbb0686a737e11fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: http://review.coreboot.org/11779
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
They allow optimizing a verification of a whole CBFS image by only
dealing with the headers (assuming you choose to trust the hash
algorithm(s)).
The format allows for multiple hashes for a single file, and cbfstool
can handle them, but right now it can't generate such headers.
Loosely based on Sol's work in http://review.coreboot.org/#/c/10147/,
but using the compatible file attribute format. vboot is now a hard
dependency of the build process, but we import it into the tree for
quite a while now.
Change-Id: I9f14f30537d676ce209ad612e7327c6f4810b313
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11767
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1c5e3424cb56f1f10e75bb07db084c3500f3ba07
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11768
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We need to emit some hex strings.
Change-Id: I9e7e184282f6ad0470f2e269f5dc874e78f8b697
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11766
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Iecefdd1e827e4eb8b4da573e4291850d6c47767f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11754
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
To catch dependency errors in symbol.c (such as the ones
fixed by I51b4ee326f082c6a656a813ee5772e9c34f5c343) we need
to check for global kconfig warnings before saving config
files.
This patch will produce errors for wrong dependencies and
add catching of errors to conf, nconf and mconf. Sorry,
gconf users, you will have to wait.
Change-Id: Idf7ee406ce3869941af319219aea16fab826df84
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11291
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Up to now, if both fmap and a master header existed, the master header
was used. Now, use the master header only if no fmap is found.
Change-Id: Iafbf2c9dc325597e23a9780b495549b5d912e9ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11629
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On x86, the bootblock can (and will) become part of the regular file
system, so there's no distinct fixed-size region for the bootblock
there.
Change-Id: Ie139215b73e01027bc0586701361e9a0afa9150e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11691
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
$(src) is not defined when building directly from the cbfs directory (that is,
when building cbfs as standalone, running make in the cbfs directory), so we
need to define the path to the commonlib include path relative to $(top).
Change-Id: I72e80b030d4a156ec653ded5ab1457b16f612526
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11706
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
endian.h lives in under sys on the BSDs. Replace htole32() with
swab32(htonl(..)) as a proxy for little endian operations.
Change-Id: I84a88f6882b6c8f14fb089e4b629e916386afe4d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11695
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Since fmap doesn't come with a checksum, we resort to a number of
heuristics to determine if a given location hosts an fmap (instead of
another data structure that happens to store the fmap magic string at
the right location).
The version test is particularly effective against strings containing
the magic (which either terminate with 0, or have some other ASCII data,
but rarely a '\001' byte inside the string).
Change-Id: Ic66eb0015c7ffdfe25e0054b7838445b8ba098e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11690
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The command adds a new cbfs file, fills in the CBFS meta data in cbfs
master header format, then points the master header pointer (which
resides at the last 4 bytes of the CBFS region) to the data area of the
new file.
This can leak some space in CBFS if an old-style CBFS with native master
header gets the treatment, because a new header is created and pointed
at. flashmap based images have no such header, and the attempt to create
a second file with the (hardcoded) name will fail.
Change-Id: I5bc7fbcb5962b35a95261f30f0c93008e760680d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11628
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is more in line with how fmd/fmap specify ranges.
Change-Id: Iecf8250e84d6eb267711ded446909b21147f1a9c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Let's move x86 style bootblocks (and later the others) and the master header
into the CBFS structure. Prepare for this by adding file types.
Change-Id: I1b4149c7f3b8564ee358a2c18ba91e6a7a6797da
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11627
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
fileno() is a mess on some operating systems. Don't
deliberately convert between FILE * and file handles.
Change-Id: I5be62a731f928333ea2e5843d81f541453fdb396
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11636
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
flmstr register bits have slightly different meaning for IFD v2.
BUG=chrome-os-partner:45091, chrome-os-partner:43461
TEST=Run `ifdtool -d image.bin` on IFD v1 locked squawks image:
Found Master Section
FLMSTR1: 0x0a0b0000 (Host CPU/BIOS)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: disabled
Host CPU/BIOS Region Write Access: enabled
Flash Descriptor Write Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: enabled
Intel ME Region Read Access: disabled
Host CPU/BIOS Region Read Access: enabled
Flash Descriptor Read Access: enabled
Requester ID: 0x0000
FLMSTR2: 0x0c0d0000 (Intel ME)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: enabled
Host CPU/BIOS Region Write Access: disabled
Flash Descriptor Write Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: enabled
Intel ME Region Read Access: enabled
Host CPU/BIOS Region Read Access: disabled
Flash Descriptor Read Access: enabled
Requester ID: 0x0000
FLMSTR3: 0x08080118 (GbE)
Platform Data Region Write Access: disabled
GbE Region Write Access: enabled
Intel ME Region Write Access: disabled
Host CPU/BIOS Region Write Access: disabled
Flash Descriptor Write Access: disabled
Platform Data Region Read Access: disabled
GbE Region Read Access: enabled
Intel ME Region Read Access: disabled
Host CPU/BIOS Region Read Access: disabled
Flash Descriptor Read Access: disabled
Requester ID: 0x0118
Then, run `ifdtool -l image.bin` and verify newly locked image is identical.
Next, run `ifdtool -l image.bin` on unlocked glados image. Verify that locked
and unlocked regions are identical to above.
Finally, burn glados image, run `flashrom -V`, and verify ME regions is
locked and descriptor region is RO.
BRANCH=None
Change-Id: I8a65bdc5edd0d888138b88c1189f8badd1404b64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 11c434835a66a50ab2c0c01a084edc96cbe052da
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Change-Id: I875dfce6f5cf57831714702872bfe636f8f953f4
Original-Reviewed-on: https://chromium-review.googlesource.com/298968
Original-Commit-Ready: Shawn N <shawnn@chromium.org>
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no need to maintain two lists of dependencies that need to be
changed every. single. time.
Change-Id: I26bb8c884e98afe74fd9df11464bcf88e130cd92
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11674
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It was added to an unused variable.
Change-Id: I869ffdda7e04b5c615931473c760d66b803fb98b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11673
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The locate command was previously being used for x86 romstage
linking as well as alignment handling of files. The add command
already supports alignment so there's no more users of the
locate command. Remove the command as well as the '-T' (top-aligned)
option.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi. Noted microcode being directly added.
Change-Id: I3b6647bd4cac04a113ab3592f345281fbcd681af
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11671
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of going through the locate then add-stage
dance while linking romstage twice allow for adding romstage
with --xip flags to perform the relocation while adding it
into CBFS. The -P (page-size) and -a (alignment) parameters
were added as well so one could specify the necessary
parameters for x86 romstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Change-Id: I585619886f257e35f00961a1574009a51c28ff2b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11669
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The cbfs_locate_entry() function had a hack in there which
assumed a struct cbfs_stage data was being added in addition
to the struct cbfs_file and name. Move that logic out to the
callers while still maintaining the logic for consistency.
The only impacted commands cbfs_add and cbfs_locate, but
those are using the default 'always adding struct cbfs_stage'
in addition to cbfs_file + name. Eventually those should be
removed when cbfs_locate is removed as cbfs_add has no smarts
related to the cbfs file type provided.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I2771116ea1ff439ea53b8886e1f33e0e637a79d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11668
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to allow cbfstool to add XIP romstage on x86 without
doing the 'cbfstool locate', relink, then 'cbfstool add' dance
expose the core logic and of rmodule including proving an optional
filter. The filter will be used for ignoring relocations to the
.car.global region.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I192ae2e2f2e727d3183d32fd3eef8b64aacd92f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11598
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The core logic of the rmodule parser is ideal for
processing romstage ELF files for XIP. To that
end start the work of exposing the logic from
rmodule so cbfstool can take advantage of it.
The properties that both need require:
- Single program segment
- Relocation information
- Filter relocation processing
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi.
Change-Id: I176d0ae0ae1933cdf6adac67d393ba676198861a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11595
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no need to whine about missing files, so test for them first.
Change-Id: I906fd04a315de70340ce76d7c38eaaf88cc6580a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11642
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We build the coreboot utilities in a separate step as a minor
optimization. When logging in junit format (for jenkins), we want to
have a report on those as well (instead of an xml error).
Change-Id: Ibcd3b02bce9a314c30b5f7414e9e4cf0149ffd6a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11641
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Variable expansion made abuild create board..foo/bar, which are annoying
on jenkins' web UI because it doesn't cope properly with the empty
namespace between the dots. make it create board.foo/bar or
board.$class.foo/bar.
Change-Id: Ifa79cbfd1f263e11a458b3cc320baeed6a3fbc98
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11640
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
We had two mappings of filetype IDs to strings. We shouldn't.
Change-Id: I08e478b92f3316139f14294e50ede657c7d5fb01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11626
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As with most other languages, a pre-installed Ada toolchain is needed
to build gcc's Ada frontend. To support building with older host tool-
chains, the patch `gcc-5.2.0_gnat.patch` disables warnings for unknown
pragmas. Building has been tested with host gcc-4.9 and hopefully works
with newer versions, too.
For convenience, the gnattools (e.g. gnatmake etc.) will be build if
'ada' is specified as a target language.
Change-Id: Ia78c29d1aba2943de5238421a324cfff8eb08875
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add an option `--languages` which takes a list of target languages to
buildgcc. That list gets passed through to the configure step for
building gcc.
Also alter the Makefile to pass $(BUILD_LANGUAGES) to that option, if
this variable is set.
Change-Id: I6a74ab2c75871ea8d03a499cca33d88938b59c8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are currently 2 uses for rmodule programs: stand alone
programs that are separate from the coreboot stages and a
relocatable ramstage. For the ramstage usage there's no reason
to require a rmodule parameter section. Therefore make this
optional.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built ramstage w/ normal linking (w/o a rmodule parameter
section). No error.
Change-Id: I5f8a415e86510be9409a28068e3d3a4d0ba8733e
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11523
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring rmodule linking into the common linking method.
The __rmodule_entry symbol was removed while using
a more common _start symbol. The rmodtool will honor
the entry point found within the ELF header. Add
ENV_RMODULE so that one can distinguish the environment
when generating linker scripts for rmodules. Lastly,
directly use program.ld for the rmodule.ld linker script.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built rambi and analyzed the relocatable ramstage,
sipi_vector, and smm rmodules.
Change-Id: Iaa499eb229d8171272add9ee6d27cff75e7534ac
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11517
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Whenever we want to add a file to CBFS with a specific alignment, we
have to do two cbfstool invocations: one to find a place for the file,
and another to actually add the file to CBFS. Get rid of this nonsense
and allow this to be done in one step.
Change-Id: I526483296b494363f15dc169f163d93a6fc71bb0
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11525
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
According to https://gcc.gnu.org/gcc-4.6/changes.html it's only in gcc 4.6,
not 4.5, which I mistakenly believed.
Change-Id: I8212e7921bd9d1436a0ba491cbe6c4d473228956
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11476
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Tested-by: build bot (Jenkins)
This isn't required for correct execution, and doesn't need to be tested
on every single compiler out there.
Since GCC < 4.5 has no idea about _Static_assert, hide it there. Our
build tests will make sure that the test is run before changes are
submitted to master.
Change-Id: I4141f4aa23b140d2d1017ca7b4dace5aa7db0c04
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11475
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Display compressed and decompressed sizes, as well as the compression
algorithm used, when a compressed file is encountered.
Change-Id: I13c2332702c4a5bec379e1ebda72753e06f8e135
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11359
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, compression is only allowed at subheader level (e.g. cbfs_stage,
cbfs_payload_segment). This change adds compression field to each file's
header so that any cbfs file can be compressed.
With the necessary additions in coreboot and libpayload, the following sample
code can load a compressed file:
const char *name = "foo.bmp";
struct cbfs_file *file = cbfs_get_file(media, name);
void *dst = malloc(ntohl(file->uncompressed_size));
dst = cbfs_get_file_content(media, name, type, file, dst);
cbfs_stage and cbfs_payload_segment continue to support compression at
subheader level because stages and payloads have to be decompressed to the load
address, which is stored in the subheader. For these, file level compression
should be turned off.
Change-Id: I9a00ec99dfc68ffb2771bb4a3cc5ba6ba8a326f4
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10935
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to make analysis easier provide an option (-T) to
print timestamps in a parseable format:
ID<tab>raw timestamp<tab>time from previous entry<tab>description
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and tested on glados. Used the following script:
cbmem -T | awk 'BEGIN { FS="\t" } { tot += $3 } END { print tot }'
Change-Id: I06dc0487d1462b6a78924130f0ad74b0d787d3f8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the timestamp tick frequency within the timestamp table so
the cbmem utility doesn't try to figure it out on its own. Those
paths still exist for x86 systems which don't provide tsc_freq_mhz().
All other non-x86 systems use the monotonic timer which has a 1us
granularity or 1MHz.
One of the main reasons is that Linux is reporting
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq as the true
turbo frequency on turbo enables machines. This change also fixes
the p-state values honored in cpufreq for turbo machines in that
turbo p-pstates were reported as 100MHz greater than nominal.
BUG=chrome-os-partner:44669
BRANCH=firmware-strago-7287.B
TEST=Built and booted on glados. Confirmed table frequency honored.
Change-Id: I763fe2d9a7b01d0ef5556e5abff36032062f5801
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ie3a44c6db9c9c186c52b4743334266ec5411ba8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I9f59a00e735f39df813b2216290da62eea3c595d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11372
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Previously, X4X was incorrectly named because it provides
support for SKUs within XX4X range. This is renamed.
This patch provides support for all X4X SKUs according to
datasheet Intel 4 Series Chipset Family Specification Update,
namely: Q45, Q43, P45, P43, G45, G43, G41 and B43 (both versions).
Tested on Gigabyte GA-G41M-ES2L
Change-Id: I032265e80d9ca51e2fef29201280832ea3210a0b
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: http://review.coreboot.org/11245
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Whatever it is, it likely won't be cros/chromeos-2013.04 anymore.
Change-Id: I020b65a7406e3bef7d1c8fad8c530354b1f78819
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11438
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
This patch adds support to enable a linker workaround to a hardware
erratum on some early Cortex-A53 revisions. Since the linker option was
added very recently, we use xcompile to test whether the toolchain
supports it first. It is also guarded by a Kconfig since only a few
ARM64 SoCs will need this and it incurs a performance penalty.
BRANCH=none
BUG=none
TEST=Turned it on or off for Smaug and confirmed that it (dis)appeared
in verbose make output accordingly.
Change-Id: I01c9642d3cf489134645f0db6f79f1c788ddb00d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 57128785760c4dfa32d6e6d764756443a9323cb7
Original-Change-Id: Ia5dd124f484e38460d75fb864304e7e8b18d16b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/294745
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
We have tons of file types now that can be safely extracted.
It's pretty much only stages and payloads that aren't.
Change-Id: Ibf58a2c721f863d654537850c6f93d68a8a5bbeb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11360
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
My concern was that compilers may something stupid under the assumption
of a fixed struct size, but filename is already variable, so things are
okay.
Change-Id: I5348faf68f0a7993294e9de4c0b6c737278b28af
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11331
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They're passed as part of the header now.
Change-Id: I7cd6296adac1fa72e0708b89c7009552e272f656
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11327
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The header is now created before the "converters" are run.
Adding new capabilities (and fields to the header) will happen there,
so we're close.
Change-Id: I0556df724bd93816b435efff7d931293dbed918f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11326
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These functions can do all kinds of things, such as converting an ELF
image into SELF, or (in the future) compress or checksum entire files.
This may require changing or adding fields to the header, so they
need to have access to it.
The header_size parameter that was provided (but never used) is
equivalent to cbfs_file's offset field.
Change-Id: I7c10ab15f3dff4412461103e9763a1d78b7be7bb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11325
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's sole use was comparing it to the header's "len" field.
Change-Id: Ic3657a709dee0d2b9288373757345a1a56124f37
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11324
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
->len used to be set to the file data length plus the size of the
padding used for the cbfs_file header. This isn't the case anymore,
so no patching of this field is necessary anymore.
->offset still needs to be patched in that case because its final
value can only be determined when the file's actual location is known.
Change-Id: I1037885f81b4ed3b68898dd7d0e515cf7a9c90a8
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11322
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Up to now cbfstool creates the cbfs_file header at the latest possible
time, which is unsuitable when the idea is to add further fields to it
that need to be configured earlier.
Thus, have it ripple up the call chain.
Change-Id: I7c160681c31818bc550ed2098008146043d0ee01
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11320
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
"target", for what? It's the offset where the file header of the currently
added file will be located, name it as such.
Change-Id: I382f08f81991faf660e217566849773d9a7ec227
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11319
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Refactor the code to be better understandable.
Change-Id: Ia815a27f7cc83c226a32e87485d712a5fbf4168e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11318
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In testing other localization changes, I found that I couldn't build
anymore because xcompile wasn't picking up my toolchain. I traced it
to the regex comparison of '.*format \(.[a-z0-9-]*\)' to the string
'formato del fichero elf32-i386'. Forcing the localization of
objdump to C before doing the comparison fixes the issue.
Change-Id: I6bed5a9824807dd5bc5a38b711ab47e2af4b0c29
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11304
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
There doesn't seem to have been an olddefconfig target in the coreboot
version of the Kconfig makefile. It's listed in the .PHONY, but it
doesn't seem like it's ever been there. This is useful for expanding
a miniconfig saved with 'make savedefconfig'.
Change-Id: I3798f8469135b58d32da68d4b0e434ab5351b501
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11273
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some patch implementations (eg. BSD) create new files by taking the "---" file
name instead of the "+++" one, so set both to the file name that is to be
created.
Change-Id: I6f37748b4cf0852d292f8f5156fc27ab8fd481b6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reported-by: Idwer Vollering <vidwer@gmail.com>
Reported-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-on: http://review.coreboot.org/11303
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It still needs to pass --32 (yes, 32) to the assembler.
x86_64-linux does this (through some other config file),
x86_64-elf did not.
This fixes building SeaBIOS with our x86_64-elf multilib compiler.
Change-Id: Ibe2a70e46e64e71c947482be5ec0eaf7f7bf300d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/11289
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
All compilers built, incl. x86_64-elf as multilib and riscv-elf.
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69372
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10975
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The get_region() function was using fixed masks for
the base and limit. However, newer descriptors (on
skylake, e.g.) use a 15-bit mask -- not a 12-bit one.
Choose the right mask based on ifd_version.
BUG=chrome-os-partner:43461
BRANCH=None
TEST=Built glados bootimage.
Original-Change-Id: Ibcbfd649a561d36b17ea2cc8fbeb30ffdbbb2c96
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293250
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I7f2ef9fb8e5b6c7114225fecc2798668d6507ac3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11229
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The descriptor format has changed with Skylake and some fields have
moved or been expanded.
This includes new SPI frequencies and chip densities, though unfortunately
30MHz in the new format conflicts with 50MHz in the old format...
There are also new regions with a few reserved regions inserted before
a new embedded controller region.
Unfortunately there does not seem to be a documented version field
so there does not seem to be an official way to determine if a
specific descriptor is new or old. To work around this ifdtool
checks the hardcoded "SPI Read Frequency" to see if it set for
20MHz (old descriptor) or 17MHz (new descriptor).
BUG=chrome-os-partner:40635
BUG=chrome-os-partner:43461
BRANCH=none
TEST=run ifdtool on skylake and broadwell images
Original-Change-Id: I0561b3c65fcb3e77c0a24be58b01db9b3a36e5a9
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/281001
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9a08c26432e13c4000afc50de9d8473e6f911805
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/293240
Reviewed-on: http://review.coreboot.org/11228
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display the total accumulated time using each timestamp
entry. It purposefully doesn't take into account the first
timestamp because that can be a platform dependent value
that may not contribute to the concept of "total".
BUG=None
BRANCH=None
TEST=Ran cbmem on glados where TSC doesn't reset to 0 on
reboots. Clear total value given at end.
Original-Change-Id: Idddb8b88d3aaad11d72c58b18e8fd9fd1447a30e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291480
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Trybot-Ready: David James <davidjames@chromium.org>
Change-Id: I79a0954d3b738323aaebb3e05171bcf639e5d977
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11202
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After the preparation in earlier commits, it is now possible to handle the
more general case of position independent files using the special code path
for fixed location files.
This leads to a single place where non-empty cbfs file headers are actually
written into the image, allowing us to move it up the chain more easily.
Change-Id: I8c1fca5e4e81c20971b2960c87690e982aa3e274
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11222
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
... and the assert is gone.
The actual action of adding a just-right file can be moved after the tests
since it's exactly the condition those tests don't continue or break on.
Change-Id: I6d0e829e0158198301136ada9a0de2f168ceee3f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11221
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The assert() makes sure the if() holds true. But that assert won't survive for
long.
Change-Id: Iab7d2bc7bfebb3f3b3ce70dc5bd041902e14bd7a
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11220
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We will want to create headers that live outside the final image at some point
(eg. to build the file before we even know where to place it).
Change-Id: Ie4c0323df8d5be955aec3621b75309e8f11fae49
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11219
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Pass the file type into it instead of creating an entry, then modifying the
header field again after the fact.
Change-Id: I655583218f5085035b0f80efff7f91a66b5b296e
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11218
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If an earlier stage built a larger header, cbfs_add_entry_at() shouldn't
decide to go with the most boring, least featureful header type (and its size)
instead.
Change-Id: Icc5dcd9a797a0f3c42f91cddd21b3b3916095b63
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11217
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The idea is that they can at some point add extended attributes to the header.
That also needs to be passed, but let's start simple.
Change-Id: I80359843078b149ac433ee3d739ea192592e16e7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11216
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It will at some point create the header, and pass it with its size. We can
start with the size already.
Change-Id: I8f26b2335ffab99a664d1ff7bc88e33ed62cf9ca
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11215
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Headers vary in size soon, and more places need to be able to calculate their
size.
Change-Id: I30761bb9da0756418993dee21d8fa18cf3174c40
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11214
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is in preparation of creating the cbfs_file header much earlier
in the process. For now, size is enough because lots of things need to
move before it makes sense to deal with cbfs_file at a higher level.
Change-Id: I47589247c3011cb828170eaa10ef4a1e0f85ab84
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No need to read the file before bailing out.
Change-Id: Ida7226c6ec227e1105724cdb1e5a0927217a69c7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11212
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is a generic structure, not unlike the cbtables design, based on which we
can build specialized TLV data structures.
Change-Id: I98a75eef19f049ad67d46cdc2790949dcd155797
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10937
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Vladimir Serbinenko