It's useless and makes clang unhappy.
Change-Id: If256b99aebabd87df30a3a078c5804330b82989b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4713
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The unusual construction ls + grep + while read fails
for unknown reason. Use standard for x in * consruction
instead.
Change-Id: Ibcdf5e18543587f71a605bae2d0df72b6a286a5b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4757
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On bot, stderr is unmonitored, so it make no sense to stop with an error.
Instead use some sensible guesses.
Change-Id: I6292e9fbf446b751471b95f86e7515c6680bddf3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4748
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Up until now, we relied on mksunxiboot to prepend the header which
makes coreboot.rom bootable on Allwinner SoCs. If that tool was not
present, the build silently failed.
Integrate this tool into our util/ package, so that we do not have to
rely on mksunxiboot being in PATH.
Our version of mksunxiboot also eliminates some limitations of the
original tool, so we no longer have to use 'dd' to limit the file
size.
Change-Id: Id5a4b1e2a3cb00cd1d6c70e6cbc3cfd8587e8a24
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4656
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The rule has the target `junit.xml` and runs `make clean` and `make` and
logs the result in the file `junit.xml` suitable for consumption by
Jenkins.
Change-Id: I42a31f6c7a45fa9c3773969d78f745fcc4e09dbd
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4611
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This should probably propagate to the other lint checks.
The idea: only enforce style on files that were at least touched
by the developer.
Change-Id: I5ac690ee726e27e80e790fa9a41cd14b84ad2161
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4644
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The last few days of the year might belong to the first
week of the new year in the ISO week numbering scheme.
GNU date accounts for that with different-than-usual
notation.
Change-Id: I8047c197971077a845d6c1fdc9da6eb9f3741539
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4610
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
cleanup() uses BUILDDIRPREFIX, which is set after the
getopt loop.
Change-Id: I8a904781ee4fefc42681d31e94b64008cf03750a
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4544
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Make abuild -r work in more sitations (eg. xargs parallelization),
and make it not break junit output.
Also tell Kconfig to just overwrite the config file, instead of
atomically updating it, which help if coreboot-builds is on a
different filesystem (eg. tmpfs).
Change-Id: I2f4eedfd34ea6771732a60b38f1856056089be23
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4542
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Change-Id: I9791beff44535a0a130292414fcd9875b497b1ca
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4492
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
During the update_fit step, 'file_length' is used to determine how many
bytes are left in the CBFS file. It was decremented in a loop from an
array 'mcus[num_mcus].size', but 'num_mcus' was incremented right before.
Since 'mcus' is memset(0) externally, 'file_length' was never decremented.
The loop exited when it reached a dummy terminator, usually 48 bytes of 0
which are internationally added to microcode blobs in coreboot. However,
if that terminator is removed, the loop doesn't stop and continues until
it segfaults.
Change-Id: I840727add69379ffef75b694d90402ed89769e3b
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4508
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
If the unpacking was interrupt by Ctrl-C, probably part of
an archive is unpacked. If we run buildgcc again, the
incomplete folder would be and skipped.
We can create a file to tell the script the unpacking is done.
Change-Id: Id9eb74d119e22b62c70dca9b38a92c3dbdf0f64c
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Make boards take less vertical space, and link to board pages
Change-Id: Ifdd062a15191809b75422416c874161d9114363d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4493
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
These were terribly under-documented
Change-Id: I285ea083110d87076281e81065f5f38d0c688358
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4491
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We use junit style output these days.
Change-Id: I4110ec10bf0e9f4354ee08e7e1c5a81ae605fee0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4484
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
USE_XARGS mode builds n boards in parallel (with 1 CPU each) instead of
building 1 board with n CPUs.
This requires the main build system to work under such circumstances.
Change-Id: Ib4571a78dfe78fd61ae5b26c18be9745bd8b3d52
Reviewed-on: http://review.coreboot.org/4485
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This makes USE_XARGS-abuild unhappy due to races
Change-Id: I1237468366c7f8af7eacd572c2bd32df9a3d58ca
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4486
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The numbers alone are hard to parse, so add
some timestamp names to make it easier to read.
Change-Id: Ie32d3e7ca759bd15e7c160bdd829dec19943e6cb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65333
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4314
Tested-by: build bot (Jenkins)
On ARM the timestamps are already in micro seconds, so
no need to convert them.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If7363b0703e144bde62d9dab4ba845e1ace5bd18
Reviewed-on: https://gerrit.chromium.org/gerrit/63991
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4313
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's a start...
Change-Id: Ibdb0b64ab0349df58bcad5ce553bf0dbec636925
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4483
Tested-by: build bot (Jenkins)
This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.
Change-Id: I244955394c6a2199acf7af78ae4b8b0a6f3bfe33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62287
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4312
Tested-by: build bot (Jenkins)
on ARM the CBMEM utility requires the procfs entry
/proc/device-tree/firmware/coreboot/coreboot-table
provided by the FDT (dynamically created by depthcharge
at the moment)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4311
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The update-fit command takes in a parameter for number of slots
in the FIT table. It then processes the microcobe blob in cbfs
adding those entries to the FIT table. However, the tracking of
the number of mircocode updates was incremented before validating
the update. Therefore, move the sanity checking before an increment
of the number of updates.
Change-Id: Ie8290f53316b251e500b88829fdcf9b5735c1b0e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50319
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4161
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Commit b8ad224 changed the memory address in lb_cbmem_ref coreboot
table entries from a pointer to a uint64_t. This change was introduced
to make the cbmem utility work on both 32bit and 64bit userland.
Unfortunately, this broke the cbmem utility running on older versions
of coreboot because they were still providing a 32bit only field for
the address while the cbmem utility would now take the following 4
bytes as upper 32bits of a pointer that can obviously not be
mmapped. This change checks if the size of the lb_cbmem_ref structure
provided by coreboot is smaller than expected, and if so, ignore the
upper 32bit of the address read.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: If4c8e9b72b2a38c961c11d7071b728e61e5f1d18
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The field wasn't initialized in RAM first and later overwritten in a somewhat
twisted way (that relied on the size field coming after the tag field in the
struct).
Change-Id: Ibe931b297df51e3c46ae163e059338781f5a27e2
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4087
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This moves an ugly comment closer to where it is applicable and also
adds a visual break between the commands which gather data and the
part of the script that finishes up. I'm usually not fan of banner
comments, but it seemed to help in my totally subjective opinion.
I was thinking about how to break the part that uploads results into
a separate function, but there are enough variables that are re-used
from earlier parts that the tradeoff probably isn't worth it.
Change-Id: If888329911c4de3b907cdf5973695c707bbb02fe
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4051
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This allows the command wrappers to delete files if the command
fails. In particular, it delets empty or otherwise useless files
that are generated if a non-fatal command fails.
Change-Id: If26d7b4d7500f160edd1cc2a8b6218792fefae8b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4050
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds cmd_nonfatal() for commands which are considered
non-essential and can be expected to fail safely. This can be used,
for example, to gather data that is generated when using non-standard
utilities or coreboot config options.
Change-Id: Ie43944d2eb73f9aae1c30c3a204cfc413e11d286
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4049
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is really only a cosmetic change, but is intended to make it
slightly easier to remember to update the help menu whenever
options change.
Change-Id: I58b5012309229d08da138a01c7cd1c5096423179
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4048
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Clobbering output is only really useful when debugging the script.
Since we're only using short options, let's save 'c' for something
more important.
Change-Id: If87a70fdc0cd006818d1736c40f9984dfec663a9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4047
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is the first major re-work for the board status script.
Summary:
- Added a command to the getrevision.sh script to retrieve tagged
revision.
- Results are placed in a dynamically generated temporary location.
This makes it easy to do multiple trial runs and avoids polluting
the coreboot directory.
- Results are stored in a directory with the following form:
<vendor>/<mainboard>/<tagged_revision>/<timestamp>/
Vendor and mainboard are obtained from CONFIG_MAINBOARD_DIR so that
hierarchy is consistent between coreboot and board-status.
- The results directory is used as the commit message.
- board-status repository is checked out automatically if results are
to be uploaded.
TODO:
- Add ability to run commands which may fail. Currently we assume
any failure should terminate the script, but some commands can be
made optional.
Successfully uploaded first result to board-status repository. See
http://review.coreboot.org/gitweb?p=board-status.git;a=summary .
Change-Id: Icba41ccad4e6e6ee829b8092a2459c2d72a3365b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4039
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Arrays are indexed 0..(number_of_element-1).
Change-Id: I2157e74340568636d588113d1d2d8cae50082da2
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4089
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This just moves stuff to be more clear about the purpose of
the script. Other suggestions are welcome.
Change-Id: Ic6095fd4eb347daa5a03eff21b5952d2d42a6bfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4038
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The tools for aarch64 on ubuntu are called
aarch64-linux-gnu-*
The type is
elf64-littleaarch64
This now finds the right files for building on aarch64
This has only been tested on ubuntu saucy; the aarch64 toolchain
is in a very ill-defined state on most distros.
Change-Id: Ic1bbd40f0d72384d6e80287b850686292a252918
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: http://review.coreboot.org/4035
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The whitespaces make "git commit" failed.
lint-stable-003-whitespace
Check for superfluous whitespace in the tree
========
test failed:
File util/status/status.sh has lines ending with whitespace.
========
Change-Id: I52fc5ae3e5aa81dac098b36d2479e4d10325a09b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4032
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This reports relevant bits of information about a machine which is
running coreboot. This also includes a script to get revision info
from git, which we may want to split out into another patch.
A remote target can be specified since it is likely that the machine
used to develop the code is not the same machine being developed for.
The remote host must be set up for non-interactive root login.
Example: sh util/status/status.sh -r gizmoboard -u
Change-Id: Ief0a85faca2ec9ce2d270e1e5b09e74836ab0c97
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4021
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some editors like gedit create auxiliary files ending with a
tilde '~'. As these are not checked into the Git repository, do
not check these for whitespace errors.
Change-Id: I2c4cf00f9d623be73ea3bbb7b2da4f1e1900c8e9
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3952
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
SeaBIOS’ Makefile requires cpp (C Preprocessor) to build. Modify
the xcompile script to search for cpp program path, and pass it to
SeaBIOS’ `Makefile.inc`. Also pass the program path for as (GNU assembler).
This is needed, so the crossgcc toolchain to build the SeaBIOS payload
under Mac OSX. OSX ships a cpp program, but it works differently
from GNU CPP, so we need to override it.
Change-Id: If996ffbb76ec4bd16079b54b41f3fac07bfe25be
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3896
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
`util/lint/lint-stable-002-build-dir-handling` always overwrites your
current `config.h` and `auto.conf` when the pre-commit hook is run. It
can be very confusing when your configuration is suddenly broken. So fix
it by not using the default build directory.
Change-Id: If2bbc97ac2f12a8203a3769d813386a023f93dd6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3593
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
gcc 4.8.x has issues with using ebp, which broke some builds,
so downgrade. The problem also manifested elsewhere, so it's
not necessarily our fault.
While at it, gcc complained about "armv7a" where it seems to
expect "armv7-a".
Change-Id: I6f0c35f49709cb41022475bb47116c12ab1c7ee3
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3930
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This simplifies debugging and also fixes an issue when build directories
are kept between buildgcc runs for different architectures.
Change-Id: I5badccd3368e3014680da3eedb607119fff8fa7f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3929
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Clean whitespace errors that have gotten past lint-stable-003-whitespace
and gerrit review.
Change-Id: Id76fc68e9d32d1b2b672d519b75cdc80cc4f1ad9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3920
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The rule "-perm +111 -prune" matched any searchable directory
and did not recursively find files in them. The use of "+mode"
for -perm is deprecated.
Change-Id: I1b43f89ee9ab37928e56104b0f07241ff84b84c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3921
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It wasn't even hooked up to the build system anymore.
Change-Id: I4b962ffd945b39451e19da3ec2f7b8e0eecf2e53
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3892
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
In the great tradition of LinuxBIOS this allows adding
a kernel as payload. add-payload is extended to also
allow adding an initial ramdisk (-I filename) and a
command line (-C console=ttyS0).
Change-Id: Iaca499a98b0adf0134e78d6bf020b6531a626aaa
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3302
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
acpica-unix-20130626 doesn't use bin32 and bin64 to save the objects
any more.
Change-Id: I419ecc987e2adcd860a8ad1bf2f6b5c4dd40fd8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/3885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This simplifies storing SeaBIOS parameters in CBFS.
Change-Id: I301644ba0d7a9cb5917c37a3b4ceddfa59e34e77
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3733
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The raw CPUID is useful for matching the directories under 'src/cpu/intel'
and is not easy to find out otherwise because it is most often decoded
already. The decoded values are not obviously hexadecimal so prepend
them with 0x to make sure they are unambiguous.
The output differences look like this:
- CPU: Processor Type: 0, Family 6, Model 25, Stepping 2
+ CPU: ID 0x20652, Processor Type 0x0, Family 0x6, Model 0x25, Stepping 0x2
Change-Id: Id47f0b00f8db931f0000451c8f63ac1e966442c4
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3788
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Tested-by: build bot (Jenkins)
This is a trivial patch moving cpuid() call after reading argv
so that verbose is set.
Change-Id: Ic621191ef650495614a041413c1a0f707d4469e6
Signed-off-by: Benoît Legat <benoit.legat@gmail.com>
Reviewed-on: http://review.coreboot.org/3627
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The .dependencies rule did not use the CPPFLAGS variable which led
to funny behavior: a spurious termination message the first time
(after checkout/make distclean) one executes make. Afterwards the
(wrongly) empty .dependencies file hides the problem and the binary
is created anyway.
$ make
cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory
compilation terminated.
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
$ make
make: Nothing to be done for `all'.
$ make clean
rm -f cbmem *.o *~
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
$ make distclean
rm -f cbmem *.o *~
rm -f .dependencies
$ make
cbmem.c:37:34: fatal error: boot/coreboot_tables.h: No such file or directory
compilation terminated.
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cc cbmem.o -o cbmem
I fixed that by adding the CPPFLAGS variable to the .dependencies recipe, just
like Stefan Reinauer did in Chromium (Ia9d2e10a3ef122f30d681d16c2291eb108ead835),
hence the split sign-off for this tiny change. :)
Change-Id: Icd11b146ad762cbdf9774630b950f70e1253a072
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3548
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
abuild checks the path for toolchains prior to building a
mainboard. It didn't check xgcc/, which would be picked up
by the coreboot make, and fail to build when it shouldn't.
Change-Id: If0ca4238e8c57a6b015fdad623ccdbf237ef1ba6
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/3350
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This new tool called `ifdfake` just creates an empty Intel Firmware
Descriptor (IFD) and writes the IFD signature plus the section layout
given on the command line.
usage: ifdfake [(-b|-m|-g|-p) <start>:<end>]... <output file>
-b | --bios <start>:<end> BIOS region
-m | --me <start>:<end> Intel ME region
-g | --gbe <start>:<end> Gigabit Ethernet region
-p | --platform <start>:<end> Platform Data region
-h | --help print this help
<start> and <end> bounds are given in Bytes, the <end> bound is inclusive.
All regions must be multiples of 4K in size and 4K aligned.
The descriptor region always resides in the first 4K.
An IFD created with ifdfake won't work as a replacement for a real IFD.
Never try to flash such an IFD to your board!
The output of ifdfake can be utilized to build an image with just the
later added sections (like coreboot itself) being valid. The resulting
image can then be partially written to a machines flash ROM to just
update coreboot (i.e. the BIOS section).
Change-Id: I925b47cab5c6d490a79d684bdd7a7a45ac442640
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3523
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are no files to build left under AMD nortbridge/x/root_complex
directories. For some cases, even the Kconfig file was no longer sourced.
Remove all such references and empty files.
For devicetree.cb treat component paths with "/root_complex" in them valid
even when the directory does not exists. This is because AMD boards us this
dummy chip component as the root node in their devicetree.cb.
The generated devicetree file static.c remains unchanged.
Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/3434
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Also, add pretty printing of Westmere's DMI registers (tested on my t410s
by staring at non-zero output values :)
Apparently Nehalem does not have a MEMBAR? But there are some
documented memory controller control registers in PCI configuration
space... left out for now.
The PCIEXBAR is not documented publicly AFAICT, but there is
a similar register on a device on bus 0xFF. phcoder might know more...
Change-Id: I5faadb6e4f701728f5290276c02809b4993bd86d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3505
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
e4e8e090fa does add support for QM57,
but there are many more that should work with that code(?).
Does not explode on...
CPU: Processor Type: 0, Family 6, Model 25, Stepping 2
Northbridge: 8086:0044 (1st generation (Westmere family) Core Processor)
Southbridge: 8086:3b0f (QS57)
Change-Id: I85e15ba45678a5bd635415a7a8d69c05bff8f7ef
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3321
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This is spkmodem receiver counterpart.
Change-Id: Id27d32608502029fb6fcc8154f508811bf5ca77b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3411
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
While some of the case .. break statement actually weren't needed,
too are, since otherwise the option parsing loop hangs.
Exit conditions for that endless loop: "--" or no more arguments,
in line with GNU command line parsing rules.
Change-Id: I0dbc35e530fb8c93a0f7de05ac47f325555ad4a4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3418
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Added support for Intel Atom cpu to msrtool
Fixed a cut&paste error in nehalem msr bits definition
It has been tested with a N455 cpu and msrtool output can be review at:
http://www.trillion01.com/coreboot/msrtool_atom.txt
Change-Id: I0ecf455b559185e2d16fa1a655bf021efc2ef537
Signed-off-by: Olivier Langlois <olivier@olivierlanglois.net>
Reviewed-on: http://review.coreboot.org/3351
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
viatool is a utility for extracting useful for extracting certain configuration
bits on VIA chipsets and CPUs. It is a fork of inteltool.
viatool is currently focused on "quirks". Quirks are device configurations that
cannot be accessed directly. They are implemented as hierarchical configurations
in the PCI or memory address spaces (index/data register pairs). Such
configurations refer to hardware parameters that are board specific. Those
parameters would otherwise be difficult to extract from a system running the
vendor's firmware.
viatool also preserves inteltool's MSR dumps. VIA CPU and Intel CPU MSRs are
nearly identical.
Change-Id: Icbd39eaf7c7da5568732d77dbf2aed135f835754
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1430
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Bash case statements are terminated with ';;'.
Unlike C, bash case statements will not continue to the next case. No 'break' is needed.
Change-Id: I62e7e91f3223ac4052728a1ca12a4681af0dc036
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3330
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use PRIx64 to print a u64 instead of "llx". Fixes the following error:
cbmem.c: In function 'parse_cbtable':
cbmem.c:135:2: error: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type 'u64' [-Werror=format=]
Change-Id: Ibc2bf8597cb86db5b2e71fba77ec837a08c5e3d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3301
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
buildgcc has many wrong choices, and two right ones,
but you would never guess that. It's even more
frustrating when it spends lots of time building a
full tool chain and you find out it's not the one you
wanted and, still worse, you've forgotten what it does want
and, even worse, it won't f-ing tell you what the two
right choices are!.
Have it tell you when you've done something wrong, and have it
make reasonable decisions when you say things like
-p arm
instead of
-p armv7a-eabi
This change lowers my blood pressure 10 points.
Change-Id: I44a59d7cb7a6260894d8bcb692a693ed25681ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3292
Tested-by: build bot (Jenkins)
Properly check the dependency of choices as a group.
Also fix that sym_check_deps() correctly terminates the dependency loop
error check (otherwise it would continue printing the dependency chain).
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: I0c98760dd0f55cf2ff70c53e0b014288b59574c8
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3290
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Fix reversal of dlg.border.atr and dlg.dialog.atr for draw_box()
Makes the inputbox look like expected
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: I596915aab0204ef0e392fefa56fad8e25204e207
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3289
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
Change-Id: If0f00d1783907d606220cda5307b8960d3bfc38d
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3291
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
right now this is just a fake option to get rid of ifdefs in
coreboot's code.
Change-Id: I59233f3c1d266b4e716a5921e9db298c7f96751d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3225
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This option has never had much if any use. It solved a problem over 10
years ago that resulted from an argument over the value or lack thereof
of including all the debug strings in a coreboot image. The answer is
in: it's a good idea to maintain the capability to print all messages,
for many reasons.
This option is also misleading people, as in a recent discussion, to
believe that log messges are controlled at build time in a way they are
not. For the record, from this day forward, we can print messages at all
log levels and the default log level is set at boot time, as directed by
DEFAULT_CONSOLE_LOGLEVEL. You can set the default to 0 at build time and
if you are having trouble override it in CMOS and get more messages.
Besides, a quick glance shows it's always set to max (9 in this case) in
the very few cases (1) in which it is set.
Change-Id: I60c4cdaf4dcd318b841a6d6c70546417c5626f21
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3188
Tested-by: build bot (Jenkins)
We write CMOS data to 128 byte files, which is a problem
when using them later-on (eg. as part of a coreboot image)
where nvramtool assumes them to be 256 byte, and so data
corruption occurs.
Change-Id: Ibc919c95f6d522866b21fd313ceb023e73d09fb9
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3186
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update crossgcc to use gcc 4.7.3
The resulting coreboot.rom is not runtime tested (any volunteers?).
Drop the texinfo patch, rename the armv7a patch.
Some Linux distributions have moved on to gcc 4.8,
under certain circumstances this version can't (cross-)compile gcc 4.7.2
Bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56927
Change-Id: Id8ce5f86c34e1a0900d44dc6ae4e81cb9548ecc2
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3112
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
cbmem currently fails to build due to `-Werror` and the following
warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
cbmem.c: In function ‘map_memory’:
cbmem.c:87:2: error: format ‘%zx’ expects argument of type ‘size_t’, but argument 2 has type ‘off_t’ [-Werror=format]
[…]
Casting the argument of type `off_t` to `intmax_t` and using the
length modifier `j`
$ man 3 printf
[…]
j A following integer conversion corresponds to an intmax_t or uintmax_t argument.
[…]
instead of `z` as suggested in [1] and confirmed by stefanct and
segher in #coreboot on <irc.freenode.net>, gets rid of this warning
and should work an 32-bit and 64-bit systems, as an `off_t` fits
into `intmax_t`.
[1] http://www.pixelbeat.org/programming/gcc/int_types/
Change-Id: I1360abbc47aa1662e1edfbe337cf7911695c532f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3083
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building inteltool with Clang, it warns about the following.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ CC=clang make
[…]
clang -O2 -g -Wall -W -c -o pcie.o pcie.c
pcie.c:297:40: warning: signed shift result (0xFF0000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0xff << 28);
~~~~ ^ ~~
pcie.c:301:41: warning: signed shift result (0xFF8000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0x1ff << 27);
~~~~~ ^ ~~
pcie.c:305:41: warning: signed shift result (0xFFC000000) requires 37 bits to represent, but 'int' only has 32 bits [-Wshift-overflow]
pciexbar_phys = pciexbar_reg & (0x3ff << 26);
~~~~~ ^ ~~
3 warnings generated.
[…]
Specifying the length by using the suffix `0xffULL` fixes these issues
as now enough bits are available.
These issues were introduced in commit 1162f25a [1].
commit 1162f25a49
Author: Stefan Reinauer <stepan@coresystems.de>
Date: Thu Dec 4 15:18:20 2008 +0000
Patch to util/inteltool:
* PMBASE dumping now knows the registers.
* Add support for i965, i975, ICH8M
* Add support for Darwin OS using DirectIO
[1] http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=1162f25a49e8f39822123d664cda10fef466b351
Change-Id: I7b9a15b04ef3bcae64e06266667597d0f9f07b79
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3015
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Now users can use a different compiler from GCC like Clang by for example
doing `CC=clang make`.
Change-Id: I664a36df79f7496a56d89bdb61948b2eda33a6b4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3082
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In [1] Idwer Vollering noted, that the type `u64` is not portable so
on his FreeBSD system, the following warning is shown.
$ clang -O2 -Wall -W -I/usr/local/include -c -o amb.o amb.c
amb.c:441:22: error: use of undeclared identifier 'u64'
ambconfig_phys = ((u64)pci_read_long(dev16, 0x4c) << 32) |
The type `uint64_t` seems to be defined also on FreeBSD, so using this
fixes the warning.
Note, this warning is not reproducable with Debian Sid/unstable for
example. I have no idea why though.
[1] http://review.coreboot.org/#/c/3015/
Change-Id: Ic22f4371114b68ae8221d84a01fef6888d43f365
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3086
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Currently on a 32-bit system cbmem fails to build due to `-Werror`
and the following warning.
$ make
cc -O2 -Wall -Werror -iquote ../../src/include -iquote ../../src/src/arch/x86 -c -o cbmem.o cbmem.c
[…]
cbmem.c: In function ‘parse_cbtable’:
cbmem.c:135:2: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘u64’ [-Werror=format]
cc1: all warnings being treated as errors
[…]
Using the length modifier `ll` instead of `l` gets rid of this
warning.
Change-Id: Ib2656e27594c7aaa687aa84bf07042933f840e46
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3084
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Cppcheck warns about a memory leak, present since adding romtool,
which was renamed to cbfstool, in commit 5d01ec0f.
$ cppcheck --version
Cppcheck 1.59
[…]
[cbfs-mkstage.c:170]: (error) Memory leak: buffer
[…]
Indeed the memory pointed to by `buffer` is not freed on the error path,
so add `free(buffer)` to fix this.
Change-Id: I6cbf82479027747c800c5fe847f20b779e261ef4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3069
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The URL to acpica-unix-20121114 has changed, update the URL.
Change-Id: I1c8c228094f19455af3682f36f1990586fe3934c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3070
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Current code outputs the whole cbmemc buffer even if only part of
it is really used. Fix it to output only the used part and notify
the user if the buffer was too small for the required data.
Change-Id: I68c1970cf84d49b2d7d6007dae0679d7a7a0cb99
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/2991
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:
commit aa3f7ba36e
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.
Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Patrick Georgi