Note: This patch was backported from the master branch and it was
modified so that it can be applied on the 1.1.x branch.
`ich_hwseq_wait_for_cycle_complete()` drops taking `timeout` as argument
in favor of a fixed timeout of `30 seconds` for any given SPI operation
as recommended by the SPI programming guide.
Document: Alder Lake-P Client Platform SPI Programming Guide
Rev 1.30 (supporting document for multi-master accessing the
SPI Flash device.)
Refer to below section to understand the problem in more detail and SPI
operation timeout recommendation from Intel in multi-master
scenarios.
On Intel Chipsets that support multi-mastering access of the SPI flash
may run into a timeout failure when the operation initiated from a
single master just follows the SPI operational timeout recommendation
as per the vendor datasheet (example: winbond spiflash W25Q256JV-DTR
specification, table 9.7).
In the multi-master SPI accessing scenario using hardware sequencing
operation, it's impossible to know the actual status of the SPI bus
prior to individual master starting the operation (SPI Cycle In Progress
a.k.a SCIP bit represents the status of SPI operation on individual
master).
Thus, any SPI operation triggered in multi-master environment might need
to account a worst case scenario where the most time consuming operation
might have occupied the SPI bus from a master and an operation initiated
by another master just timed out.
Here is the timeout calculation for any hardware sequencing operation:
Worst Case Operational Delay =
(Maximum Time consumed by a SPI operation + Any marginal
adjustment)
Timeout Recommendation for Hardware Sequencing Operation =
((Worst Case Operational Delay) * (#No. Of SPI Master - 1) +
Current Operational latency)
Assume, on Intel platform with 6 SPI master like, Host CPU, CSE, EC,
GbE and other reserved etc, hence, the Timeout Calculation for SPI
erase Operation would look like as below:
Maximum Time consumed by a SPI Operation = 5 seconds
Worst Case Operational Delay = 5 seconds
Timeout Recommendation for Hardware Seq Operation =
5 seconds * (6 - 1) + 5 seconds = 30 seconds
BUG=b:223630977
TEST=Able to perform read/write/erase operation on PCH 600 series
chipset (board name: Brya).
Original-Signed-off-by: Subrata Banik <subratabanik@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/62867
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Change-Id: Ifa910dea794175d8ee2ad277549e5a0d69cba45b
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68690
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Note: This patch was backported from the master branch and it was
modified so that it can be applied on the 1.1.x branch.
The developerbox_spi programmer depends on bitbang SPI support. Thus,
fix that.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ic0fe589ffdccede0fbf6360c2bebe58a36654f10
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66096
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68011
The flashrom project no longer uses freenode. To avoid having outdated
man pages in the future, the contact methods are now listed in the wiki.
Change-Id: I75e8f43c50dc4c3feede0250334a877cdaac8103
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68061
As discovered earlier[1], the `vendor_id` and `device_id` fields are not
always automatically set. However, we use these fields throughout flash-
rom. To not lose track when we actually fetched them, let's always call
pci_fill_info(PCI_FILL_IDENT) before returning a `pci_dev` handle.
[1] Commit ca2e3bce0 (pcidev.c: populate IDs with pci_fill_info())
Backported to older versions where pcidev handling was much more
scattered.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iae2511178bec44343cbe902722fdca9eda036059
Ticket: https://ticket.coreboot.org/issues/367
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64573
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67859
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
With pciutils 3.7.0, flashrom is unable to match any PCI devices by
vendor/device ID because the vendor_id and device_id fields of struct
pci_dev are not filled in.
Call pci_fill_info() to request these identifiers before trying to match
them against the supported device list.
The pciutils ChangeLog for 3.7.0 mentions that the documentation and
back-end behavior for pci_fill_info() was updated; it seems that a call
to pci_fill_info() was always intended to be required, but some backends
(such as the sysfs one used on Linux) would fill the identifier fields
even when not requested by the user. The pci_fill_info() function and
the PCI_FILL_IDENT flag have been available for all versions of pciutils
since at least 2.0 from 1999, so it should be safe to add without any
version checks.
With this change, reading/writing a nicintel_spi boot ROM is successful.
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Change-Id: Ia011d4d801f8a54160e45a70b14b740e6dcc00ef
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46310
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67858
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Make the linux_mtd driver treat any negative return value from the
MEMERASE ioctl as an error. Previously it only treated -1 as an error.
BUG=b:213561594,b:210973586,b:182223106
BRANCH=none
TEST=builds
Change-Id: I40cfbdee2ab608fbe6c17d9cac6ec53ff224d9a4
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67857
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The maximum transfer size is too large for some devices and
results in an USB timeout.
Change-Id: If2c00b1524ec56740bdfe290096c3546cf375d73
Signed-off-by: Marc Schink <dev@zapb.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67855
Reviewed-by: Felix Singer <felixsinger@posteo.net>
We open the device node for the MTD device with this:
dev_fp = fopen(dev_path, "r+")
In C fopen() is allowed to provide _buffered_ access to the file.
That means that the standard library is allowed to read ahead and/or
return cached data. That's really not what we want for something like
this. Let's turn it off.
This fixes a problem where flashrom would sometimes fail to "verify"
that it erased the flash. The error message would look something like
this:
Erasing and writing flash chip... FAILED at 0x0000e220! Expected=0xff, Found=0xe9, failed byte count from 0x0000e200-0x0000e2ff: 0xdc
failed byte count from 0x0000e000-0x0000efff: 0xffffffff
ERASE_FAILED
FAILED!
Uh oh. Erase/write failed. Checking if anything changed.
After the failure I could read the flash device with a new invocation
of flashrom and I would see that, indeed, the erase had worked.
Tracing in the kernel showed that when the failure happened we saw a
pattern that looked like this:
* Read 0x0b00 bytes starting at 0x0000d000
* Read 0x1000 bytes starting at 0x0000db00
* Erase 0x1000 bytes starting at 0x0000e000
...and then there was _not_ a read after the erase. It can be assumed
that, since userspace had already read 0xdb00 - 0xeaff that it was
looking at old buffered data after the erase.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Change-Id: I989afd83a33013b2756a0090d6b08245613215c6
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50155
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67854
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Port from the ChromiumOS fork of flashrom.
Change-Id: I8075fe5f80ac0da5280d2f0de6829ed3a2496476
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67852
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The memory for the `param` string is aliased by `dualbiosindex_suffix`.
Moreover, `errno` could have been modified by the call to `free()`.
Therefore, only free the former when there are no more uses of either.
Change-Id: I79f18f6077c77c0cbb8bfa431e17f9b079f11c95
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46551
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67851
Reviewed-by: Felix Singer <felixsinger@posteo.net>
When hardware write protect is applied, flashrom crashed and
generate coredump. spi_disable_blockprotect_generic() calls
flash->chip->printlock() method when disable was failed,
but this method is optional, can be NULL depends on type of
flashrom chip. NULL pointer check before call is added to
avoid crash.
BRANCH=none
BUG=b:129083894
TEST=Run on Mistral P2
(On CR50 console, run "wp disable")
flashrom --wp-range 0 0x400000
flashrom --wp-enable
(On CR50 console, run "wp enable")
flashrom -r /tmp/test.bin
Verify "Block protection could not be disabled!" is shown,
but flash read completes.
Signed-off-by: Yuji Sasaki <sasakiy@chromium.org>
Change-Id: I81094ab5f16a85871fc9869a2e285eddbbbdec4e
Reviewed-on: https://chromium-review.googlesource.com/1535140
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: SANTHOSH JANARDHANA HASSAN <sahassan@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40468
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67850
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Print an error message and return if the read from emu_persistent_image
fails.
Change-Id: Icd1a72f9171e547f2081ba4bc53834a17ef7fcab
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1403912
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67849
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Since fread() returns the number of bytes read, this currently will only
check for errors if it returns 0 (i.e. the file was empty). However, it
is possible for fread() to encounter an error after reading a few bytes,
which this doesn't catch. Fix this by using fgets() instead, which will
return NULL if EOF or an error is encountered, and is simpler anyway.
Change-Id: I4f37c70e97149b87c6344e63a57d11ddde7638c4
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 1403824
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34848
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67848
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The N25Q is a stacked device, so it requires 0xC4 to perform a die
erase.
Signed-off-by: Jacob Creedon <jcreedon@google.com>
Change-Id: Ib408fbe5633abd8b657e3907142b997e88b33f84
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67847
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We never read the first 'ret'. Let's check the first 'ret'
and exit if it failed.
Also, print the version only when the command succeeded.
Backported to libusb-v0 version (checking for CMD_LENGTH
instead of 0 return value).
Found-by: scan-build 7.0.1-8
Change-Id: I4aac5e1f3bd0604b079e1fdd9b7f09f1f4fc2d7f
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34403
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
For the physmap*() functions, NULL is considered valid return value.
Fixes a segmentation fault when DMI tables can't be mapped.
Tested on intel/eblake board with broken coreboot.
Change-Id: Ic403c2940c2b91acbd113f0acfa3ce9ef6c6bb6c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62613
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
All these variables are only used in the files they are defined in, so
they can be made static.
(Backported as it untangles aliased global objects.)
Change-Id: I1e55138adef540e9d3a2237aa5b289cb338c0608
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33747
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62612
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Instead of hard coding the test procedure on qa.coreboot.org, allow
running a script in the repo instead. The server is already adapted
to do that, so once there's a test_build.sh file in the toplevel
directory, it's run in place of the default operation.
The content of this change mirrors the default operation exactly so
should serve as a good starting point.
The script is executed in an encapsulate[0] context with the workspace,
/tmp and $HOME/.ccache writable, everything else read-only and
network disabled.
It should return 0 on success, anything else on failure, as is normal
for UNIX processes.
[0] https://review.coreboot.org/cgit/encapsulate.git
(Backported minus the Meson support)
Change-Id: I37a8e925d1b283c3b8f87cb3d0f1ed8920f2cf95
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46894
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62617
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: Nico Huber <nico.h@gmx.de>
Calm a compiler warning on big-endian builds about the unused static
flashrom_layout_parse_fmap(). The guard is ugly but gets the job done.
We should forbid endian-specific code in the future, I guess.
Change-Id: Id3f4a57e027f88cc469ed50312adddcc8af71a63
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33297
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Don't use a device that has the same vendor ID, but a different
than requested product ID.
Fixes broken dediprog detection with TOMU in use.
Change-Id: I08c1c363ce2d6603e46efecc61d3910e02314fca
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/32892
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is an interim solution. We'll have to enable 4BA step-by-step for
each dediprog protocol version.
Change-Id: I08efcbb09ab3499ef6902a698e9ce3d6232237c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The full verification step was not accounting for sparse layouts.
Instead of the old contents, combine_image_by_layout() implicitly
assumed the new contents for unspecified regions.
Change-Id: I44e0cea621f2a3d4dc70fa7e93c52ed95e54014a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
The erase (-E) feature is somehow a brute force method, but still, if we
are given a region to erase, we should make sure to restore surrounding
data if the erase block expands beyond the region.
It shares a lot of code with the write path. Though, experiments with
common functions have shown that it would make the whole function even
harder to read. Maybe we could add some abstraction if we ever need
similar code on a third path.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/31068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GCC is picky about the comment being where the break should go.
Change-Id: I05db2fb34025fefe2c6ddd1274c8e45b7cc5a4b6
Signed-off-by: Richard Hughes <richard@hughsie.com>
Reviewed-on: https://review.coreboot.org/c/30406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Leaving the `linux_spi` driver's unknown default is almost never what we
want and resulted in many support requests since Raspbian switched to a
default that is too high for most applications.
Change-Id: I9361b7c1a1ab8900a619b06e1dae14cd87eb56c2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/30368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested on a Supermicro X10SLM+-F. The flash chip has been read, written,
and erased many times without issue. Most boards with this chipset will
have the ME region locked, hence the selection of DEP.
Change-Id: I25126b94e691289a7b29dd81d5c864854a4e0245
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/c/30361
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This never was a use case until now but the `--fmap` code makes it
obvious: Unaligned reads that were smaller than the `chunksize` here,
were extended without considering the length of the buffer read into.
With that fixed we run into the next problem: dediprog_spi_bulk_read()
shouldn't report an error when an empty read is unaligned.
Change-Id: Ie12b62499ebfdb467d5126c00d327c76077ddead
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/30051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested reading, writing and erasing the internal flash chip using an HP
Pavilion dv6-2125ef laptop with an Intel PM55 chipset. However, since
all ME-enabled chipsets are marked as DEP instead of OK, this one shall
follow suit as well.
Change-Id: I667ea970be11a35b480e0e7c69a1fdf9afa08762
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/29437
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
As per user `The_Raven Raven` on the mailing list. Since the added
values had some inconsistencies, the chips are marked as untested.
Change-Id: I6c26aafdca232110986334e85297d73d513600dc
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/28813
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested on an ASRock H81M-HDS. The flash chip has been read, written, and
erased many times without issue. Most boards with this chipset will have
the ME region locked, hence the selection of DEP.
Change-Id: I30aae956b2851c741e59403f5e49b80b5ba7c5e4
Signed-off-by: Tristan Corrick <tristan@corrick.kiwi>
Reviewed-on: https://review.coreboot.org/29391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Similar to W25Q256FV, but it supports the native 4BA page program
instruction (12h). Note that the variant with QE enabled by default
shares the device ID of the W25Q256FV.
Tested using a Raspberry Pi.
Change-Id: I76d7362777d364594d2a733d7e478741b0bef7c4
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/29305
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
