This fixes -Werror=unused-function when not all programmer tests are
build.
`run_basic_lifecycle` and `run_probe_lifecycle` need to have a prototype
to not throw a -Werror=unused-function if no programmer needs them.
Change-Id: I02880e73996b30df618738e86b8a52126fbe5b3b
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64224
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The install functions of meson can take a relative path and join the
prefix automatically.
Change-Id: I9cb9faf4bdbcfd66098478cc3a260eb3b664a2e6
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64028
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
During development it can be useful to disable unit testing. By default
tests are built if cmocka is found. To force enable tests run `meson
build -Dtests=enable`. To disable tests run `meson build
-Dtests=disabled`.
Change-Id: I384c904c577b265dfe36bf46bf07c641bc29de9b
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Move build instructions for files inside the `platform/` directory to
`platform/meson.build`. This contains instructions to build
`memaccess.c`, the right endian implementation and selecting the right
legacy command line option for the endian.
The `platform/` directory should contain code that abstracts the
underlying platform but is not involved in flashrom logic.
Change-Id: I88044a3f903f316138483dd872a6d95f8686ae69
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
An issue was discovered in the sys-info crate before 0.8.0 for Rust.
sys_info::disk_info calls can trigger a double free. To prevent any
potential problems, update this crate to version 0.9 (as of writing,
sys-info version 0.9.1 is the latest).
Refer to CVE-2020-36434 for more details about the sys-info crate bug.
TEST=Run `cargo build` in `util/flashrom_tester`, it still works fine.
Change-Id: I3b6b21e830ff3107860f7bcbfe2d58b29efe0c12
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63975
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Start taking bits related to write protection into account.
Also add "hwwp" parameter for dummy programmer that sets state of WP
pin (not inverted value).
TEST=use command-line interface to run WP-related commands
dummyflasher doesn't store state of the chip between runs and flashrom
allows running only one command, so testing WP in this way is limited.
However, WP options can be combined with other operations and are
executed prior to them, so certain scenarios can be checked.
List possible ranges:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes --wp-list
Set a particular range and check status is correct:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-enable \
--wp-range=0x00100000,0x00f00000 \
--wp-status
Enable write protection and try erasing/writing (erasing here):
# this fails
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0x00c00000 \
--wp-enable \
--erase
Write protecting empty range has no effect:
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0 \
--wp-enable \
--erase
Disabling WP is possible if hwwp is off:
# this fails
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=yes \
--wp-disable
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=no \
--wp-disable
Change-Id: I9fd1417f941186391bd213bd355530143c8f04a0
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Enable emulation of SR2 and SR3 for W25Q128FV and provide logic for
updating them (masks of read-only bits that can't be set from outside).
TEST=check how input value affects status registers of emulated chip
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x12 |
grep -A3 'Initial status registers'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x1234 |
grep -A3 'Initial status registers'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x123456 |
grep -A3 'Initial status registers'
Change-Id: I79f9b4a0b604663d3288ad70dcbe3ea4075dede5
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59073
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Prepare everything for emulating SR2 and SR3 for chips that have it.
This is needed for accessing SRP1 and WPS bits which are involved in
write protection. The emulated register doesn't affect anything yet
and will be tested by write-protection tests.
TEST=check how input value affects status registers of emulated chip
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x12 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x1234 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x123456 |
grep 'Initial status register'
Mind that at this point there are no chips that emulate more than one
status register.
Change-Id: I177ae3f068f03380f5b3941d9996a07205672e59
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
In function sp_stream_buffer_op, the variable parms might be NULL when
passed to memcpy. Although, since parmlen is also 0 at that time I
don't think it would make much difference. Still, add a NULL check
before calling memcpy to be safe.
Change-Id: I850123237e328f9548ba7f77a01888be2cbc9e7b
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
These inline functions and macros are only used in
platform/endian_(big|little).c and do not need to be compiled into every
object which includes `platform.h`.
Change-Id: Ib2326e6a4eb5e000a0eace857d040372e2e9e561
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63825
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 doxygen documentation was in the libflashrom.c file. Move the
documentation to the libflashrom.h file. This allows foreign function
interface binding generators (eg rust bindgen) that operate on the .h
file to generate documentation for the target language. Some doxygen
errors were also corrected, mostly undocumented or wrongly labeled
parameters.
To test, I have diffed and inspected the doxygen documentation before
and after the change. All functions are documented the same, and the
structs and enums are now also included in the docs.
Change-Id: I856b74d5bfea13722539be15496755a95e701eea
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63903
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 Singer <felixsinger@posteo.net>
Just a trivial patch to fix a few errors found by codespell.
Here's the command I used:
codespell -S subprojects,out \
-L fwe,dout,tast,crate,parms,claus,nt,nd,te,truns,trun
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4e3b277f220fa70dcab21912c30f1d26d9bd8749
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62840
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch introduces useful macros (read/write/erase) and uses these
macros throughout the SPI operations.
Additionally, implicitly using the HSFC_CYCLE_READ macro for the SPI
read operation.
BUG=b:223630977
TEST=Able to perform read/write/erase operation on PCH 600 series
chipset (board name: Brya).
Additionally, no difference in flashrom binary seen while comparing
flashrom binary generated with CB:62888 and between CB:62888 to
CB:62868 below:
flashrom$ cmp flashrom flashrom_old
<<none>>
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I3ea74b668e5f8d8e4b3da2a8ad8b81f1813e1e80
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62868
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In light of `commit caa0335114a81`, extract out the get_param logic to
its own function to simplify the number of cleanup paths.
BUG=none
TEST=builds
Change-Id: I364febc05c870683cbad114583762b0c006f4bac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63130
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configuration for W25Q64 was tested on hardware (W25Q64FV).
Emulation of W25Q128 in dummyflasher will be extended to support WP.
Haven't tested this one on hardware, but it's the same configuration as
for W25Q64 except that it has WPS.
W25Q64JV chip was renamed to W25Q64JV-.M (those with QPI).
W25Q64.V chip was split into W25Q64BV/W25Q64CV/W25Q64FV (no SR3 and WPS)
and W25Q64JV-.Q (SR3 and WPS, but no QPI).
Change-Id: Iccb69a8d3a0dd2192e2c938caddaf07b1889ed35
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Because the enum is a different name to the one within cr50 it
was entirely unclear where these values were handled at the end-point
and what a untargetted REQ_ENABLE actually did. Comment to avoid
needing to chase this again.
BUG=b:224358254
TEST=builds
Change-Id: I8cc78a85660190c9f750bf67994f0d59d69592d8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63902
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
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>
