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>
Here is the definition of new W25Q256xV chip with new functions pointers
for 4-bytes addressing reads and writes. Erase functions pointers are
changed in their old places. New feature flags for 4-bytes mode added.
Patched files
-------------
flashchips.c
+ added definition for Winbond W25Q256BV/W25Q256FV chips
Change-Id: I90226f453f8147ae5ac7dbbef7549ee3bfacc3d6
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013201.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20506
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch integrates code of the previous patch into Flashrom's code.
All the integrations is around 3 functions spi_nbyte_read, spi_nbyte_program
and spi_byte_program. After this patch then are not static and can be called
by their pointers saved in flashchips array. Also I added to flashrom.c some
code to switch a chip to 4-bytes addressing mode. And one error message is
corrected in spi.c because it's not suitable for 32-bit addresses.
Patched files
-------------
flash.h
+ added set of 4-bytes address functions to flashchip structure definition
flashrom.c
+ added switch to 4-bytes addressing more for chips which support it
serprog.c
+ added 4-bytes addressing spi_nbyte_read call to serprog_spi_read
spi.c
+ fixed flash chip size check in spi_chip_read
spi25.c
+ added 4-bytes addressing spi_nbyte_read call to spi_read_chunked
+ added 4-bytes addressing spi_nbyte_program call to spi_write_chunked
+ added 4-bytes addressing spi_byte_program call to spi_chip_write_1
Conflicts:
serprog.c
Change-Id: Ib051cfc93bd4aa7580519e0e6206d025f3ca8049
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013205.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20505
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Fix some whitespace, and braces. Remove sector size from comments that I
could not verify.
Change-Id: I4faaa036fea744135fa37f405686fb9fd0882806
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/21947
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
If flash chip is switched to 4-bytes addressing mode then all
read/erase/program instructions will be switched from 3-bytes mode
to 4-bytes mode. Then well known instructions like 03h (Read),
02h (Program) and 20h,52h,D8h (Erase) will become one byte longer
and accept 4-bytes address instead of 3-bytes.
This patch provides support for well known instructions in 4-bytes
addressing mode. Also here is the code to enter 4-bytes addressing
mode by execute the instruction B7h (Enter 4-bytes mode).
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
Makefile
+ added spi4ba.c
Added files
-----------
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 enter 4-bytes addressing mode
+ functions for read/write/erase in 4-bytes addressing mode
Change-Id: Ie72e2a89cd75fb4d09f48e81c4c1d927c317b7a7
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013199.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20513
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>
without the upcache there is no "offline" version (yet).
Change-Id: Iac3bf11fbd55cfa034ef8af04ef90fe57182ee2b
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
refine the pre-push hook:
- get rid of the concept of precious brances - all of them on the
upstream repos are precious (this is a change in the face of
using gerrit instead of a native git repository for staging purposes)
- likewise, only allow new versioned stable branches and no feature
branches there
Change-Id: I1d4b4a7ef2673cabee980ec4a7d7d5fbebdcaed1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- update the commit-msg hook to the latest one provided by Gerrit.
However, disable the (new) code that would avoid adding Change-IDs
to fixup/squash commits as needed on the staging branch
Change-Id: I2f2d7ae58dcd7d3e55959e18fe664df10bc3cc41
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21832
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- wrap a line in the hook installer. The line still exceeds our
maximum limit by two chars but it makes no sense to break
apart the one long argument IMHO
Change-Id: I0e931fbb5902d2714d5399c1d1bfac0de35523bb
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21831
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- exploit Make's -include statement to simplify execution flow
- expand and refine respective comment to better describe and
match the new behavior
Change-Id: I0c66f2508cc754cf9219211a06d6f305a32c422d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21830
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename getrevision's local_revision function to just revision.
All revisions are local in git and we certainly wont go back to
a non-distributed VCS :)
Change-Id: I6689ac24077b3981b471ed69de7cc3ef79d435b1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- make version string generation independent of the actual VCS
used by not generating "unknown" in the makefile but letting
getrevision do that
- make hook installation independent of version string generation
since they have nothing to do with each other and there are no
synergies anymore
Change-Id: Iedc9df4c033a70447b8b1b65c83764c769b02c3f
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Use a more generic file name for the exported VCS data.
Change-Id: Ie57b20dc014ba44ded5783bdb432eb7d0e0e28ad
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix broken/one-off loop to restore file dates.
Explain what the sed program actually does because it is non-trivial.
Change-Id: Iff4021be49a9fab208b619c555b9f9e81f671ab8
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
"System Manager's Manual" or similar is way less interesting.
Change-Id: I45c5d6a2316c51a57a49fd010682dc3f0f915382
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21822
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A couple of C99-style variable declarations within loops are causing
compilation failures on some systems (gcc 4.9.2-10 on Raspbian). This
moves them to make gcc happy.
Change-Id: Ib7ad5a69244e462f84eae93df9e841716e089b31
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/21702
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replace bit shits with BIT() macro. This improves the readability of the
code.
Change-Id: I30315891f18d4d5bfbc247bb9012560479afab90
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21432
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Implements I210 "raw" flash access as detailed in:
http://www.intel.com/content/www/us/en/embedded/products/networking/i210-ethernet-controller-datasheet.html
Unfortunately, most of the time the card is in Secure Mode, which means
that the raw access is not available. But his should be pretty useful
for bringing up boards.
Change-Id: I8598ab21297b85dcae1e650a168043aa4cc15c10
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21430
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
On the I210 family there is no MAC EEprom, instead there is a big flash
(typically around 16Mb) with contents of the old MAC plus other stuff.
There is an interface to program the whole flash, but once it is
programmed it enters a "Secure Mode" that disables the interface.
Luckily, the section with the MAC can still be updated via the EEprom
interface. This patch adds support for this interface.
root@qt5022-fglrx:~# ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
flashrom v0.9.9-unknown on Linux 4.10.0-qtec-standard (x86_64)
flashrom is free software, get the source code at https://flashrom.org
flashrom was built with libpci 3.4.1, GCC 5.3.0, little endian
Command line (5 args): ./flashrom -p nicintel_eeprom:pci=01:0.0 -w kk.raw -V
Calibrating delay loop... OS timer resolution is 1 usecs, 1856M loops per second, 10 myus = 10 us,
100 myus = 102 us, 1000 myus = 1017 us, 10000 myus = 10044 us, 4 myus = 4 us, OK.
Initializing nicintel_eeprom programmer
Found "Intel I210 Gigabit Network Connection" (8086:1533, BDF 01:00.0).
Requested BAR is of type MEM, 32bit, not prefetchable
Requested BAR is of type MEM, 32bit, not prefetchable
The following protocols are supported: Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Found Programmer flash chip "Opaque flash chip"
(4 kB, Programmer-specific) on nicintel_eeprom.
Found Programmer flash chip "Opaque flash chip" (4 kB, Programmer-specific).
Reading old flash chip contents... done.
Erasing and writing flash chip... Trying erase function 0... 0x000000-0x000fff:W
Erase/write done.
Verifying flash... VERIFIED.
Change-Id: I553f33e5dcb4412d682fc93095b29bcfed11713c
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This patch has been tested on a board similar to AMD Bettong.
00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus
Controller [1022:790b] (rev 4a)
00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC
Bridge [1022:790e] (rev 11)
root@qt5022-fglrx:~# ./flashrom -p internal -w kk.rom
flashrom v0.9.9-unknown on Linux 4.10.0-qtec-standard (x86_64)
flashrom is free software, get the source code at
https://flashrom.org
Calibrating delay loop... OK.
coreboot table found at 0x9ffd6000.
Found chipset "AMD FP4".
Enabling flash write... OK.
Found Micron/Numonyx/ST flash chip "N25Q128..1E" (16384 kB, SPI)
mapped at physical address 0x00000000ff000000.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
Change-Id: I66a240ebc8382cc7e5156686045aee1a9d03fe6d
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Reviewed-on: https://review.coreboot.org/21429
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
5 regions made sense in 2013 when this bit of code was originally
written. MAX_NUM_FLREGS is now used to keep track of the max number of
flash regions and is >5 since Sunrise Point.
Change-Id: Idb559e618369fecf930724a7c1c84765247f3e38
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/21338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This moves the ich_layout declaration from one header to another. This
will avoid a circular dependency when we update the entries[] member in
the follow-up patch to use MAX_NUM_FLREGS which is defined in
ich_descriptors.h.
Change-Id: I08006f1f7c9ccdd17a9a6d74881ed2c8541d4de1
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/21337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This adds PCI IDs for C620-series PCHs and adds
CHIPSET_C620_SERIES_LEWISBURG as a new entry in the ich_chipset enum.
Lewisburg is very similar to Sunrise Point for Flashrom's purposes,
however one important difference is the way the "number of masters" is
interpreted from the flash descriptor (0-based vs. 1-based). There are
also new flash regions defined.
Change-Id: I96c89bc28bdfcd953229c17679f2c28f8b874d0b
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/20922
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Can't find bits that tell us the actual permissions in charge. So report
them as unknown.
Change-Id: Ib73f95e0348f5c6d89988e3ea3529af0ec3b23a6
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/21106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
The pci_dev structure is never meant to be used as is, but always as a
pointer. By using the struct itself in undo_pci_write_data, we are risking
data corruption, or buffer overflows if the structure size changes.
This is especially apparent on my system where flashrom segfaults
because I compile it with pciutils 3.3.0 and I run it on a system
with pciutils 3.5.2. The struture size is different and causes a
struct with the wrong size to be sent to the library, with invalid
internal field values.
This has been discovered and discussed in Change ID 18925 [1]
[1] https://review.coreboot.org/#/c/18925/
Change-Id: Icde2e587992ba964d4ff92c33aa659850ba06298
Signed-off-by: Youness Alaoui <kakaroto@kakaroto.homelinux.net>
Reviewed-on: https://review.coreboot.org/20784
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
