When developing software that has to be flashed to a flash chip to be
executed, it often takes a long time to read the current flash contents
(for flashrom to know what pages to erase and reprogram) each time
when writing the new image. However, when the flash was just reprogrammed,
its current state is known to be the previous image that was flashed
(assuming it was verified).
Thus, it makes sense to provide that image as a file for the flash contents
instead of wasting valuable time read the whole flash each time.
Change-Id: Idf153b6955f37779ae9bfb228a434ed10c304947
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23263
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead of just "Probing for ENE KB9012 (EDI), 128 kB:", lets print
some debug info - like it is currently being printed for other chips:
Probing for ENE KB9012 (EDI), 128 kB: edi_chip_probe: hwversion 0xc3, ediid 0x04
Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
Change-Id: Id8e62bc9f6785b4bf0be0aaf0f74c8120d77c0d4
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23261
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
ENE chips enable EDI by detecting a clock frequency between 1 MHz and 8 MHz.
In many cases, the chip won't be able to both detect the clock signal and
serve the associated request at the same time.
Thus, a dummy read has to be added to ensure that EDI is enabled and
operational starting from the next request.
Change-Id: I69ee71674649cd8ba4fc635f889cb39a1cd204b9
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23260
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ENE Embedded Debug Interface (EDI) is a SPI-based interface for
accessing the memory of ENE embedded controllers.
The ENE KB9012 EC is an embedded controller found on various laptops
such as the Lenovo G505s. It features a 8051 microcontroller and
has 128 KiB of internal storage for program data.
EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO)
when flash direct access is not in use. Some firmwares disable EDI at runtime
so it might be necessary to ground pin 42 to reset the 8051 microcontroller
before accessing the KB9012 via EDI.
The example of flashing KB9012 at Lenovo G505S laptop could be found here:
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
Change-Id: Ib8b2eb2feeef5c337d725d15ebf994a299897854
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Most flash chips are erased to ones and programmed to zeros. However, some
other chips, such as the ENE KB9012 internal flash, work the opposite way.
Change-Id: Ia7b0de8568e31f9bf263ba0ad6b051e837477b6b
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23258
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default, we want to probe for SPI25 chips only. Other SPI use cases,
like the ENE/EDI protocol, might use commands that can confuse these
common chips.
Now, flashrom will probe for a chip only if one of these conditions is
true:
1) no chip has been specified AND the chip uses the SPI25 commands
2) this chip has been specified by -c | --chip <chipname>
The CLI can later be extended to probe for a specific class of chips.
Change-Id: I89a53ccaef2791a2ac32904d7ab813da7478a6f0
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
This patch sets the default baud rate for communication between
the host device and the Bus Pirate for hardware versions 3.0
and greater to 2M baud.
It also introduces the ability to manually set the baud rate via
the added 'serialspeed' programmer parameter.
This is done in two parts. Firstly, the requested serial speed is looked up
in a table to determine the appropriate clock divisor and the divisor is sent
to the bus pirate. Then, the system's baud rate for the selected serial port
is set using serial.c's 'serialport_config'. This function's prototype had to
be added to programmer.h.
In testing, using the 2M baud rate was able to significantly decrease
flash times (down from 20+ minutes to less than 2 minutes for an 8MB flash).
Change-Id: I3706f17a94fdf056063f2ad4a5f0a219665cdcbf
Signed-off-by: Shawn Anastasio <shawnanastasio@yahoo.com>
Reviewed-on: https://review.coreboot.org/23057
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the DOS cross-compile documentation,
and workaround issue with valloc() with the
latest DJGPP.
Change-Id: I909c5635aec5076440d2fde73d943f8ad10b8051
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Reviewed-on: https://review.coreboot.org/23039
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I can confirm a successful reading and writing of MX25L8005 (SPI) on a HP t5550
Thin Client (AMI BIOS 786R9 v1.04).
Change-Id: I190253b0c1920747b710ed7155e78191cce139eb
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23030
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Avoid attempting to read the SPI bases from the location 0x00000000, all
zeroes mean that the chipset's MMIO area is not enabled.
Change-Id: I5d3a1ba695153e854e0979ae634f8ed97e6b6293
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Advertise all 4BA features that are currently supported by flashrom,
plus add a new feature flag for the 4BA fast-read instruction. Also,
list all supported 3BA and 4BA erase-block functions.
As this adds a lot of new code paths that could be taken for these
chips, mark them all as untested again.
Change-Id: I0598496ee7058e3b170684d366f58e4014e0e871
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Instead of arbitrarily deciding whether to enter 4BA mode in the flash
chip's declaration, advertise that entering 4BA mode is supported and
only enter it if the SPI master supports 4-byte addresses. If not, exit
4BA mode (the chip might be in 4BA mode after reset). If we can't assure
the state of 4BA mode, we bail out to simplify the code (we'd have to
ensure that we don't run any instructions that can usually be switched
to 4BA mode otherwise).
Two new feature flags are introduced:
* FEATURE_4BA_ENTER:
Can enter/exit 4BA mode with instructions 0xb7/0xe9 w/o WREN.
* FEATURE_4BA_ENTER_WREN
Can enter/exit 4BA mode with instructions 0xb7/0xe9 after WREN.
FEATURE_4BA_SUPPORT is dropped, it's completely implicit now.
Also, draw the with/without WREN distinction into the enter/exit
functions to reduce code redundancy.
Change-Id: I877fe817f801fc54bd0ee2ce4e3ead324cbb3673
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Add a feature flag SPI_MASTER_4BA to `struct spi_master` that advertises
programmer-side support for 4-byte addresses in generic commands (and
read/write commands if the master uses the default implementations). Set
it for all masters that handle commands address-agnostic.
Don't prefer native 4BA instructions if the master doesn't support them.
Change-Id: Ife66e3fc49b9716f9c99cad957095b528135ec2c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Get rid of the layering violations around ICH's BBAR. Move all the weird
address handling into (surprise, surprise) `ichspi.c`. Might fix writes
for the `BBAR != 0` case by accident.
Background: Some ICHs have a BBAR (BIOS Base Address Configuration
Register) that, if set, limits the valid address range to [BBAR, 2^24).
Current code lifted addresses for REMS, RES and READ operations by BBAR,
now we do it for all addresses in ichspi. Special care has to be taken
if the BBAR is not aligned by the flash chip's size. In this case, the
lower part of the chip (from BBAR aligned down, up to BBAR) is inacces-
sible (this seems to be the original intend behind BBAR) and has to be
left out in the address offset calculation.
Change-Id: Icbac513c5339e8aff624870252133284ef85ab73
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22396
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prefer the native 4BA instruction when they are supported. In this
case, override our logic to decide to use a 4BA address.
Change-Id: I2f6817ca198bf923671a7aa67e956e5477d71848
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22385
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow 4-byte addresses for instructions usually used with 3-byte
addresses. Decide in which way the 4th byte will be communicated
based on the state of the chip (i.e. have we enabled 4BA mode)
and a new feature bit for an extended address register. If we
are not in 4BA mode and no extended address register is available
or the write to it fails, bail out.
We cache the state of 4BA mode and the extended address register
in the flashctx.
Change-Id: I644600beaab9a571b97b67f7516abe571d3460c1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22384
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce spi_prepare_address() and spi_write_cmd() and use them in
nbyte_program, nbyte_read and block-erase procedures. The former
abstracts over the address part of a SPI command to make it exten-
sible for 4-byte adressing. spi_write_cmd() implements a WREN + write
operation with address and optionally up to 256 bytes of data. It
provides a common path to reduce overall redundancy.
Also, reduce the polling delay in spi_block_erase_c4() from 500s to
500ms as the comment suggests.
Change-Id: Ibc1ae48acbfbd427a30bcd64bdc080dc3dc20503
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
spi_simple_write_cmd() executes WREN plus a single byte write and polls
WIP afterwards. It's used to replace current spi_erase_chip_*() imple-
mentations.
Change-Id: Ib244356fa471e15863b52e6037899d19113cb4a9
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
internal_init() explicitly fails on everything but x86 and mipsel.
Instead, we can just never build the internal programmer on other
architectures and drop a lot of #if boilerplate.
Change-Id: I672ddab0415df3baa49ff39a1c9db1b41d8143a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add an `endiantest.c` similar to `archtest.c` to provide the endianness
inside the Makefile. The __FLASHROM_(LITTLE|BIG)_ENDIAN__ definitions
had to move from `hwaccess.h` into `platform.h`, therefor. This will
be used to decide whether to build the internal programmer in a follow-
up.
Change-Id: I55dcf5a88da48f885cda9ad89ab87395d895a891
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
IS25LP128 is the 3.3V variant, IS25WP128 is the 1.8V variant.
Tested read, erase, and write using Dediprog SF600 on each.
Change-Id: Ia1c7a9a950043c30b7525196e03ee394689e89a5
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/22784
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead, continue probing the next chip.
This fixes the problem that flashrom aborts probing for
flashchips if one big flashchip (e.g. 32M/64M) can't be mapped
because of activated CONFIG_STRICT_DEVMEM kernel option.
Change-Id: Iaecfb6d30a5152c8c4b5d2804efacac85fc615f9
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reviewed-on: https://review.coreboot.org/22685
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Just another chip sharing the same ID. Tested by somebody on IRC.
Change-Id: Ibea956e48e10fda91930b65b3bf3b3ae4ad13f63
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22759
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
By adding more #if guards, fix warnings about unused constants that
are enabled by default in newer GCC versions.
Change-Id: Ib3b6d7c0c2fadc4faeab971673bfadb1a6d25919
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Skylake is a mess, especially with coreboot. We have now a present and
configured software sequencing interface with SCGO supposedly being
readonly (Apollo Lake has that feature and a strap documented, Skylake
behaviour might be the same). As we can't easily check if it's read-
only, just enable hardware sequencing by default (even if the software
sequencing interface seems usable).
Change-Id: I8a13fb9c3ca679b3f7d39ad1dc56d5efdc80045b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/22274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The interface of spi_read_status_register() is broken and can't return
errors. Let's not return random stack data at least.
Change-Id: I714b20001a5443bba665c2e0061ca14069777581
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Two occurences of ICH9_REG_OPMENU were overlooked and not replaced,
rendering the software sequencing unusable on Skylake.
Change-Id: I16eebcf37ab8ba39b02f33135535552e380b0b92
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/22273
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
TARGET_OS as well as EXEC_SUFFIX were only set when called via the
main makefile and even then __USE_MINGW_ANSI_STDIO was not set
for MinGW.
While at it, also replace the hardcoded gnu_printf printf format
attribute with __MINGW_PRINTF_FORMAT which is set according to
__USE_MINGW_ANSI_STDIO respectively.
Change-Id: Id146f5ba06a0e510397c6f32a2bd7c819a405a25
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tarballs on download.flashrom.org are generally packaged using bzip2, so
we may as well be internally consistent.
Change-Id: Ib9fb1ea6d5994cd0285ce8db9675640fae992773
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/22116
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Using serprog on FreeBSD to read an SPI flash (MX25L6406) via an
Arduino Nano V3 with flashrom hangs after 5 seconds while reading. The
problem is that kernel method "ttydisc_rint" ignores some bytes. It
happens due to enabled IEXTEN local flag of termios. TTY cuts a few
bytes, Arduino reads 11264 bytes, but flashrom gets only 11244 bytes
and waits for the remaining 20 bytes.
The fix is simple: turn off the IEXTEN local flag.
Tested on Arduino Nano V3 + FreeBSD 12-CURRENT.
Change-Id: I7aa6a283d523c544d9b8923cd4c622bf08c0fb3f
Signed-off-by: Michael Zhilin <mizhka@gmail.com>
Reviewed-on: https://review.coreboot.org/21919
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Urja Rannikko <urjaman@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The function to do this is contained in custom_baud.c because
of broken include stuff.
Change-Id: I2a20f9182cb85e7bce5d6654a2caf20e6202b195
Signed-off-by: Urja Rannikko <urjaman@gmail.com>
Reviewed-on: https://review.coreboot.org/20224
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The (old) ST (now Micron) M25P05 does only support RES for identification.
Unfortunately, the vendor datasheet states the same ID as for the M25P10
(0x10) and thus flashrom has treated these two as evil twins in the past.
However, real hardware confirmed that the real ID of this chip is 0x05.
Change-Id: Idc75f8cb98e7ef0c47c4527cedcc4da3723bd779
Signed-off-by: Serge Vasilugin <vasilugin@yandex.ru>
Tested-by: Serge Vasilugin <vasilugin@yandex.ru>
Reviewed-on: https://review.coreboot.org/21920
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows us to support flash chips in any of the following
configurations, regardless of whether the chip powers up in 3-byte or
4-byte address mode.
- standard commands with extended address register (*_4ba_ereg) or
direct commands (*_4ba_direct) in 3-byte address mode (.set_4ba =
spi_exit_4ba_*)
- standard commands (*_4ba) or direct commands (*_4ba_direct) in
4-byte address mode (.set_4ba = spi_enter_4ba_*)
- direct commands (*_4ba_direct) in either address mode (.set_4ba =
NULL)
Change-Id: I0b25309d731426940fc50956b744b681ab599e87
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
Reviewed-on: https://review.coreboot.org/20510
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Large flash chips usually support special instructions to work with
4-bytes address directly from 3-bytes addressing mode and without
do switching to 4-bytes mode. There are 13h (4BA Read), 12h (4BA Program)
and 21h,5Ch,DCh (4BA Erase), correspondingly. However not all these
instructions are supported by all large flash chips. Some chips
support 13h only, some 13h,12h,21h and DCh, but not 5Ch. This depends
on the manufacturer of the chip.
This patch provides code to use direct 4-bytes addressing instructions.
This code should work but it tested partially only. My W25Q256FV has
support for 4BA_Read (13h), but doesn't have support 4BA_Program (12h)
and 4BA_Erase instructions. So, direct 4BA program and erase
should be tested after.
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
flashchips.c
+ modified definition of Winbond W25Q256BV/W25Q256FV chips
flashrom.c
+ modified switch to 4-bytes addressing for direct-4BA instructions
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for read/write/erase directly with 4-bytes address (from any mode)
Change-Id: Ib51bcc5de7826b30ad697fcbb9a5152bde2c2ac9
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013198.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20508
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some flash chips data with addresses more than 24-bit field
can address may be accessed by using Extended Address Register.
The register has 1-byte size and stores high byte of 32-bit address.
Then flash can be read from 3-bytes addressing mode with writing
high byte of address to this Register. By using this way we have
access to full memory of a chip. Some chips may support this method
only.
This patch provides code use Extended Address Register.
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
flashrom.c
+ modified switch to 4-bytes addressing to support extended address register
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for write Extended Address Register
+ functions for read/write/erase with Extended Address Register
Change-Id: I09a8aa11de2ca14901f142c67c83c4fa0def4e27
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013200.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
