Makefile treats warnings as errors, so enable the same option
for meson.
Makefile has an option to disable "warnings as errors" option
from command line. The same can be achieved with meson, see
scenario 2 below.
TEST=I verified the following scenarious
1) check that warnings treated as errors by enforcing higher
warning level
`meson setup --warnlevel=3 --wipe`
`ninja test`
shows tons of errors because warning level 3 is pedantic,
build fails
2) disable "warning as errors" option from command line
`meson configure -Dwerror=false`
`ninja test`
Now all warnings are non-blocking for build, so tests pass
3) back home
`meson configure -Dwerror=true`
`meson setup --warnlevel=2 --wipe`
`ninja test`
No warnings and tests pass
4) defaults: create new directory and run meson will all default
options
No warnings, all tests pass.
Change-Id: I06c72abf1c861f9b35736e02ef7f4a4fb6909b97
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Makefile has optimisation level set explicitly. This patch
sets the same level s into meson build.
Also disable debug by default to correspond to make builds.
These two options (optimisation and debug) are linked together
in meson build, so they need to be set together to be properly
recognised for builds.
Alternative approach would be to use buildtype option (and do not
set optimisation and debug). However, none of the standard
buildtypes gives a combination that we need:
optimisation level s and debug disabled.
TEST=ninja test shows no warnings and tests pass
Change-Id: I4ca96a866529cac320e66516ef280d5100ceefab
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Makefile options were more restrictive and produced more
warnings. This patch adds missing warning options into
meson build.
Makefile also has -Wall and -Wextra specified explicitly,
however this is covered by warning_level=2 which is already
set in meson.build. warning_level info:
https://github.com/mesonbuild/meson/issues/3275
There are few warning options that are present in meson,
but not in Makefile. These are left as is.
TEST=ninja test shows no warnings and tests pass
Change-Id: Id401bfd642dc3c13d85bd9a2dba56ada38714c25
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58561
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Part 2 of fixing -Wmissing-prototypes warnings. This patch adds
headers with function prototypes and includes the headers into
source files. This fixes the warnings like this:
warning: no previous prototype for ‘function_name’
[-Wmissing-prototypes]
This patch is needed to sync compiler warning options between meson
and makefile.
TEST=running the following produces no warnings:
meson setup --wipe (to clean build directory)
ninja test
Change-Id: Ia1ff22deb2354569f277649c6575ef2d5ffbb6e0
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63489
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Part 1 of fixing -Wmissing-prototypes warnings. This patch is
adding static to all functions which are actually static.
This fixes the warnings like this:
warning: no previous prototype for ‘function_name’
[-Wmissing-prototypes]
This patch is needed to sync compiler warning options between meson
and makefile.
TEST=running the following produces no warnings:
meson setup --wipe (to clean build directory)
ninja test
Change-Id: Ic54da5ac1b2a46f55e3e3bee4ed952bdf59e8444
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch is fixing -Wsign-compare warnings, specifically:
warning: comparison of integer expressions of different signedness:
‘int’ and ‘uint32_t’ {aka ‘unsigned int’} [-Wsign-compare]
Both instances in this patch produce the same warning.
The patch is needed to sync compiler warning options between meson
and makefile.
TEST=running the following gives no warnings:
meson setup --wipe (to clean build directory)
ninja test
Change-Id: I1f9325e9cf89f57f18d63cc3906a0958b47286d7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63488
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Move all header files to the new `include` directory.
Adapt include directives and build systems to the new directory.
Change-Id: Iaddd6bbfa0624b166d422f665877f096983bf4cf
Signed-off-by: Felix Singer <felix.singer@secunet.com>
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
WPS bit controls use of individual block protection which is mutually
exclusive with protection based on ranges. Proper support requires
extension of the API as well as implementation, so here we're just
making sure that range-based protection is enabled and our WP
configuration is not ignored by the chip.
Change-Id: I2c26ec65d64a3b6fb1f1a73690bc771415db2744
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Adds support for reading and writing the third status register.
Feature flag is not needed because it would never on its own control
whether SR3 access occurs. If added, it would be in one of three
possible states: wrong, useless or redundant.
Change-Id: Id987c544c02da2b956e6ad2c525265cac8f15be1
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60230
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The flashrom project does not use GitHub for pull requests or issues.
Thus, close issues and pull requests automatically using a GitHub
Actions hook. Also, add a comment pointing to our guidelines.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I8076f0fb964970ffd05f355b9d1e33a65aa7a3c8
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
`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).
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ifa910dea794175d8ee2ad277549e5a0d69cba45b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62867
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
As mentioned by Wolf Dieter Brandt in his mail from 07.Feb.22.
Change-Id: Idec3d82efbdf095c3d57bfe5f0fd487007b554cb
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62712
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>
Current error messages are not very helpful when attempting to flash a
target that has WP enabled. This change checks for the USB_SPI_DISABLED
error that occurs in this case and gives a more informative error
message.
BUG=b:210645611
TEST=Tested with WP enabled and disable to verify that error message is
displayed properly
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: Ib1e8383baa9c3ea41ab1079af12e3dc8cdff90ae
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62909
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
With this change we add path and flag validation to many tests that do
not call open. Expected path is set to NULL, if the code indead calls
open then the assertion for non-NULL will make the test fail.
BUG=b:217629892,b:215255210
TEST=`ninja test`.
Change-Id: I892fa1ecee26ebce9640893edbb228fa9aa7b0b6
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Co-Author: Daniel Campello <campello@chromium.org>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62320
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As identified while documenting driver, allow for passing
'false' even though it is the default for custom_rst to be
consistent.
BUG=b:224358254
TEST=builds
Change-Id: I25bfe6f8e3f7cfffb1a9c99ac90ec56a750d7f84
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63601
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Additionally, utilize CSSO (CPU Soft Strap Offset) to uniquely detect
the chipset when the CSSL (CPU Soft Strap Length) field default value
(0x03) on Jasper Lake is the same as Elkhart Lake.
BUG=b:221175960
TEST=dedede with `flashrom -p internal --flash-size`.
```
$ flashrom -VVV -p internal --ifd -i fd -i bios -r /tmp/filename.rom
<snip>
Enabling hardware sequencing by default for 100+ series PCH.
OK.
No board enable found matching coreboot IDs vendor="Google", model="Magolor".
The following protocols are supported: Programmer-specific.
Probing for Programmer Opaque flash chip, 0 kB: Chip identified: GD25Q127C/GD25Q128C
Hardware sequencing reports 1 attached SPI flash chip with a density of 16384 kB.
There is only one partition containing the whole address space (0x000000 - 0xffffff).
There are 4096 erase blocks with 4096 B each.
Added layout entry 00000000 - 00ffffff named complete flash
Found GigaDevice flash chip "GD25Q127C/GD25Q128C" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
Found GigaDevice flash chip "GD25Q127C/GD25Q128C" (16384 kB, Programmer-specific).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
Reading Status register
Block protection is disabled.
Reading ich descriptor... Reading 4096 bytes starting at 0x000000.
done.
Assuming chipset 'Jasper Lake'.
Added layout entry 00000000 - 00000fff named fd
Added layout entry 00381000 - 00ffffff named bios
Added layout entry 00001000 - 00380fff named me
restore_power_management: Re-enabling power management.
Using regions: "bios", "fd".
Reading Status register
Block protection is disabled.
Reading flash... 0x381000-0xffffff:R Reading 13103104 bytes starting at 0x381000.
000000-0x0fff:R Reading 4096 bytes starting at 0x000000.
done.
restore_power_management: Re-enabling power management.
SUCCESS
Restoring PCI config space for 00:1f:5 reg 0xdc
restore_power_management: Re-enabling power management.
```
Change-Id: Ib942d0b8942fe0a991b2af0b187414818485153d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
STANDALONE mode was used to build flashrom without having support for
file handling. This was relevant to build libflashrom on top of
libpayload. For a while now, the code which is covered by STANDALONE has
moved to cli_*.c and is not used for libflashrom. Therefore we can drop
STANDALONE mode.
Change-Id: I58fb82270a9884a323d9850176708d230fdc5165
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63469
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: Angel Pons <th3fanbus@gmail.com>
The NEED_PCI macro is only used to guard prototypes. This is not needed.
Change-Id: I6895b795bc96b3e251700bff4b0054407aac789a
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The libpci header is neither directly nor indirectly included in
flashrom.c. `PCILIB_VERSION` is therefore never set and the following
print statement is dead code. Since libpci is the only library in
buildinfo, Drop it.
Change-Id: I0b5dbf3bd82a2ffe64b73881383e92f7dad4c382
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62833
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-by: Nico Huber <nico.h@gmx.de>
This eliminates the need to redefine the rdmsr and wrmsr symbols,
resulting in more understandable code. The common prefix clarify the
relation between the functions.
Change-Id: Ie5ad54d198312578e0a1ee719eec67b37d2bf6a4
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62851
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add functions like
`uint32_t read_le32(const void *base, size_t offset);`
Read a 32 bit unsigned from a base with an offset.
Having prototypes and a macro generated implementation makes it easier
to read, understand and spot errors in one of them.
Change-Id: Idde177acf8bc5f94cd046b6539dc31532c98e452
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/31016
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
A `const` on the parameter itself is irrelevant to the caller.
Change-Id: Iea26d75719ebb718203dbba883ac88f459c68c0a
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63585
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The following do-block is quite error prone to do manually,
```
io_mock_register(&XXX_io);
run_probe_lifecycle(state, &XXX, "", "..");
io_mock_register(NULL);
```.
Hence, deduce out the common pattern and fold up into the common
worker function to handle state machine setup and teardown in a
consistent way.
BUG=b:227521116
TEST=`ninja test`.
Change-Id: Icc00acd980a027337acb079f5afc3cccdfe4c765
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63231
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Daniel Campello <campello@chromium.org>
Sabrina SoC uses SMBUS revision code 0x71 which behaves exactly as the
promontory chip. Hence add 0x71 as promontory.
BUG=b:228238107
TEST=Build and deploy flashrom in Skyrim. Ensure that flashrom is able
to detect the SPI ROM chip, read from it and write to it successfully.
Ran flashrom_tester on Skyrim (Sabrina SoC) successfully and ensured
that all the tests passed.
Change-Id: I2408959fbf1c105508f0a12f38418c9606280ab9
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63423
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-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Starting to move the platform dependent code to platform/ and provide
the abstraction through the platform.h header.
Change-Id: I35640282d451960f2a329ae24339ec05dbae6d30
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62899
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Split the code for endian conversion into separate files for big and
little endian. The buildsystem selects the correct file for the used
endianness. Replace the swab macros with `static inline` c functions.
Define macros for returning the same or swapped value. Call those macros
in the endian specific files.
Change-Id: I86d38d816b37c283279c485fac8027f8fb94364a
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62898
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
On AMD SoCs that use SPI100 engine, flashrom has been using legacy
spi100 register and bit mappings when programming the engine -
specifically when programming the opcode and triggering their execution.
---------------------------------------------------------------------
| Register Name | Legacy SPI100 mapping | Updated SPI100 mapping |
|---------------|------------------------|--------------------------|
| Opcode | Offset 0 from SPI BAR | Offset 0x45 from SPI BAR |
| | Bits 0:7 | Bits 0:7 |
|---------------|------------------------|--------------------------|
| Execute Cmd | Offset 2 from SPI BAR | Offset 0x47 from SPI BAR |
| | Bit 1 | Bit 7 |
---------------------------------------------------------------------
These legacy register mappings are removed in upcoming generations of
AMD SoCs. Stop using the legacy spi100 registers. For more details about
SPI100 refer to document: 56569-A1 Rev 3.01
BUG=b:228238107
TEST=Build and deploy flashrom in Skyrim. Ensure that flashrom is able
to detect the SPI ROM chip, read from it and write to it successfully.
Ran flashrom_tester on Dewatt (Cezanne SoC), Dalboz (Picasso SoC)
successfully and ensured that all the tests passed.
Change-Id: If42130757331f4294b5a42c848557d3287f24fc3
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Unsigned types show undefined behaviour if they are subtracted by a
value greater than their own (mostly it wraps to the max value). Using
this value for left shifting could be even more dangerous.
Change-Id: I5921cc571f3dca5188ca1973dba6ececbcbe2f39
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
For MACH / APPLE map_physical is defined in DirectHW.h
TEST: run `make`
compiles,
linking fails due to missing directhw object in my setup, don't know
how to fix this
Change-Id: I0e0f3fd587ae46e6f73418f2c83641cb1202478c
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62929
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With this change the wrappers for mock and friends are able to take an
optional io_mock_fallback_open_state struct to assert expected pathnames
and flags whenever an open operation is called.
Based partially on https://review.coreboot.org/c/flashrom/+/62319/5
BUG=b:227404721,b:217629892,b:215255210
TEST=./test_build.sh; FEATURES=test emerge-amd64-generic flashrom
BRANCH=none
Signed-off-by: Daniel Campello <campello@chromium.org>
Co-Author: Edward O'Callaghan <quasisec@google.com>
Change-Id: Ib46ca5b854c8453ec02ae09f3151cd4d25f988eb
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63227
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
With this change the mocks are able to return a non-negative value for
the file descriptor expected from open operations. This avoid issues
with subsequent error checks of the form `if (fd < 0)`
BUG=b:227404721
TEST=./test_build.sh; FEATURES=test emerge-amd64-generic flashrom
BRANCH=none
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: Ib6bac051852aea2465665a6fd669b7f5e3772985
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This is a follow up on commit 12dbc4e04508aecfff53ad95b6f68865da1b4f07.
Use a lookup table in get_wp_mode() and drop the srp_bit_present check,
since a chip without SRP is just FLASHROM_WP_MODE_DISABLED.
Add a srp_bit_present check to set_wp_mode() if the mode requires it.
BUG=b:182223106
BRANCH=none
TEST=flashrom --wp-{enable,disable,status} on AMD dut
Change-Id: Ib6c347453f9216e5816e4ed35bf9783fd3c720e0
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This commit adds a generic framework to allow opaque programmers to
implement writeprotect operations and uses the framework to support
writeprotect operations on linux MTD device files.
The generic framework comprises three new functions in
`struct opaque_master` that are called from libflashrom:
- wp_write_cfg()
- wp_read_cfg()
- wp_get_ranges()
For linux_mtd, only the read/write functions are implemented. Linux's
MTD interface doesn't provide a way to get available ranges, so calling
get_wp_ranges() on the linux_mtd master will return
FLASHROM_WP_ERR_RANGE_LIST_UNAVAILABLE.
BUG=b:182223106
BRANCH=none
TEST=WP ops on hana DUT (MT8173) with W25Q32DW flash
TEST=flashrom --wp-enable --wp-range <non-empty> succeeds
TEST=flashrom --wp-enable --wp-range <empty> fails as expected
TEST=flashrom --wp-disable --wp-range <empty> succeeds
TEST=flashrom --wp-disable --wp-range <non-empty> fails as expected
TEST=flashrom --wp-status succeeds
Change-Id: I5c86e28cdec44bec49ba1d36f8ab62241b9b01da
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Chips I had available for testing were tested with all writeprotect
commands and an FT232H adapter. Chips I wasn't able to test were just
checked against the datasheets.
Chips used for testing (including chips added in previous patches) are
listed in the table below:
Flashrom Chip name | Chip(s) tested
---------------------------------+----------------------------
AT25SL128A |
EN25QH128 |
GD25LQ128C/GD25LQ128D/GD25LQ128E | GD25LQ128DSIG
GD25LQ64(B) | GD25LQ64CWIG
GD25Q127C/GD25Q128C | GD25Q127CSIG, GD25Q128ESIG
GD25Q256D | GD25Q256DYIG
GD25Q64(B) | GD25Q64CSIG
W25Q128.JW.DTR |
W25Q128.V..M |
W25Q128.W |
W25Q256JV_M |
W25Q256.V |
W25Q64.W |
XM25QH128C |
XM25QH256C |
BUG=b:182223106
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status}
Change-Id: I7f3d4c4148056098a845b5c64308b0333ebda395
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62214
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure the g_has_dmi_support variable has the default state
of false after the life-time has expired.
BUG=none
TEST=builds
Change-Id: I0674950304736e53d014117d287682a4f6349879
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This allows has_dmi_support to be become static local
to just the scope of dmi.c
BUG=none
TEST=builds
Change-Id: Ibded9714998ea6f2e5d4e0512fa7c6b105f9638a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Delete the spi_read_status_register() function because the generic
spi_read_register() function can be used instead.
This patch also converts all call sites over to spi_read_register().
A side effect is that error codes are now properly propagated and
checked.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=Tested with a W25Q128.W flash on a kasumi (AMD) dut.
Read SR1/SR2 with --wp-status and activated various WP ranges
that toggled bits in both SR1 and SR2.
Change-Id: I146b4b5439872e66c5d33e156451a729d248c7da
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59529
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Creating the entire SPI command that should be sent to the chip in
spi_write_register() is simpler than splitting it across two functions
that have to pass multiple parameters between them.
Additionally, having separate spi_write_register_flag() function
provided little benefit, as it was only ever called from
spi_write_register().
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=Tested with a W25Q128.W flash on a kasumi (AMD) dut.
Read SR1/SR2 with --wp-status and activated various WP ranges
that toggled bits in both SR1 and SR2.
Change-Id: I4996b0848d0ed09032bad2ab13ab1f40bbfc0304
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59528
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds Meteor Lake support into flashrom.
Additionally, utilize CSSO (CPU Soft Strap Offset) to uniquely detect
the chipset when the CSSL (CPU Soft Strap Length) field default value
(0x03) on Meteor Lake is the same as Elkhart Lake.
BUG=b:224325352
TEST=Flashrom is able to detect MTL SPI DID and show chipset name as below:
> flashrom --flash-name
....
Found chipset "Intel Meteor Lake-P/M".
....
> flashrom - internal --ifd -i fd -i bios -r /tmp/bios.rom
....
Reading ich_descriptor... done.
Assuming chipset 'Meteor Lake'.
Using regions: "bios", "fd".
Reading flash... done.
SUCCESS
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I0a2ffe2ba8d96c90d89b77e0d8583d179ff02a75
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62783
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Sam McNally <sammc@google.com>
In function flash_layout_read_from_ifd variable chip_layout remains
uninitialized if prepare_flash_access returns false. This uninitialized
variable (which contains a garbage value) is passed to
flashrom_layout_release. Thus initialize it with NULL. For completeness,
also initialize dump_layout with NULL.
Change-Id: Iacbd7bf9cdf897cc2a732c1dc6568845a4ab804d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62725
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In function board_asus_p3b_f there were two consecutive lines which
modified the value of variable b
// Do something with b
b=INB(0x80);
b=INB(smbba);
//Do something with b
Since the value of b is not used after first assignment, remove the
first assignment.
Change-Id: I7458b416a69fd5e2aa300ca49d1352b6074ad0bc
Tested-by: Keith Hui <buurin@gmail.com>
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
