When flash regions are protected, erase could incorrectly erase regions
which were meant to be protected by requesting the correct size but
using an erase opcode with coarser granularity than desired (for
instance using a 16-byte erase command while attempting to erase only 8
bytes).
This fixes that by exchanging the nesting of the loops over erase blocks
and flash regions.
Old:
- Select erasefns
- Loop over blocks to erase for each selected erasefn
- Loop over programmer flash regions within erase block
- Erase regions (may fail since selected erasefn will be
too big if flash region is smaller than erase block)
New:
- Loop over programmer flash regions within erase block
- Select erasefns within programer flash region
- Loop over blocks to erase for each selected erasefn
- Erase regions
Eraser selection and erasing has also been factored out into a helper
function to manage nesting depth.
TEST=New test cases pass, whereas some of them fail without the changes
to erasure_layout.c
BUG=https://ticket.coreboot.org/issues/525
Change-Id: Ic5bf9d0f0e4a94c48d6f6e74e3cb9cccdc7adec9
Co-authored-by: Nikolai Artemiev <nartemiev@google.com>
Co-authored-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This allows tests to verify that the correct opcode is used when
erasing, which is required to unit-test the fix to issue #525 where in
some situations an incorrect erase opcode will be used.
BUG=https://ticket.coreboot.org/issues/525
Change-Id: I3983fe42c2e7f06668a1bd20d2db7fafa93b8043
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82251
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This allows the minimum time that default_delay() will choose to sleep
for instead of polling to be configured at build-time. The default
remains unchanged at 100 milliseconds for now.
The test's correctness has been checked by testing with minimum sleep
time left at its default and set to a non-default value smaller than 100
microseconds (both pass without sleeping, verified with strace) and with
the minimum sleep time set to 0 (causing the test to be skipped). The
configured value from the macro needs to be stored in a const to avoid
-Werror=type-limits errors when configured to be zero.
Change-Id: Ida96e0816ac914ed69d6fd82ad90ebe89cdef1cc
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As proposed on the mailing list ("RFC: remove the calibrated delay
loop" [1]), this removes the calibrated delay loop and uses OS-based
timing functions for all delays because the calibrated delay loop can
delay for shorter times than intended.
When sleeping this now uses nanosleep() unconditionally, since usleep
was only used on DOS (where DJGPP lacks nanosleep). When busy-looping,
it uses clock_gettime() with CLOCK_MONOTONIC or CLOCK_REALTIME depending
on availability, and gettimeofday() otherwise.
The calibrated delay loop is retained for DOS only, because timer
resolution on DJGPP is only about 50 milliseconds. Since typical delays
in flashrom are around 10 microseconds, using OS timing there would
regress performance by around 500x. The old implementation is reused
with some branches removed based on the knowledge that timer resolution
will not be better than about 50 milliseconds.
Tested by reading and writing flash on several Intel and AMD systems:
* Lenovo P920 (Intel C620, read/verify only)
* "nissa" chromebook (Intel Alder Lake-N)
* "zork" chromebook (AMD Zen+)
[1]: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/HFH6UHPAKA4JDL4YKPSQPO72KXSSRGME/
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I7ac5450d194a475143698d65d64d8bcd2fd25e3f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81545
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
The test cases from #16 onwards cover the case when layout region is
not aligned with eraseblock region, and therefore either layout start
boundary or end boundary needs to be extended to align with
eraseblock.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I726a30b0e47a966e8093ddc19abf4a65fb1d70ce
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78985
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The test checks that algorithm for erase functions selection
works and there are no regressions.
Specifically, test contains an array of test cases. Each case
initialises a given initial state of the memory for the mock chip,
and layout regions on the chip, and then performs erase and write
operations.
At the end of operation, test asserts the following:
- the state of mock chip memory is as expected, i.e. properly erased
or written
- erase blocks are invoked in expected order and expected number
of them
- chip operation (erase or write) returned 0.
Change-Id: I8f3fdefb76e71f6f8dc295d9dead5f38642aace7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Some devices such as the GSC knows how it is wired to AP and EC flash
chips, and can be told which specific device to talk to. Other devices
such as Servo Micro and HyperDebug are generic, and do not know how they
are wired, the caller is responsible for first configure the appropriate
MUXes or buffers, and then tell the debugger which port to use (Servo
Micro has just one SPI port, HyperDebug is the first that has multiple).
The Raiden protocol allows both the cases of USB devices knowing their
wiring and not.
If I were to declare the protocol in Rust, this is how the information
of the Raiden protocol "enable request" would be encoded:
```
enum {
EnableGeneric(u8),
EnableAp,
EnableEc,
...
}
```
The first label `EnableGeneric(u8)` is to be used with HyperDebug that
does not know how its ports are wired, and allow access by index.
The other labels `EnableAp` and `EnableEc` are to be used with the GSC.
The actual transmission of the enum above uses the bRequest and low byte
of wValue of a USB control request, but that is a detail and not
conceptually important.
Until now, `-p raiden_debug_spi:target=AP` or `...:target=EC` could be
used to make flashrom use `EnableAp` or `EnableEc`, and if neither was
given, it would default to `EnableGeneric`, which now that wValue is
used means `EnableGeneric(0)`.
I find it rather straight-forward, that `-p raiden_debug_spi:target=1`,
`...:target=2`, etc. should translate to `EnableGeneric(1)`, etc.
This patchset achieves this, by adding a second 16-bit parameter value,
next to request_enable.
I have tested that flashrom can detect the same Winbond flash chip
"W25Q128.V..M" with two different Raiden USB devices as below.
TEST=flashrom -p raiden_debug_spi:serial=0701B044-91AC3132,target=AP
TEST=flashrom -p raiden_debug_spi:serial=205635783236,target=1
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I03bf4f3210186fb5937b42e298761907b03e08b7
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Layouts can be expensive to derive (reading from flash), so we might
want to reuse a layout for different purposes. Today, it's not possible
to undo a flashrom_layout_include_region() operation (to, say, operate
on a different region). Add such an API.
Change-Id: I7ea3e0674f25e34bf2cfc8f464ae7ca1c1a3fbfd
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/76005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
When libusb is not around for the tests struct timeval and mode_t are
not defined on mingw. Add both missing header to compile the tests under
MSYS2 MINGW32/64 without libusb.
Change-Id: Ic76653c8f3b5d7043ab6080d4e2e1748590ad070
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75235
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook logging callback so unit-tests print what they are doing.
This make debug far easier for a failing test.
BUG=none
TEST=ninja test.
Change-Id: I7ab0ff0915a76eea9857fc876493615c06193a37
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74932
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Flashrom only tries to use WP-based unlocking if it detects that WP
operations are supported. However WP support was detected in a way that
ignored WP operations provided by opaque masters.
This stopped flashrom from automatically unlocking with some opaque
masters, particularly linux_mtd.
This commit also deletes part of a test that required the chip unlock
function to be called before read/write/erase operations because WP
unlocking is now used instead of chip unlocking.
BUG=b:280111380
BRANCH=none
TEST=Checked flashrom automatically unlocked flash on strongbad (MTD)
Change-Id: I1774ad64d82ae47cd085df6045e17e283855c01f
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
The main purpose of this patch is to run unit tests on BSD family
of OSes. The root cause is `fileno` syscall which is a macro that
can be expanded to either a function call (for multi-threaded
environment) or to inline code (for single-threaded environment).
Said inline code accesses private field of file descriptor, and
this construction is impossible to mock in unit tests. Multi-
threaded environment has `fileno` as a function, which can be
mocked in unit tests.
On other OSes the patch just creates a thread which is doing nothing.
We avoid adding pre-processor conditionals since the cost is small.
Tested on
FreeBSD 13.1-RELEASE-p6 GENERIC amd64
NetBSD 9.2 (GENERIC) amd64
OpenBSD 7.2 GENERIC#7 amd64
DragonFly v6.4.0-RELEASE x86_64
Ubuntu 22.04.1 x86_64
Change-Id: I3d65c125183e60037ad07b9d54b8fffdece5a4e8
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Patch fixes the error:
error: second argument to 'va_arg' is of promotable type 'mode_t'
(aka 'unsigned short'); this va_arg has undefined behavior because
arguments will be promoted to 'int' [-Werror,-Wvarargs]
Discovered and tested on:
FreeBSD clang version 13.0.0
gcc 8.3.0 "cc 8.3 [DragonFly] Release/2019-02-22"
Also tested on:
gcc 11.3.0 "cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0"
Change-Id: I95b7c8dafdf4e7664c48a952acd7f8eaedb59ba7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74202
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Converting the blockprotect unlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: Ie5c5db1b09d07e1a549990d6f5a622fae4c83233
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add a new wp_cfg_to_reg_values() function that takes a generic wp_cfg
instance and returns the chip-specific values that need to be written to
the chip's registers to enable the specified protection range/mode.
The function returns three values for each chip register:
- reg_values[reg] - Value writeprotect will write to reg
- bit_masks[reg] - Bit mask for WP-related bits in reg
- write_masks[reg] - Bit mask for writable WP-related bits in reg
(i.e. the ones writeprotect will try to write)
BUG=b:260019525,b:259013033,260020006
BRANCH=none
TEST=ninja test
Change-Id: Ib2a47153b230c9f82bb4eca357c335f2abbacc20
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69847
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Dummy programmer has a shared data between *_masters. To make sure the
dummy has no memory leakage, we need a test that will covers
initialization and shutdown of the programmer with different bus
types, i.e. programmer specific, non-SPI and SPI.
TEST=ninja test
Change-Id: Iafe715feb5f5c0b5efd6827cdb2c3a314f542319
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72665
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Just use a static string on the stack.
Change-Id: I0414ab9a63867fc58b04ad62ed3ec4f221448a58
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Just use a static string on the stack.
Change-Id: Ic6cb4f32094ae5868912ebcffc8ab21026c48d32
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71917
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Unit tests had int-to-pointer-cast warnings for 32-bit Linux
environment, and since warnings are treated as errors this
failed build with unit tests.
Ticket: https://ticket.coreboot.org/issues/407
Change-Id: I9ec5d37cc038171afc67a69ea9a6885deb8fa4a8
Tested-By: Branden Waldner <scruffy99@gmail.com>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72038
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
A written region that is sized below that of the erasure granularity
can result in a incorrectly read region that does not include prior
content within the region before the write op. This was dealt with
in ChromeOS downstream by expanding out the read to match the erase
granularity however does not seem to impact upstream. Add a unit-test
to avoid regression as this is important behaviour to cover.
Change-Id: Id3ce5cd1936f0f348d34a6c77cee15e27a5c353f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71659
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Evan Benn <evanbenn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A chip content setup as 0x00 is ambiguous from a zero'ed heap
or some erased chips and 0xFF is ambiguous from an erased chip.
Change-Id: I15905180141aee54c166ff1c0275d1a7dfde0a46
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The global const of `board_matches_size` has value `1` on non-x86
machines. Therefore strictly greater than zero is correct.
Change-Id: Icbe677d3ef164e998daf898ddbea34f96246677f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Code coverage can be requested with -Dllvm_cov and run with ninja
llvm-cov-tests or llvm-cov-cli.
BUG=b:187647884
BRANCH=None
TEST=meson test; ninja llvm-cov-tests
TEST=ran test_build.sh with coverage enabled
TEST=jenkins ran test_build.sh with coverage disabled
Change-Id: Id6c73bff46e7b88d425956a80def97082b201f56
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69268
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Code coverage writes data to disk, we need to use real io functions at
this point so that the data is really written.
BUG=b:187647884
BRANCH=None
TEST=llvm-profdata merge -sparse default.profraw -o default.profdata
TEST=llvm-cov show ./flashrom_unit_tests
-instr-profile=default.profdata --format=html --output-dir=.
Change-Id: I21cc1d631e92fa19006b967e85676f108e80b307
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69267
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Code coverage writes data to disk, we need to use real io functions at
this point so that the data is really written.
BUG=b:187647884
BRANCH=None
TEST=meson test
TEST=ninja coverage
Change-Id: If06053ecd78e886c8f7fc55813f4b5635be78c6b
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69266
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Implement a check that redirects mock io functions to the real
implementations. Real I/O functions are needed for the coverage tool to
be able to create and write files.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0817fce6ea0f53a4c127794a0d8246504675f805
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
open has a second form with a mode_t argument. When mocking without this
argument a caller trying to O_CREAT would have their mode_t argument
discarded and a random stack variable would be used instead.
BUG=b:187647884
BRANCH=None
TEST=meson test
Change-Id: I8c134e6d36a248d0f51985e389085a9e585fb83d
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69263
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add unit tests for programmer_table, flashchips, and board_matches
structs. The tests are derived from the selfcheck function, checking
that the required fields have been filled in.
BUG=b:140595239
BRANCH=None
TEST=meson test
Change-Id: I41cd014d9bf909296b6c28e3e00548e6883ff41a
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69620
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This test upgrades mocks to simulate a read request. Read buffer
is populated with chip manufacture id and chip model id to emulate
successful probing.
TEST=ninja test
Change-Id: I0a2d5591d097435fc69719e1d9bd153433425821
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68755
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
TEST=the following scenarios run tests successfully
1) ch341a_spi is enabled
result: all tests run and pass, including ch341a
2) ch341a_spi is disabled
result: ch341a_spi test is skipped, the rest of tests run and pass
3) libusb isn't presented in the system
result: tests for usb programmers are skipped, the rest of tests run
normally
Change-Id: If28fbe09ad685082152aa3a7e8d5a150169aee9e
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch adds mocks for several libusb functions are introduced
in one of the previous commits.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I5a316687ab39a112d968eeaedb71f7b4b659d8d5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The patch adds wrappers for libusb functions that are used in the
ch341a programmer and have not yet been introduced.
Change-Id: Ic11efb9fd746cb91911dbe87e1c0028759f5bb0b
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The `full_chip_erase_with_wp_dummyflasher_test_success` test case
checks that erasing a write-protected region of a dummyflasher chip
fails.
However erase optimization may cause the erase operation to be skipped
if the flash contents are already erased, so the erase operation appears
to succeed and the test case fails.
Writing a non-erased value to the chip ensures that an erase operation
will be executed and write protection will be properly tested.
BUG=b:237620197
BRANCH=none
TEST=ninja test
Change-Id: Ia00444dcd2ad96c64832a13201efbd064cd7302d
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69130
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: Angel Pons <th3fanbus@gmail.com>
Move the definition of the programmer test source files into the
dictionary defining the programmers itself. This way there is a better
overview about which of the available programmers have tests and which
don't.
Also, to keep the tests working, iterate over all programmers and add
their test source files to the list of sources that should be built.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I307faaf8a9f7ae3c54bd96e7d871a3abb8aadea3
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68162
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
Change-Id: I02ae7e4c67c5bf34ec2fd7ffe4af8a2aba6fd5e5
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69133
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This paves the way to allow for the conversion of flashchip erase_block
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: I122295ec9add0fe0efd27273c9725e5d64f6dbe2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69131
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Flashrom I/O mock functions need to be renamed so that they do not
have name clash with standard I/O, because the latter are allowed
to be macros. Adding a prefix to flashrom mock functions avoids
them being accidentally expanded. Standard I/O functions are
expanded and flashrom mocks stay as they are.
BUG=b:237606255
TEST=ninja test
1) gcc 12.2.0 on Debian
2) clang 15.0 on Chromium OS
Ticket: https://ticket.coreboot.org/issues/411
Change-Id: I7998a8fb1b9e65621e12adbfab5460a245d5606b
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68433
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The option _FORTIFY_SOURCE, when enabled, can result in some functions
being expanded into _chk variants. For example, `fprintf` can get
expanded into `__fprintf_chk`. This makes sense for building a real
binary, but is not needed for unit tests.
In unit test environment all those functions are wrapped. In the
example above, both `fprintf` and `__fprintf_chk` needed to be mocked.
Disabling _FORTIFY_SOURCE avoids expanding functions into _chk
variants, without any loss of testing coverage because that would
be wrapped/mocked anyway.
This patch also removes two existing _chk wraps because they are not
needed anymore.
BUG=b:237606255
TEST=ninja test on
1) gcc 12.2.0 on Debian
2) clang 15.0 on Chromium OS
Ticket: https://ticket.coreboot.org/issues/411
Change-Id: I70cb1cd90d1f377ff4606acad3c1b514120ae4f7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68432
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename the list of source files to `test_srcs` so that there is less
confusion with the variable `srcs` from the top-level meson.build file
containing the flashrom source files.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ica0fc3923070bff63323204bd58edb5276dc9493
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I612d46fefedf2b69e7e2064aa857fa0756efb4e7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66788
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I80149de169464b204fb09f1424a86fc645b740fd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I00aaab9c83f305cd47e78c36d9c2867f2b73c396
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Replace the `decode_range` function pointer in `struct flashchip` to an
enum value. The enum value can be used to find the corresponding
function pointer by passing it to `lookup_decode_range_func_ptr()`.
Removing function pointers like `decode_range` makes it possible to represent chip data in a declarative format that does not have to be
stored as C source code.
BUG=b:242479049
BRANCH=none
TEST=ninja && ninja test
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: If6d08d414d3d1ddadc95ca1d407fc87c23ab543d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67195
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a file object is created, Meson also checks if the file actually
exists and an error points to the specific line of meson.build if not.
If just a list of filenames is used, then the error occurs at the line
where the list is used.
Thus, use file objects in tests/meson.build for more useful error
messages.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I0b9144a6b76c1772833817b4e6873818dcf36b05
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
