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>
Old wiki website is retired and so is print_wiki.c
Change-Id: I9990add27f7fdddc23ddd1f33306566ce7548417
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@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>
Other chips (at least Winbond) will benefit from this change.
Also, drop the FIXME comment, as it can be misleading. The
"pretty print" functions should only display values from the
Status Register, so using an inappropriate function might only
confuse user.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I7169a2312698343e1065cdca91a3985e00cb3804
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
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>
Converting the printlock 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: I9131348f72c1010e2c213dca4dc4b675a8d8681e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
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>
Chip restore callbacks currently are used by
- spi25_statusreg.c unlock functions to restore status register 1.
- s25f.c to restore config register 3.
Both of these cases only need to save a single uint8_t value to restore
the original chip state, however storing a void pointer will allow more
flexible chip restore behaviour. In particular, it will allow
flashrom_wp_cfg objects to be saved and restored, enabling
writeprotect-based unlocking.
BUG=b:237485865,b:247421511
BRANCH=none
TEST=Tested on grunt DUT (prog: sb600spi, flash: W25Q128.W):
`flashrom --wp-range 0x0,0x1000000 \
flashrom --wp-status # Result: range=0x0,0x1000000 \
flashrom -w random.bin # Result: success \
flashrom -v random.bin # Result: success \
flashrom --wp-status # Result: range=0x0,0x1000000`
Change-Id: I311b468a4b0349f4da9584c12b36af6ec2394527
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70349
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>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The new erase algorithm uses some of the functions which are static to
`flashrom.c`. So make these functions global and add prototypes to
`include\flash.h` and `include\layout.h'.
Change-Id: I7ee7e208948337b88467935fd2861b5f9ad6af9d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add flags to allow libflashrom users to configure how operations that
include unreadable or unwritable regions should be behave.
If the flags are set to true, a read/write operation will just skip the
inaccessible region and will still be executed in other regions.
If the flags are set to false, the inaccessible region will cause the
entire operation to fail.
BUG=b:260440773
BRANCH=none
TEST=builds
Change-Id: I9b96fb04b863625d2c9f9a00b97c35b3ddb0871b
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The non-custom driver programmer delay implementation
'internal_delay()' is unrelated specifically to the
'internal' programmer. The delay implementation is
simply a platform-agnostic host delay implementation.
Therefore, rename to simply default_delay().
Change-Id: I5e04adf16812ceb1480992c92bca25ed80f8897a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68855
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This paves the way to allow for the conversion of flashchip printlock
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: Icff868d9454e9b0a059a736457bb562430436033
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69844
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 paves the way to allow for the conversion of flashchip unlock
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: I3ed51142cd22becc8286959f5504565158fa2de0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Not all chips follow the same pattern. There are differences in how CMP
bit is treated or in block size used.
Change-Id: Ied7b27be2ee2426af8f473432e2b01a290de2365
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66212
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
One more variation of registers.
This one is read via a separate RDCR command, but written as if it's
SR2 using WRSR_EXT2.
Change-Id: I45f9afcc31f1928ef6263a749596380082963de4
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66211
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Not to be confused with "secure registers" of OTP.
Security register is a dedicated status register for security-related
bits. You don't write its value directly, issuing special write commands
with no data set separate OTP bits to 1 automatically (WRSCUR, WPSEL
commands). No WREN is necessary, but at least some datasheets indicate
BUSY state after those write commands.
Unlike cases where OTP bit is part of SR and can only be written while
in OTP mode, security register can only be written outside of the mode.
The register is found in at least these chips by Macronix:
* MX25L6436E
* MX25L6445E
* MX25L6465E
* MX25L6473E
Change-Id: Iae1753ca4cb051127a5bcbeba7f064053adb8dae
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59709
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
Apart from the very bespoke case of 'probe_w29ee011()'
the override 'chip_to_probe' name is a nature parameter
to 'probe_flash()'. However we can deal with w29ee011
by providing a probe specific validation function to
check if the chip can indeed be overriden.
TEST=`./flashrom -p internal --flash-name`.
Change-Id: Ifcdace07ea2135d83dea92cfa5c6bec8d7ddf05d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.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: 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>
Modify the `programmer_delay` function signature to allow passing
the flashrom context. Programmers that depend on internal delay
should provide NULL as a context. The use of this function parameter
will be introduced in CB:67393.
TOPIC=programmer_handle_global
TEST=builds
Change-Id: Ibb0bce26ce2052853ee52158d7ba742967a9e229
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Move (un)map_flash_region function pointers from programmer_entry to
par_master, spi_master, and opaque_master. This enables programmers to
specify a different mapper per bus, which is needed for the internal
programmer. Mapping is closely tied to the way the memory is accessed
using the other functions in the bus master structs.
Validate that FWH/LPC programmers provide specialized mapping in
register_par_master(); this is needed for chips with
FEATURE_REGISTERMAP, which only exist on FWH or LPC buses.
programmer.c: Update comment in fallback_map(), NULL return is the
desired behavior.
Test: Read firmware on SB600 Promontory mainboard (requires physmap)
Test: Read firmware externally with ft2232_spi
Test: Read firmware on ICH hwseq, verify physmap still occurs
Change-Id: I9c3df6ae260bcdb246dfb0cd8e043919609b014b
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Co-Authored-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67695
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is analogous to spi.c and opaque.c however parallel
logic was previously never consoldiated.
This free's up flashrom.c from namespace pollution.
BUG=b:242246291
TEST=builds with both make and meson.
Change-Id: Ie08e2e6c51ccef5281386bf7e3df439b91573974
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66651
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The write_buf_to_include_args() helper is only ever used
by the cli frontend therefore make it static local to the
user.
BUG=b:242246291
TEST=builds
Change-Id: Ia16bf4b8e46a011aa45f98089d43904b077833a0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The read_buf_from_include_args() helper is only ever used
by the cli frontend therefore make it static local to the
user.
BUG=b:242246291
TEST=builds
Change-Id: I9dee63d67320085e16c64eefb2723169f49f07aa
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
write_buf_to_include_args() does not need the whole flashctx,
rather it works with a fix layout and buffer. Just pass what
state is actually required.
BUG=b:242246291
TEST=builds
Change-Id: I885c4395356eef27746c66300233f07f4718ccdf
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66644
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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: Thomas Heijligen <src@posteo.de>
read_buf_from_include_args() does not need the whole flashctx,
rather it works with a fix layout and buffer. Just pass what
state is actually required.
BUG=b:242246291
TEST=builds
Change-Id: Ieadd68895c7ba05cc3d770d304351b02622f14d7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66633
Reviewed-by: Evan Benn <evanbenn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
So far, we assumed the 0xc5/0xc8 instructions by default and allowed
to override the write instructions with the `.wrea_override` field.
This has some disadvantages:
* The additional field is easily overlooked. So when adding a new
flash chip, one might assume only 0xc5/0xc8 are supported.
* We cannot describe flash chips completely that allow both
instructions (and some programmers may be picky about which
instructions can be used).
Therefore, replace the `.wrea_override` field with a feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6d82f24898acd0789203516a7456fd785907bc10
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
To prepare for other instructions than the default 0xc5/0xc8, rename
the original feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iacb7b68a9e3444fe28873ff0fe5e3fab16643c8c
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Spansion flash chips S25FL128L and S25FL256L use the WRSR instruction to
write more than 2 registers. So align SR2 and SR3 support: The current
FEATURE_WRSR_EXT is renamed to FEATURE_WRSR_EXT2 and FEATURE_WRSR_EXT3
is added. Also, WRSR3 needs a separate flag now.
Verified that FEATURE_WRSR_EXT2 still works using the `dummy_flasher`.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibdfc6eb3d2cfecbf8da0493d067031ddb079a094
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
These were part of the original wp implementation, now dead
code left over.
Change-Id: I43b25175c6ff833b822a93c4e752a28cf97d64b8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The need_erase() helper is only used within flashrom.c
Change-Id: Ic0946bb109fca2fc18e15eefa11cccea284ded0b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64369
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
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>
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>
