The initial version of API for progress callback would require the
callback function to make a second call to get the needed data about
progress state (current, total etc).
This patch changes the callback API, so that callback function gets
all needed data straight away as parameters, and with this,
callback has all the data to do its job.
Since the initial version was submitted and it was in the tree for a
while, the change needs to add a _v2 suffix for new thing and
deprecated attribute for old thing.
Testing: both unit tests and cli are libflashrom clients.
All unit tests run successfully, for the cli all scenarios from
commit 75dc0655b95dde91f1426a7e5aecfc04d7b8d631 run successfully.
Change-Id: Ia8cc0461c449b7e65888a64cdc594c55b81eae7a
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
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>
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>
We used to have two code paths for erase and write, so we had
{erase|write}_by_layout in two variants: *_new and *_legacy.
Now that legacy is removed, *_new can be renamed without *_new
suffix.
Change-Id: Ib21bf29e1993c4fc0516e76fde2ad283eedb50d2
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83852
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aarya <aarya.chaumal@gmail.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Current code path for erase and write has been enabled in the tree
since May 2023, which is more than 1 year ago (15 months ago),
and legacy path has been disabled since the same time.
Current logic has been officially released in v1.4.0 in July 2024.
Change-Id: I08fd686fecf6a5313eea2d66b368661c664f4800
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aarya <aarya.chaumal@gmail.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
get_flash_region() emits a struct flash_region, which uses chipoff_t for
the start and end addresses of a region. chipoff_t is defined as a valid
flash address, so it was wrong to be setting the end address to start +
len; this is clearly wrong in the case where there is a single region
because setting end to the flash size generates an address that is
beyond the end of the chip (due to zero-indexing).
This changes the one actual implementation of .get_region in ichspi.c to
use inclusive upper bounds, and corrects all callers of
get_flash_region() to treat the upper bounds as inclusive. Overall this
reduces complexity slightly by removing more downward adjustments by 1
than it needs to add upward adjustments.
TEST=on yaviks, `flashrom -V -x` prints equivalent messages about
"x region (0xZZZZ..0xZZZZ) is readable" before and after this
patch.
Change-Id: Ia0ca867aef33b598c2697fc264807fa5e29683ec
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
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>
Failing to disable WP before write/erase doesn't necessarily indicate an
error and flashrom doesn't treat it as such. Print a warning instead on
an error.
BUG=b:336220545
BRANCH=none
TEST=build
Change-Id: I14c3b55e387443909ca1efab2fc1901f87dd66d6
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82175
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Waiting a full second is a very long time, especially when
default_delay() chooses to busy-loop. This code has been around for a
decade, with vague references to user reports:
commit 8ab49e72af8465d4527de2ec37b22cd44f7a1169
Date: Wed Aug 19 13:55:34 2009 +0000
Disallow erase/write for known bad chips so people won't try without a clear understanding
Still, this logic does not belong in the high-level library logic, used
by all programmers and all chips. If there is a timing issue, it should
either be encoded in the appropriate programmer or flashchip timing.
However, we don't really know what chips were in use, as the above
commit doesn't have any links to reports. So in a feeble attempt at
avoiding breaking users here, we also surmise that...
* SPI chips weren't all that common in 2009;
* I'm mostly motivated by flashrom performance on Chromebooks, were SPI
chips (and linux_mtd / BUS_PROG) are the rule; and
* SPI chips have precise timing requirements and an appropriate BUSY
status. So we guess that this "calm down" magic delay wouldn't be
necessary there.
Thus, we allow this magic delay only on non-SPI (and non-BUG_PROG, used
by linux_mtd for one) buses as a compromise.
Now, this change has some (hopefully [1] tiny) chance of regression, so
we have the following considerations:
1. emergency_help_message() already provides documentation on how to
contact support, in case we need to handle any user-reported
regressions.
2. If there is any regression here, it's only in the --verify code; so
we can always provide workarounds for testing this, to determine
whether this change may have been at fault. For example, something
like:
flashrom --write /my/new/image.bin --noverify
sleep 1
flashrom --read /tmp/bar.bin
cmp /my/new/image.bin /tmp/bar.bin
If such problems occur, we can collect system/programmer/chip info to
try to encode a more targeted delay into the appropriate
chip/programmer implementation, and avoid penalizing the entire
project like this.
3. We already have (embedded in erase_write()) erase verification that
performs no such delay. So depending on the type of timing error that
this delay was attempting to cover, we may have some proof that this
delay is no longer necessary (or at least, that whatever systems were
needing this delay in the first place are no longer caring about
flashrom).
4. We've retained the delay for buses that were likely common in 2009
(per the above "feeble attempt").
NB: I avoid using the BUS_NONSPI macro, because I want to exclude any
future buses from this workaround, even in the event that the BUS_NONSPI
category grows in the future.
[1] Famous last words.
BUG=b:325539928
TEST=`flashrom_tester --flashrom_binary=$(which flashrom) \
internal Erase_and_Write Fail_to_verify`,
TEST=`vpd -i RW_VPD -s foo=bar; vpd -i RW_VPD -l; \
vpd -i RW_VPD -d foo; vpd -i RW_VPD -l`
TEST=`elogtool list; elogtool add 0xa7; elogtool list`
on (at least) 2 systems:
#1: Kukui/Kakadu rev2 - MTD programmer /
kernel 5.10.215-24542-g0515a679eb42 /
CrOS ~ 15857.0.0
#2: Zork/Dirinboz rev2 -
chip name: vendor="Winbond" name="W25Q128.JW.DTR" /
BIOS: Google_Dirinboz.13434.688.0 /
kernel 5.4.267-21940-g67f70e251a74 /
CrOS ~ 15753.43.0
Change-Id: Ie09651fede3f9f03425244c94a2da8bae00315fc
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80807
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Don't unlock using WP for read/verify operations because WP will only
disable write locks. Most chips don't have read locks anyway, but some
do, so we still call the chip's unlock function for read/verify
operations.
Unconditionally unlocking using WP slows down flashrom significantly
with some programmers, particularly linux_mtd due to inefficiency in the
current kernel MTD interface.
BUG=b:283779258
BRANCH=none
TEST=`ninja test`
TEST=`flashrom -{r,w,E,v}` on strongbad
TEST=`flashrom --wp-enable; flashrom -{w,E}` on strongbad
Change-Id: I5dc66474a0b7969b51b86ac9f5daa2c95ae968f1
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75991
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The flashbase is a machine-sized integer representation of
address space and so use the appropriate type that is correctly
sized to encode such data.
The flashbase is assigned to 'base' in 'map_flash()' and the
type correctly changed to uintptr_t in commit 4e32ec19b124a7
therefore makes for a consistent type usage whenever stored.
While `sizeof(unsigned long)` and `sizeof(uintptr_t)` are both `8` under
most circumstances on a 64bit platform and thus have enough bits to
represent all addresses on the platform, the C standard does not
guarantee this. Only `uintptr_t` and `void *` has a guaranteed
isomorphism as `uintptr_t` is defined by the platforms toolchain support
whereas the conversion from `void *` to an integer is implementation
defined and that the memory address value may contain additional bits
describing the validation data or provenance of the address. Therefore a
integer is insufficient to contain all the necessary information for
that specific platform so this may not always work out for all platforms
and toolchain combinations.
Spotted-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ib9057e438731b9cccde0e24d5c8f758c3af1d47f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Set the use_legacy_erase_path flag to false to enable erase path optimisation
by default.
Change-Id: Ie13e43b18b20dbb956b569e554953a19eb32ea22
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74872
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>
DJGPP for compiling DOS has other sizes for the normal int types and
therefore throwing errors when using %i %d or %x with uint32_t.
Fix these warnings by using the macros created for it and provided in
inttypes.h.
Change-Id: Ia75b6df981ce60c891161fe553c7ceab8570178d
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73040
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The previous implementation had no error handling, as a result the
flashrom could crash if the computer ran out of memory. The new
version returns NULL in such cases.
Also, rewrite lots of `if` conditions to one cycle, store a name of
buses and `enum chipbustype` in an array by using a custom struct.
The caller always expected a non-null value, so change its behavior to
handle a possible null value or use the `?` symbol. As far as `free()`
can handle null pointers, do nothing with such callers.
TEST=ninja test
Change-Id: I59b9044c99b4ba6c00d8c97f1e91af09d70dce2c
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/408
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Due to how internal is structured around chipset_flash_enable()
entry we need to prepare a crafted programmer_cfg that contains
a board_enable substructure with data derived from the board_enable
subsystem. While this is certainly not perfection, it does make
clear the relationships between board_enable into chipset_flash_enable
and subsequently the overall internal programmer initialisation
in a RAII fashion at the type level over closure upon global
state that is impossible to reason about.
Also flip predicate in report_nonwl_laptop_detected() and
return early with the trivial base-case.
TEST=`$ sudo ./flashrom -p internal --flash-name`.
Change-Id: I459215253845c2af73262943ce91a36464e9eb06
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.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>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => true' as to not need this
boilerplate as it implies default behaviour of a supported
opcode within the `check_block_eraser()` match supported loop.
Ran;
```
$ find . -name '*.[c,h]' -exec sed -i '/.probe_opcode = default_spi_probe_opcode,/d' '{}' \;
```
Change-Id: Id502c5d2596ad1db52faf05723083620e4c52c12
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add [erase,walk]_by_layout_new to use optimised implementations of the
erase function selection algorithm.
Change-Id: Id79ae943eb9d6a817da28381db477725834faaf6
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71173
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As part of a GSoC project to optimise the erasure path in flashrom
a completely different algorithm is used to perform erasure. Therefore
we need a mechanism to have the two implementations side by side to
allow for A/B testing and easy reverts should issue arise.
Change-Id: Ib5660db0067c1c799dcb5c8e83b4a4826b236442
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71119
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The dummyprogrammer in the opaque case can have a NOP delay
to avoid wasting CPU time and energy.
BUG=b:266014935
TEST=builds
Change-Id: Ia86ad21f011214abc2aa0891a43559f91e2a9591
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72424
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only picked up by internal test infra in ChromeOS when
instrumenting futility(1).
The following error was incured,
```
>> Starting firmware updater.
>> Target image: images/bios-kindred.ro-12672-141-0.rw-12672-141-0.bin (RO:Google_Kindred.12672.141.0, RW/A:Google_Kindred.12672.141.0, RW/B:Google_Kindred.12672.141.0).
INFO: update_firmware: Loading current system firmware...
INFO: load_system_firmware: flashrom -r <IMAGE> -p host
Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
read_flash: cannot read inside Management Engine region (0x001000..0x3fffff).
Read operation failed!
ERROR: do_update: Cannot load system active firmware.
```
despite the appropriate flag being set within futility(1).
BUG=b:266748702
TEST=cros fw updates.
Change-Id: Ie04cd62020ca29775fc66a81d2fadd32a5aab5cd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72454
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The full writeprotect implementation has proper support and
ability to unlock flash over spi25_statusreg.c. Therefore if
the required bits are available for the given chip prefer
proper writeprotect support instead of adhoc spi25_statusreg.c
helpers.
BUG=b:237485865
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`
TEST=Tested that chips without WP support can still be unlocked
by deleting decode_range for W25Q128.W flashchip and
retesting on the grunt DUT.
Change-Id: I74b3f5d3a17749ea60485b916b2d87467a5d8b2f
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69517
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: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
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>
The 'all_skipped' global state can be made into a function
parameter if one just follows though the CFG. Running
`flashrom -p dummy:emulate=SST25VF032B,image=r.bin -w r.bin` displays
the message "Warning: Chip content is identical to the requested image."
Change-Id: I2346c869c47b48604360b0facf9313aae086c8dd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Co-authored-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67093
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Validate (flash->chip->bustype == BUS_SPI) as ich copies the
chip flags in the opaque master and tries incorrectly
to issue 4BA commands which results in failure.
The issue was detected only in the case of chips >16MB, in
this case 'W25Q256FV' that has the feature bits:
```
.feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_4BA_ENTER_WREN |
FEATURE_4BA_EAR_C5C8 | FEATURE_4BA_READ | FEATURE_4BA_FAST_READ |
FEATURE_WRSR2,
```
The regression was noticed from,
commit 0741727925b841c2479b993204ce58c5eb75185a ichspi.c: Read chip ID and use it to populate `flash->chip`
TEST=In the case of 'W25Q256FV' on TigerLake.
Change-Id: I7cce4f9c032d33c01bf616e27a50b9727a40fe1b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-by: Sam McNally <sammc@google.com>
Skip unwritable regions if FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS is
true. If the flag is false, erase operations that include an unwritable
region will not erase anything and return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -E on dedede (JSL)
Change-Id: If027a96a024782c7707c6d38680709a1a117f3ef
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/+/70517
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Make write_flash() skip unwritable regions if
FLASHROM_FLAG_SKIP_UNWRITABLE_REGIONS is true. If the flag is false
write operations that include an unwritable region will not write
anything and return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -w on dedede (JSL)
Change-Id: Idacf0d5218da9d9929f4877fc7665fe608b87fe0
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/+/70516
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Update the check_block_eraser function to use probe_opcode to see if the
given block_eraser is supported by the spi master. This will help to get
a real count of usable block_erasers.
Change-Id: I6591a84ae1fe5bc1648051cc30b9393450033852
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66717
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make verify_flash() skip read/write-protected regions based on the
FLASHROM_FLAG_SKIP_UNREADABLE and FLASHROM_FLAG_SKIP_UNWRITABLE flags.
If FLASHROM_FLAG_SKIP_UNREADABLE is false, read-protected regions will cause
verification to fail.
If FLASHROM_FLAG_SKIP_UNWRITABLE is false, read-only regions will still
be verified and any mismatch will cause verification to fail. It can be
useful to set the flag to true so that expected mismatches in read-only
regions are ignored by verify_range() after flashing.
BUG=b:260440773
BRANCH=none
TEST=flashrom -v on dedede (JSL)
Change-Id: I61dfadd3c75365f2e55abeea75f673ab791ca5cc
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/+/70515
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Skip read-protected regions if FLASHROM_FLAG_SKIP_UNREADABLE_REGIONS is
true. If the flag is false, read operations that include an
read-protected region will return an error.
BUG=b:260440773
BRANCH=none
TEST=flashrom -r on dedede (JSL)
Change-Id: I22c795d7d08ef8bf773733d9952967b2fa2ef299
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/+/70514
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 romentry structure is the container ADT with some
annotated meta-data such as 'included' or 'file' however
the substantive substructure is a 'flash_region'. Therefore
factor this out.
That is to say, the link list node 'romentry' is obscured by the implementation details of its use-case of 'flash_region' that we
clear up here.
BUG=b:260440773
BRANCH=none
TEST=flashrom_tester
Change-Id: I768742b73db901df5b5208fcbcb8a324a06014c2
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69196
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Replace `programmer_delay(NULL, [..])` calls with direct
`internal_delay([..])` dispatches explicitly. Custom driver
delays remain hooked as well as core flashrom logic. The
NULL base case of 'programmer_delay()' then becomes a condition
to validate for layering violations or invalid flash contexts.
Change-Id: I1da230804d5e8f47a6e281feb66f381514dc6861
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68434
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Handle the special cases of both serprog and ch341a_spi.
Also rewrite programmer_delay() to handle the two base
cases of zero time and no valid flashctx yet before
handling per master branching.
Additionally, modify the custom delay function pointer
signature to allow closure over the flashctx. This allows
driver specific delay implementations to recover programmer
specific opaque data within their delay implementations.
Therefore programmer specific delay functions can avoid
programmer specific globals.
Change-Id: Id059abb58b31a066a408009073912da2b224d40c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Do not just exit in the middle of the process, rather return
a value back up to the caller to allow proper resource cleanup's
to occur.
Change-Id: Ie4186a40071e9a7296d601582ff15ad7df09c70a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69474
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The 'chip_safety_check()' already validates the chip structure
within 'prepare_flash_access()' before all subsequent chip operations
such as 'verify_range()' and therefore the chip structure is
guaranteed to be valid in the domain of those operations.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ifc57dd89715115e03d013691352463a8b3c0dc52
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69471
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fallback_{un}map() boilerplate code doesn't do anything,
merely distracts away from otherwise linear control flow. Just
drop it as anything in the future that could need such a thing
is free to implement it when required.
Change-Id: Ibb7760f807fae040416cef2797a7dbf6572f7df9
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68963
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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.
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>
