Lifecycle tests are getting an upgrade in this chain, with new type
of tests: lifecycle with probing. Existing lifecycle, being the
simplest possible one becomes "basic lifecycle".
With time, most of existing tests will be upgraded to probing
lifecycle, however not necessarily all of them. Basic lifecycle will
likely to stay as an option. This can be convenient, for a developer
who wishes to add a test for a programmer, to have a choice of basic
and extended option.
BUG=b:181803212
TEST=ninja test
Change-Id: I2771921ae2bd37f4b3f49342e03d9abb5ee36ea0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59740
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Lifecycle tests are getting an upgrade later in this chain, which
means lifecycle becomes more than just init and shutdown. Rename
into lifecycle.c to reflect the upgrade.
BUG=b:181803212
TEST=ninja test
Change-Id: I8d734c43cc15c7ec1055d3fb5bdcdca8c90d0987
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59739
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
As per EDS, SPI controller sets the HSFSTS.bit5 (SCIP) when software
sets the Flash Cycle Go (FGO) bit in the Hardware Sequencing Flash
Control register.
This bit remains set until the cycle completes on the SPI interface.
Hardware automatically sets and clears this bit. Software must initiate
the next SPI transaction when this bit is 0.
Platform Setup: Alder Lake based ChromeOS devices (Brya variants)
Replication Steps: Accepting and running firmware Auto Update (AU) on
the Brya variants (dogfooder system) is seeing `flashrom` getting timed
out.
Problem Statement:
Evidencing AU (Auto Update) failure while performing firmware update on
the Alder Lake based ChromeOS devices.
Observation:
Based on the initial understanding from the failure log/pattern, it
seems like the platform is evidencing multiple `flashrom` access from
different source, for example: `futility` accesses flashrom for erase,
write and read operation, `crossystem` uses flashrom for updating VBNV,
additionally, `set_fw_good` script also uses `crossystem` to update the
fw status.
Solution:
Without this SCIP check being implemented in flashrom, there is no
way to ensure multiple instances of flashrom performing different SPI
operations are not cancelling each other and running into below error:
Erasing and writing flash chip... Timeout error between offset
0x0061c000 and 0x0061c03f (= 0x0061c000 + 63)! FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
TEST=Able to flash coreboot image on Alder Lake (Brya variants), Tiger
Lake (Volteer variants), Kaby Lake (Eve system), Comet Lake (Hatch
variants) and Ivybridge without any failure.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ib9265cc20513fd00f32f8fa22e28c312903ca484
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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/+/62611
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Does exactly what it says on the tin.
BUG=b:220799648
TEST=```localhost ~ # flashrom --flash-name
<snip>
Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
vendor="Programmer" name="Opaque flash chip"
flashrom -p internal --ifd -i fd -i bios -r /tmp/filename.rom
flashrom unknown on Linux 5.15.22 (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x768a7000.
Found chipset "Intel Alder Lake-N".
Enabling flash write... Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
SPI Configuration is locked down.
OK.
Found Winbond flash chip "W25Q256JV_M" (32768 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
Error accessing W25Q256JV_M, 0x2000000 bytes at 0x00000000fe000000
/dev/mem mmap failed: Resource temporarily unavailable
Could not map flash chip W25Q256JV_M at 0x00000000fe000000.
Reading ich descriptor... done.
Using regions: "bios", "fd".
Error accessing W25Q256JV_M, 0x2000000 bytes at 0x00000000fe000000
/dev/mem mmap failed: Resource temporarily unavailable
Could not map flash chip W25Q256JV_M at 0x00000000fe000000.
Reading flash... done.
SUCCESS
Also,
Reading ich descriptor... Reading 4096 bytes starting at 0x000000.
done.
Assuming chipset '600 series Alder Point'.
Added layout entry 00000000 - 00000fff named fd
Added layout entry 00500000 - 01ffffff named bios
Added layout entry 00001000 - 004fffff named me
```
Tested on Nivviks/ADL-N and Brya/ADL-P.
Change-Id: Ie66cf519df13f3391c41f5016b16a81ef3dfd4bf
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Generate list of available ranges by enumerating all possible values
that range bits (BPx, TB, ...) can take and using the chip's range
decoding function to get the range that is selected by each one.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-list
Change-Id: Id51f038f03305c8536d80313e52f77d27835f34d
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{status,range} at end of patch series
Change-Id: I5a1dfcf384166b1bac319d286306747e1dcaa000
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59183
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Allow chips to specify functions that map status register bits to
protection ranges. These are used to enumerate available ranges and
determine the protection state of chips. The patch also adds a range
decoding function for the example chips. Many other chips can also be
handled by it, though some will require different functions (e.g.
MX25L6406 and related chips).
Another approach that has been tried in cros flashrom is maintaining
tables of range data, but it quickly becomes error prone and hard to
validate.
Using a function to interpret the ranges allows compact encoding with
most chips and is flexible enough to allow chips with less predictable
ranges to be handled as well.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=dumped range tables, checked against datasheets
Change-Id: Id163ed80938a946a502ed116e48e8236e36eb203
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
New functions are exposed through the libflashrom API for
reading/writing chip's WP settins: `flashrom_wp_{read,write}_cfg()`.
They read/write an opaque `struct flashrom_wp_cfg` instance, which
includes the flash protection range and status register protection mode.
This commit also adds `{read,write}_wp_bits()` helper functions that
read/write chip-specific WP configuration bits.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I3ad25708c3321b8fb0216c3eaf6ffc07616537ad
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add `struct wp_bits` for representing values of all WP bits in a chip's
status/config register(s).
It allows most WP code to store and manipulate a chip's configuration
without knowing the exact layout of bits in the chip's status registers.
Supporting other chips may require additional fields to be added to the
structure.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I17dee630248ce7b51e624a6e46d7097d5d0de809
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds a register bit map `struct reg_bit_info`, with fields
for storing the register, bit index, and writability of each bit that
affects the chip's write protection. This allows writeprotect code to be
independent of the register layout of any specific chip. The new fields
have been filled out for example chips.
The representation is centered around describing how bits can be
accessed and modified, rather than the layout of registers. This is
generally easier to work with in code that needs to access specific bits
and typically requires specifying the locations of fewer bits overall.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: Id08d77e6d4ca5109c0d698271146d026dbc21284
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch adds support for reading and writing the second status
register and enables it on a limited set of flash chips.
Chip support for RDSR2/WRSR2/extended WRSR is represented using feature
flags to be consistent with how other SPI capabilities are represented.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
TEST=logged SR2 read/write values during wp commands
Change-Id: I34a503b0958e8f2f22a2a993a6ea529eb46b41db
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds new spi_{read,write}_register() functions that take the
source/destination register as an argument. Currently they can only
access SR1, support for other registers will be added in another patch.
Since we're refactoring things, this commit also makes
spi_read_register() return an error code, making it possible to identify
error conditions that spi_read_status_register() concealed.
This also removes the initial 100ms delay between writing a register and
the first attempt to check the chip's status. An initial delay was added
to avoid needing to read the status register multiple times, but that is
unlikely to cause problems on modern flash chips.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I0a3951bbf993f2d8d830143b29d3ce16cc6901d7
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Delete writeprotect code that was previously extracted from the cros tree.
This is the first of a series of commits adding writeprotect support.
Following commits incrementally implement writeprotect operations,
culminating in writeprotect support for three example chips: GD25LQ128,
GD25Q32, and GD25Q256.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I67e9b31f86465e5a8f7d3def637198671ee818a8
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
free() allows NULL and it makes error paths easier to handle when one
just needs to write `free(x);` without needing to care if `x` was
allocated already. Let's follow this rule in flashrom_flash_release().
flashrom_layout_release() already checks for NULL.
Change-Id: Id119c2e4f3aa1b11313059f11aac73c3e583185c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Have the same error message on all platforms.
Change-Id: I7aae096deedd9b78f5fd38a73390cd8a33528545
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
`getrevision.sh` isn't included in exported source code (including
GitHub's auto-generated tarballs and ZIPs). Per issue #95, the build
shouldn't depend on getrevision.sh for this reason. Previously,
however, Flashrom would not build from exported source using Meson
due to it requiring `getrevision.sh`. This patch has Meson use the
intended `getversion.sh` instead.
Signed-off-by: Samuel R. Messner <powpowd@gmail.com>
Change-Id: Id8601155b35f0299200c27d0278606127410ff16
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62061
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make progress towards the goal of removing pacc from global
state as noted in the FIXME of programmer.h
BUG=b:220950271
TEST=```sudo ./flashrom -p internal --flash-size
<snip>
Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
16777216
```
Change-Id: Id83bfd41f785f907e52a65a6689e8c7016fc1b77
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Use a conditional function for the statement. This limits the decision
to one line instead of multiple places.
Change-Id: Iee66dbc609bd5c6eb9d04b457f4508911b2e6560
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
flashrom_programmer_shutdown(NULL) is an equiv call
to programmer_shutdown() however this further decouples
cli from flashrom core logic at link-time, prefering to
instead enter via libflashrom instead.
BUG=none
TEST=`make`.
Change-Id: Ie194fa2e891797a29d05d7e9d0c7226fd62c0679
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The internal programmer has platform independent code for x86 and linux
based code for mipsel. Furthermore the internal programmer can call the
linux mtd programmer when available.
Enable the internal programmer on x86 or linux.
Change-Id: Ia607ea60c3d7d15fe231fa412595992dadc535ad
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
off_t is a special POSIX type that is used to represent file offsets in
certain APIs (e.g. lseek(), mmap()), and should not be reused to
represent anything else (such as flash offsets). In particular, the
width of the type may change based on the definition of the
_FILE_OFFSET_BITS macro. Using such a type at the libflashrom interface
is particularly dangerous, because if a program is built with a
different _FILE_OFFSET_BITS value than libflashrom, the resulting ABI
corruption will cause very very nasty and confusing bugs. This patch
replaces all instances of off_t that are not related to file offsets
with (s)size_t.
BUG=b:219811851
TEST=`elogtool list` on cherry.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I68a386973f79ea634f63dfcd7d95a63400e1fdee
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61943
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds two tests which cover verify operation, and
adds io_mock for fread.
BUG=b:181803212
TEST=ninja test
Change-Id: I1cc6f73f9b1e385eb963adccf20759c13a40ed3b
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59239
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
All CPPFLAGS and LDFLAGS for dependencies are handled by pkg-config
Change-Id: Ib7c11a0c8a7918562256480c4be0c95355f981c5
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61526
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
In the Flash Component description register (FLCOMP) bit 30 reports the
capability of using dual output for fast read operation on the flash
component. According to various SPI Programming Guides (checked for
Panther Point, Lewisburg C620, Apollo Lake and Elkhart Lake) the dual
output is enabled when this bit is set and disabled if not. Currently the
logic displays it the other way around when parsing the descriptor.
This patch changes this so now if bit 30 in FLCOMP is not set, dual read
support for fast read operation is shown as disabled.
Change-Id: If6282ac8326ab0b92e9c70c09dba0299bf0deb6f
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61362
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The pkg-config include path resolves the pciutils directory. So the
include is only the pci.h file.
Change-Id: I69dc8184d1d012fb695770cbf6f7c64e5a024453
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61525
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The --static flag of pkg-config returns also the LDFLAGS which are
required to link the library static. Use this flag to successfully
link against static libraries when the shared variant is not available.
This is the case in OpenBSD with libpci.
Change-Id: I6029a096c1ceca625789d18c88119d912d79bc0e
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61524
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some systems, e.g. OpenBSD, have clock_gettime / librt build into the
libc and therefore fail to link against it with -lrt. Thus, detect this
and link only if needed.
Change-Id: I2c1668a350aa0806fccfb4e9cd8b04861f085ee9
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61523
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The following describes the two mechanisms of testing done for
flash chip operations.
BUG=b:181803212
TEST=ninja test
Change-Id: Ie498ec55cce8460fc0b2e1fe27254d3a9f763fac
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch adds a macro MOCK_CHIP_CONTENT which represents a memory
state of a mock chip. The macro is used to initialise mock chip
memory at the beginning of a test (in setup_chip function).
Previously mock chip memory was not reset between tests. For
existing tests that did not matter, however new test for verify
operation (added later in this chain) needs mock chip memory to
be setup in a predictable way.
BUG=b:181803212
TEST=ninja test
Change-Id: I0d7623a601c207bfc62d54ab89d94cda56d85871
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59237
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
We've seen somewhat obscure test failures where the real fprintf()
function was passed a fake file returned by the fopen() mock.
Although the code that caused the specific failure was cros-specific,
adding an fprintf() mock should help avoid future debugging.
TEST=ninja test
BRANCH=none
BUG=b:217661133
Change-Id: I3f8594ea24d17436a7932732d9d05416b804dc93
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61708
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Elkhart Lake has a chipset called Mule Creek Canyon which is quite
compatible with 300 series chipsets. There are a few differences though,
e.g. different encoding for the SPI clock values for read and write in
the FLCOMP register. In addition Elkhart Lake has a new PCI device ID
for the SPI controller which is added, too.
TEST=Read and flash complete flash on Siemens MC EHL1
Change-Id: I711e39a3ec9cd7098389231eaa1cb864d615a475
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60711
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Calling libflashrom entry-points that internally dispatch to
fmap_lsearch() can result in a integer overflow. Therefore
validate the length paramter before attempting to use it.
BUG=none
TEST=`make`
Change-Id: Ifb408c55c3b69ddff453dcc704b7389298050473
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Spotted-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61545
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
BUG=b:204488958
TEST=Check that the following scenarios still behave properly:
1) probe-read-verify-erase section-write-reboot
on Intel octopus board with GD25LQ128C/GD25LQ128D/GD25LQ128E
2) flashrom binary built before and after this patch with command
`make clean && make CONFIG_EVERYTHING=yes VERSION=none`
is the same
Change-Id: I7ca2902b7caaa95418b828b068c661afafdcd171
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60272
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Initialisation of swseq_data and hwseq_data gets its own function,
which is called from init_ich_default. This makes init_ich_default
more readable.
This patch also gives a name to (previously anonymous) struct
swseq_data. Its sibling struct hwseq_data already has a name. Structs
need names to be able to declare function parameters.
BUG=b:204488958
TEST=Check that the following scenarios still behave properly:
1) probe-read-verify-erase section-write-reboot
on Intel octopus board with GD25LQ128C/GD25LQ128D/GD25LQ128E
2) probe and read on Panther Point (7 series PCH)
Change-Id: I7d62b1b380e497b82dcae1284d752204cc541bd3
Tested-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58737
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Extract processing of ich_spi_mode into a separate function which
is called from init_ich_default. This makes init_ich_default more
readable and avoids one local variable.
BUG=b:204488958
TEST=Check that the following scenarios still behave properly:
1) probe-read-verify-erase section-write-reboot
on Intel octopus board with GD25LQ128C/GD25LQ128D/GD25LQ128E
2) probe and read on Panther Point (7 series PCH)
Change-Id: I20e2379a6fd58c9346f0a2d6daf2b8decf1f6976
Tested-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58736
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
ich_init_spi is very long, but logically it can be split. Init
function detects the chipset and then the rest of operations depends
on the chipset.
Init function is more readable now, it consists of only a switch.
Initialisation of hwseq and swseq that used to happen in the
beginning of init function now moved to init_ich_default, because
hwseq and swseq are only used for chipsets served by init_ich_default.
BUG=b:204488958
TEST=Check that the following scenarios still behave properly:
1) probe-read-verify-erase section-write-reboot
on Intel octopus board with GD25LQ128C/GD25LQ128D/GD25LQ128E
2) probe and read on Panther Point (7 series PCH)
3) on machine with ich7 chipset, output from probe and read is
the same between master and this patch
Change-Id: I6789bc456a4878e6555831ae0b80ecbdbf62938b
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: Nico Huber <nico.h@gmx.de>
Tested-by: Nicholas Chin <nic.c3.14@gmail.com>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58735
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a spi_master interface supporting MediaTek MST9U ISP mode.
Autodetect the bus type via I2C_FUNC_I2C, and use the appropriate
read/write commands, in case the MST9U is attached to smbus.
TEST=Successfully programmed SPI on test hardware.
Change-Id: I24adb14e7b4f7160e1c3ff941774064d5a81e820
Signed-off-by: Neill Corlett <corlett@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61288
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
These helpers are only used by the CLI logic and so we localise
them here to move towards cli_classic being a pure libflashrom
user.
BUG=b:208132085
TEST=`make`
Change-Id: If1112155e2421e0178fd73f847cbb80868387433
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This allows for moving all the do_*() helper functions
use for the cli from flashrom.c within static local functions
in cli_classic.c
BUG=b:208132085
TEST=`make`
Change-Id: Ia0abec655a682ca449d0e8ba620886a2d616b86d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60069
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
