The patch updates calculation of total length for the operation
which is displayed with progress.
The reason is: even if, for example the whole chip erase or write
was requested, the actual length of bytes modified can be less than
whole chip size (areas which already have expected content,
are skipped).
Change-Id: I88ac4d40f1b6ccc1636b1efb690d8d68bdebec08
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84439
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original progress reporting implemented in CB:49643 and it has some
issues, for example:
size_t start_address = start;
size_t end_address = len - start;
End address is anything but length minus start address.
update_progress(flash,
FLASHROM_PROGRESS_READ,
/*current*/ start - start_address + to_read,
/*total*/ end_address);
Total should just be length if that's how current value is computed.
---
libflashrom needs to know total size ahead of time.
That's init_progress() and changed update_progress().
It also needs to store the last current value to be able to update it.
That's stage_progress in flashrom_flashctx.
Measuring accurately amount of data which will be read/erased/written
isn't easy because things can be skipped as optimizations. The next
patch in the chain aims to address this, there are TODO/FIXME
comments there.
---
CLI shares terminal with the rest of the code and has to maintain more
state to handle that reasonably well.
Similar to CB:64668, an effort is made to keep the progress on a
single line. Non-progress output is kept track of to know when
moving to a new line cannot be avoided.
---
A script to test the CLI:
\#!/bin/bash
t=${1:-rewW}
shift
if [[ $t =~ r ]]; then
echo ">>> READ"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -r dump.rom --progress "$@"
echo
fi
if [[ $t =~ e ]]; then
echo ">>> ERASE"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -E --progress "$@"
echo
fi
if [[ $t =~ w ]]; then
echo ">>> WRITE (without erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -w zero.rom --progress "$@"
echo
fi
if [[ $t =~ W ]]; then
echo ">>> WRITE (with erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
dd if=/dev/random of=random.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz,image=random.rom -w zero.rom --progress "$@"
echo
fi
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: If1e40fc97f443c4f0c0501cef11cff1f3f84c051
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84102
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The patch adds a section on a manpage to explain the freq
parameter in dummyflasher, and tests for various valid and invalid
values of freq parameter.
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: Iaca5d95f8f977bf0c2283c6458d8977e6ce70251
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84423
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
New check was added to `check_block_eraser` in
commit 0f389aea9e630c3b21547a5dd8dbe572a8502853 but it was not
handling FEATURE_NO_ERASE chips.
This patch fixes processing such chips and adds test to run
write and verify with dummyflasher for FEATURE_NO_ERASE chips.
Ticket: https://ticket.coreboot.org/issues/553
Change-Id: I582fe00da0715e9b5e92fcc9d15d5a90a2615117
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
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>
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 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>
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>
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>
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>
Programmer param can be NULL and this is a valid case which can
be covered by unit test.
`run_lifecycle` needs an adjustment to handle NULL as programmer
param, which is also included in the patch.
Change-Id: I409f1c9ac832943e54107f7cf8652d1f46ac67df
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67642
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Unhandled programmer params are considered as an error for
initialisation procedure, adding tests to run those scenarios.
BUG=b:181803212
TEST=ninja test
Change-Id: Ia64f6362f46a029e168bfdb3bdb903328fd1f9c7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67199
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add tests for i2c programmers that assert that initialisation fails
when allow_brick parameter is not provided.
Example of logs from test run:
[ RUN ] parade_lspcon_no_allow_brick_test_success
Testing init error path for programmer=parade_lspcon with params: bus=254 ...
... init failed with error code -1 as expected
[ OK ] parade_lspcon_no_allow_brick_test_success
BUG=b:181803212
TEST=ninja test
Change-Id: I382f563016502f3342131d5f9c0de41dc665b03a
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This unit test does not require any additional mocks because init
and shutdown of i2c infra was covered in realtek programmer lifecycle.
Default mocking of i2c is sufficient to run a basic lifecycle.
To run the test, config option for the programmer needs to be
enabled explicitly, since by default this programmer is disabled.
BUG=b:238816884
TEST=meson configure -Dconfig_mediatek_i2c_spi=true
ninja test
Change-Id: I98a12067d165c90013d33ffc45d20dab5c364c83
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66261
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This unit test does not require any additional mocks because init
and shutdown of i2c infra was covered in realtek programmer lifecycle.
Default mocking of i2c is sufficient to run a basic lifecycle.
To run the test, config option for the programmer needs to be
enabled explicitly, since by default this programmer is disabled.
BUG=b:238816889
TEST=meson configure -Dconfig_parade_lspcon=true
ninja test
Change-Id: I0dcfae4a58c64b2e8d56ec51b4b050534cbb4cd2
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66003
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Lifecycle functions will be used in all lifecycle tests and need to
be available by including lifecycle.h
BUG=b:237606255
TEST=ninja test
Change-Id: Ic4e9defe16c535c9384c1304c1cad2f5b84294c9
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
In commit a721181a08 dummyflasher became an opaque master too, and
now registers prog bus by default. This patch upgrades a dummy unit
test which uses all buses as programmer param, and adds a unit test
which covers specific use case for opaque programmer.
BUG=b:233816068
TEST=ninja test
Change-Id: I61a5333b61ea84fb91c7f8310d52b64213c62f83
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65236
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Joursoir <chat@joursoir.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Projects using libflashrom like fwupd expect the user to wait for the
operation to complete. To avoid the user thinking the process has
"hung" or "got stuck" report back the progress complete of the erase,
write and read operations.
Add a new --progress flag to the CLI to report progress of operations.
Include a test for the dummy spi25 device.
TEST=./test_build.sh; ./flashrom -p lspcon_i2c_spi:bus=7 -r /dev/null --progress
Change-Id: I7197572bb7f19e3bdb2bde855d70a0f50fd3854c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49643
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>
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>
This test adds a mock for linux_spi ioctl and mocks it for read
request. Read buffer is populated with chip manufacture id and
chip model id to emulate successful probing.
BUG=b:181803212
TEST=ninja test
Change-Id: I32d8e972d99b52c2b18f688aa6aeae75dd170f72
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Nico Huber <nico.h@gmx.de>
No additional mocks are needed, because linux_mtd is doing most of
the job in init function.
BUG=b:181803212
TEST=ninja test
Change-Id: I74436f36f628680c22c7225b1584f06464307775
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59743
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This patch implements run_probe_lifecycle and adds dummyflasher
test to run probing lifecycle.
A lifecycle consists of 3 steps: 1) init programmer 2) do some action
3) shutdown programmer. Step 2 can be "do nothing", and this is
named "basic lifecycle", i.e. the simplest. This patch implements
"probe lifecycle" which probes a chip as Step 2.
Internally there is one run_lifecycle function which performs steps
1, 2, 3. run_lifecycle is operating via libflashrom API. Long term
goal for cli_classic is to operate via libflashrom API, so the test
aligns with this approach.
BUG=b:181803212
TEST=ninja test
Change-Id: I9eb7fe3a436fbba5e70db957139fd26e00efec36
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59741
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
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>
This patch adds a test for raiden_debug_spi and lots of libusb wraps.
libusb.h becomes required for tests to build and run, since new tests
are using libusb structs in depth and opaque symbols not sufficient
anymore.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I880a8637ab02de179df9169c1898230bce4dc1c7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57918
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch adds two tests and initialises page_size in mock chip
chip_W25Q128_V. page_size was not needed for previous tests
(erase and read). page_size only needed to execute writing on chip
with dummyflasher, so it is added here.
BUG=b:181803212
TEST=ninja test
Change-Id: I6f0336613ab16a7e59857006496e3590ddb14d00
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Two tests cover the code which performs do_read operation.
First one works with fake chip and dummy programmer. Fake chip has all
operations defined, and a buffer to emulate chip memory.
Second one uses the chip which is closer to the real one, because
read/write/unlock/erase operations are real. The tests takes the
advantage of dummyflasher's capability of emulating a W25Q128.V chip.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: Ia57781ebc670c7bd6197e56fe8a20651a425c756
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Best efforts were made to upstream older Chromebook support for good
intentions for folks interested. However, we no longer have the hardware
available to test and maintain the code as the hardware is now end of
life. Therefore the code state has sadly fallen into a unknown state.
BUG=none
BRANCH=none
TEST=builds and ninja test passes
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I535b6380846734c999474519e9e60a73eb6a2ec4
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56476
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Best efforts were made to upstream older Chromebook support for good
intentions for folks interested. However, we no longer have the hardware
available to test and maintain the code as the hardware is now end of
life. Therefore the code state has sadly fallen into a unknown state.
BUG=none
BRANCH=none
TEST=builds and ninja test passes
Signed-off-by: Victor Ding <victording@google.com>
Change-Id: I3f40db22c42c04ce029c4defd837e05ebb550c9b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56475
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch adds an init-shutdown test for linux_mtd. Since
linux_mtd is using file i/o operations, those are added to the
framework and mocked.
Another driver linux_spi which is also using file i/o, got an upgrade
in this patch, and it is now reading max buffer size from sysfs (using
mocked file i/o).
A good side-effect is that linux_mtd is the first test for opaque
masters, which is great to have in preparation for a change like
CB:56103 but for opaque masters.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I73f0d6ff2ad5074add7a721ed3416230d3647e3f
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56413
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Two tests cover the code which performs do_erase operation.
First one works with fake chip and dummy programmer. Fake chip has all
operations defined, and a buffer to emulate chip memory.
Second one uses the chip which is closer to the real one, because
read/write/unlock/erase operations are real. The tests takes the
advantage of dummyflasher's capability of emulating a W25Q128.V chip.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I6f74bfe4e02244d24d6c837cc3d551251e7b4898
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This can catch regressions like the earlier one in this programmer that
caused initialization to always fail. Requires support for mocking POSIX
file I/O functions because the programmer does ioctls on the opened
file.
TEST=ninja test
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I5a5c617d1ec35d2a3bbe622e5add82a65eb396f0
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56911
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 patch adds a test and mocks for two pci functions that
nicreltek is using.
Main reason for this is to have at least one test for par master
(currently there are none), in preparation for a change like
CB:56103 but for par masters.
BUG=b:181803212
TEST=ninja test
Change-Id: Iaed14fe1d83c8eb45ec185ebd3f1c97cb81941f4
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56470
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Three more tests in this patch where layout does / does not pass
sanity checks.
BUG=b:193584590
TEST=ninja test
Change-Id: Ia21585d60443b2741f3868d7887476090e35f79b
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56440
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>
There are no tests for layout, it would be great to add some.
Also partially inspired by
commit 06a89d713951a2e08ef8fb698a7688357baa83d1
and commit c9039fc27916c03e21ba91365d01e6bc49503053
BUG=b:193584590
TEST=ninja test
Change-Id: I7aa8dc0c9bc5a22fe5deea757eea1a151b969cea
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56324
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds mocks for libusb functions. To avoid dependency on
libusb.h, libusb symbols for context and device handle are redefined.
Real libusb functions are never called in tests anyway, cmocka wraps
work with this without complaints.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I38508dfb6d7c24d42522f22fcae0c5e410c5f7ea
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch includes mocks for io operations in hwaccess_x86_io.h
because those are needed to test lifecycle of mec1308.c and
ene_lpc.c
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I3af612defe1af3850dfc1626a208d873e3a3eddc
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51487
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current implementation tests a particular path of the init
procedure. There are two ways for it to succeed: reading the buffer
size from sysfs and the fallback to getpagesize(). This test does
the latter (fallback to getpagesize).
Extract from meson-logs/testlog.txt for new test:
[ RUN ] linux_spi_init_and_shutdown_test_success
Testing programmer_init for programmer=25 ...
__wrap_open64 is called
__wrap_ioctl is called
__wrap_ioctl is called
__wrap_ioctl is called
__wrap_fopen64 is called
... programmer_init for programmer=25 successful
Testing programmer_shutdown for programmer=25 ...
... programmer_shutdown for programmer=25 successful
[ OK ] linux_spi_init_and_shutdown_test_success
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I4911fbb6f04371283f0e62d2196bdd691a227584
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52498
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce test to exercise that init and shutdown of drivers
correctly manage the drivers life-time state. We constrain
ourselves to dummyflasher in particular here as it does not need
any mocking.
BUG=b:181803212
TEST=builds and ninja test
Change-Id: I3c0ef73397f00c1db7aabb5f9f00cb43525af29c
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52497
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
