The header only defines getop related stuff so it seems more intuitive
this way.
Change-Id: Iaceeabedc26e93147d8122376d88e730aad1e355
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85072
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This needs libcrypto dependency to be present on CI container.
Change-Id: Ib736386a34d184f696a47272957b665c8fe26c06
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This entry in the flashchips represent a "SFDP-capable chip" and
it doesn't make sense to show the message "WP operation has status
untested, please report this". The entry can cover any generic
SFDP chip and what would you report?
Secondly, the entry "SFDP-capable chip" does not currently support
WP operations anyway.
Going further, we will be working with SFDP way more, so this area
needs to be gradually upgraded.
Testing:
flashrom -p dummy:emulate=MX25L6436 -c "SFDP-capable chip" -r dump.rom
Change-Id: I7e945389895a8042df3aaae72bccf73405be8651
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85075
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Matti Finder <matti.finder@gmail.com>
This commit adds uses the new rpmc command implementation to
add them as a new feature to the cli_client.
Also adds the necessary documentation for this new feature.
Tested on the Winbond W25R128JV as a 'SFDP-capable chip'.
This patch was done to add rpmc command support to flashrom.
This enables users to write root keys to their flash chips while they
flash data on the chip. This might become useful in the future as rpmc
support is extended in coreboot.
Also adds debug tools to flashrom, which might be useful in
implementing coreboots rpmc support.
Change-Id: I36c823bbee65f256eb6edabe6f058321c9a0cfa1
Signed-off-by: Matti Finder <matti.finder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84840
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Added optional support for all the commands specified in JESD260.
Added a new optional dependency to openssls libcrypto.
Added parsing for the rpmc parameter sfdp table.
Added necessary rpmc parameter information to flashchips struct and the
flash hardening feature to enable rpmc commands.
Enables future use of these commands in the cli_client and also
libflashrom.
Change-Id: I6ab3d0446e9fd674b20550fdbfaf499b8d4a9b38
Signed-off-by: Matti Finder <matti.finder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84934
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I used W25Q256JW as a template and just increased every erase size
calculation.
Datasheet can be found by form contact only via
https://www.winbond.com/hq/product/code-storage-flash-memory/serial-nor-flash/?__locale=en_TW&partNo=W25R512NW
I tested it by running:
dd if=/dev/urandom of=/tmp/random.bin bs=1M count=64
sudo /tmp/flashrom/build/flashrom -p ft2232_spi:type=2232H -w /tmp/random.bin --progress
sudo /tmp/flashrom/build/flashrom -p ft2232_spi:type=2232H -v /tmp/random.bin
And I saw "Verifying flash... VERIFIED."
Change-Id: Ibf670e4014a22e4636789768b759cb51f75cd046
Signed-off-by: Alexandru M Stan <ams@frame.work>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84752
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This is a simple refactor that aims to simplify maintenance and to
clarify file dependency inside the project.
Currently, most of the declarations reside in programmer.h making it
difficult to really understand file dependency.
Change-Id: I9d819ea1c5bd51289d02189c1dff367ce6d25617
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Miklós Márton <martonmiklosqdev@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add detection of Tiger Point chipsets based on SPI controller PCI ID.
Current detection is based on ESPI PCI ID only which limits the
flashrom operability to 2 out of many chipset variants.
TEST=Read flash on a platform with Intel Corporation Tiger Lake-LP
SPI Controller [8086:a0a4] and ISA bridge [0601]: Intel Corporation
Device [8086:a088] ESPI device.
Change-Id: Ie6859d81157760ca03fe34ba5ac311eba5a7c46b
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84987
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
gitiles are not always available, so the link was not always working,
which could make readers confused.
While we are here, add missing link to Dev Guide.
Change-Id: I9103e5199bdf1b65fa3136aa01259a85e788a251
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84960
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Starting with version 19, clang issues a warning when using `strlen()`
for initializing a static array's size. This causes the build to fail as
the project also sets `-Werror`.
This is fixed by using `sizeof()` instead, which is guaranteed to be
evaluated at compilation time and therefore not triggering the
problematic warning.
Change-Id: If470a65702e9ae08e4303123a0014e53a1fee56e
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84856
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The patch adds command line option to handle the following situation:
There is a region which is requested to be erased (or written, because
the write operation uses erase too). Some of the areas inside this
region don't need to be erased, because the bytes already have expected
value. Such areas can be skipped.
The logic selects eraseblocks that can cover the areas which need to be
erased. Suppose there is a region which is partially covered by
eraseblocks of size S (partially because remaining areas don't need to
be erased). Now suppose we can cover the whole region with eraseblock
of larger size, S+1, and erase it all at once. This will run faster:
erase opcode will only be sent once instead of many smaller opcodes.
However, this will run erase over some areas of the chip memory that
didn't need to be erased. Which means, the chip, as a hardware, will
wear faster.
New command line option sets the maximum % memory that is allowed for
redundant erase. Default is 0, S+1 size block only selected if all the
area needs to be erased in full. 50 means that if more than a half of
the area needs to be erased, a S+1 size block can be selected to cover
all area with one block.
The tradeoff is the speed of programming operation VS the longevity of
the chip. Default is longevity.
Change-Id: I154e8a713f626c37dbbe118db700055b96d24803
Co-developed-by: persmule <persmule@hardenedlinux.org
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: persmule <persmule@hardenedlinux.org>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.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>
If hardware protection is requested but not supported by the flash
chip, return an error code indicating that the protection mode is
unsupported, rather than indicating that all WP features are unsupported.
TEST=ninja test
Change-Id: I29e9069c7781fbb238f30aa9a9285b692b0c7200
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch updated the VERSION file itself, and the document on
release process.
Change-Id: I2bd2e57e42c29ea5a9d8bc334b86c6fa5c4b46a4
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Previously the logic which selected large block did deselect of
smaller blocks, but only one level below. So some even smaller blocks
could still remain selected, and this would result in duplicate erase.
This patch deselects all smaller blocks of all levels below, down to
the smallest size. If the area is covered by one large block, no
other smaller blocks inside are needed.
Change-Id: Icfc18d5c090b1dcb92ab157e2c139be71af59300
Spotted-by: persmule <persmule@hardenedlinux.org>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-authored-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84686
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A larger (not the smallest) erase block used to get erased when half
of sub-blocks it contains need erase, which has at least 2 issues:
1. The rest half of sub-blocks that do not need erase are also erased,
introducing some erase overheads.
2. More severely, since this logic only selects a block and delects
its sub-blocks when half of sub-blocks need erase, but this logic
does not deselect "nested sub-blocks (sub-blocks of sub-block)" not
reach the limit under this block, the logic may cause duplicated
erase. For example, if a erase block (often the largest one
corresponding to the whole chip) has half of its sub-blocks and
some incontiguous nested sub-blocks needing erase, these double
sub-blocks will end up being erased twice, introducing even more
erase overheads than whole-chip erase.
The older behavior of flashrom before adding erasure_layout.c, when no
communicational error occurs, will neither erase blocks that do not
need erase, nor cause duplicated erase. Higher efficiency should be
achieved without introducing extra erase overheads, by allowing
combining contiguous small erase blocks only when they can
coincidently form a larger erase block.
Change-Id: I9e10749186e395da67ec80e296119f33c3f83122
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84614
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
ich_spi_send_command() and ich_spi_send_multicommand() will overwrite
the "Sector erase" opcode with the opcode for command via
reprogram_opcode_on_the_fly(), but not restore it, causing the "Sector
erase" opcode may get lost after sending commands, leaving only "Bulk
erase" opcode which erase the whole chip available.
In the mean time, ich_spi_probe_opcode() used not to report opcodes in
POSSIBLE_OPCODES[] but not in curopcodes->opcode[] as supported.
Now, if the opcode being probed is not in curopcodes->opcode[] but in
POSSIBLE_OPCODES[], it will be reported as supported, and programmed
later by ich_spi_send_(multi)command().
Fix:https://ticket.coreboot.org/issues/556
Change-Id: I3fc831fc072e2af9265835cb2f71bf8c222c6a64
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84253
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
There seems no problem to use ich_spi_probe_opcode() for
spi_master::probe_opcode() on ich7, so we may merge former
spi_master_ich7 and spi_master_ich9 into spi_master_ich, for both
init_ich7_spi() and init_ich_default().
Change-Id: I6a65c97e910622a55da7cef8a10de3af6a99c9e8
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84593
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
POSSIBLE_OPCODES[] is never modified, so mark it as read-only.
Change-Id: I217f8a9e50b9e2e9f2731adec89a46780874c754
Signed-off-by: persmule <persmule@hardenedlinux.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84595
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
The function for reprogramming on the fly was using the default
configuration O_ST_M25P as a base and the position 2 as the position
to reprogram. Position 2 corresponds to JEDEC_SE which is often useful
for chip erase (when less than whole chip needs to be erased).
This patch changes the default position to reprogram to 4, which
corresponds to JEDEC_REMS. It is used less often, but if it needs to
be used, it will be discovered missing and reprogrammed back.
For erase opcodes, there is usually several of them available. So if
one is missing, erase still can be performed with the remaining ones.
However, this hides the fact that one of available erase opcodes is
missing (it won't be reprogrammed back), and also it gives non-optimal
erase layout.
Context: https://ticket.coreboot.org/issues/556
Change-Id: I6bc855daedf0af2e8de191f23a3512de3ebc3fef
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84567
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
meson's default behavior is to install subprojects, so because we use a
wrap to get cmocka if needed and the cmocka wrap sets install=true
unless cross-compiling, cmocka headers and libraries will be installed
by `meson install`. This isn't useful (because cmocka is used only for
tests which don't get installed), and can cause install errors in some
configurations.
meson can be told to never install subprojects with `meson install
--skip-subprojects` which solves this, but is inconvenient because that
option must be specified on the command line and there is little hope of
meson's default behavior changing [1].
To fix this, I've replaced `patch_url` for the wrap with an included
`patch_directory` instead, which was created by unpacking the original
archive pointed to by `patch_url` and setting `install : false` in
src/meson.build.
A more concise option to make the same change would be to make the
change to the `install` option in a new patch specified via `diff_files`
(which works because patches from `diff_files` are applied after
applying the `patch_*` archive), but `diff_files` is not supported by
Meson before version 0.63.0 which would require increasing flashrom's
minimum meson version from the current 0.56.0. This seems too new, since
meson 0.56 was released in October 2020 while meson 0.63 was released in
July 2022.
[1]: https://github.com/mesonbuild/meson/issues/10561#issuecomment-1444059473
BUG=https://ticket.coreboot.org/issues/561
Change-Id: I15f549175e2d5d52979814d7f7530da868871ce8
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84557
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Without the header being explicitly included, scan-build run on CI
was returning errors for these files, such as:
include the header <stdlib.h> or explicitly provide a declaration
for 'calloc'
The functions in question were calloc, free, etc.
Change-Id: I4b79c5f86c074c456533296c309293e4064abe3f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84455
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From page:
https://wiki.flashrom.org/FT2232SPI_Programmer
The sections about openbiosprog-spi, RushSPI, Amontec have broken
links and are not added to this patch. If we find out where these
project live now (if they still are active), would be good to add
the info later.
Change-Id: Id30b6c92838d7ca6e26a4cc3e0aeeb3f3ce07668
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83866
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The existing page on old wiki is very small and fits into
a manpage item:
https://wiki.flashrom.org/NICIntel
Change-Id: I139065611c68c0fa0a675fe49a6f8bc20e9057f7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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>
Fix a segmentation fault that is caused by accessing an invalid
"subedata" pointer on the last iteration of the init_eraseblock loop.
Instead, short circuit the loop condition to check the sub block index
first, and do not access the invalid pointer if it is the last sub
block.
Issue was encountered in:
- OS: OpenBSD 7.5 amd64
- Compiler: clang 16.0.6
- Chip: Macronix MX25U6435E/F
BUG=https://ticket.coreboot.org/issues/555
Change-Id: I61bf0d93aa9f0b2b420b146be16fcd5124f0dc5d
Signed-off-by: Grant Pannell <grant@digitaldj.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84234
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: DigitalDJ
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Based on public Intel 700 Series PCH datasheet, DOC 743835 rev 004.
The IDs of IoT chipset SKUs (ending with E) can only be found in "12th
Gen Intel® Core™ Processors Family (Formerly Known as Alder Lake -S)
for IoT Platforms External Design Specification (EDS) Addendum" DOC
634528 rev 2.7 (NDA).
TEST=Probe flash on Z790 chipset. Run the ich_descriptors_tool and
check the output is correct as expected.
Change-Id: I13ac52d5400c0e2260e12d605077fc2182c379ef
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
The patch adds new functionality to the test: tracking the areas of
chip memory that were modified (i.e. by erase or write operation),
and then checking those areas were completely covered by verify
operation.
The test operates over the mock chip memory of 16 bytes, so it is
possible to track each byte which was modified, and assert that is
has been verified afterwards.
Adding the test found a bug which is fixed in this commit:
Post-cleanup after processing unaligned region for the case when end
region needs to be extended to align with erase block. Writing was
done correctly, but post-processing of newcontents could cause
one-off offset at the end of the region, which would make
verification appear false-negative (see test cases #16-19).
Change-Id: I3c5d55a0deb20f23f4072caac8c0dce04cc98fd4
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84078
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
This makes flashrom sleep more eagerly rather than busy-waiting,
observing that most delays in flashrom are either less than 100
microseconds (barely enough time to get any work done, even on a fast
machine) or much more than 1 millisecond (very wasteful to busy-loop).
Since we believe most systems offer good timer resolution that should
provide sleep latency on the order of 100 microseconds, this is a
reasonable default.
For DOS, the default is set to 50ms because the best available timing
source on DOS only ticks at about 20 Hz.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I0f431d240c670446218b14811ef62a34e4c83da2
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
CH347 SPI interface supports up to 60M.
For example, to set a 30M spi rate, use -p ch347_spi:spispeed=30M.
Change-Id: If2be48929db540a6598ac0b60b37e64597156db7
Signed-off-by: ZhiYuanNJ Liu <871238103@qq.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82776
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
removed FEATURE_WRSR_EXT2 from the model after datasheet review.
replace
printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP3_SRWD,
.unlock = SPI_DISABLE_BLOCKPROTECT,
with
.printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD,
.unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD,
GD25B256E: 3V 256Mbit, Quad enabled.
GD25R256E: GD25B256E features + RPMC, so they share the same datasheet on flash side
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230627/DS-00658-GD25B256E-Rev1.1.pdf
Tested both models on ch347 with erase, write, read and protection.
Change-Id: Ie733e0c2e35fa4797f5198f2c8334469b65f402c
Signed-off-by: Victor Lim <vlim@gigadevice.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83998
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Both of these chips were tested in-circuit with an SOIC-8 clamp and two
different BusPirate boards: the BPv3.6 from Adafruit (sku 237) and the
BPv3.6a from Sparkfun (sku TOL-12942), on a Fedora 38 host, using
flashrom 9a570318 (changes rebased since then).
Change-Id: Ib3c94f03a132a912bb4bb9d36e8783f4468587c4
Signed-off-by: Samantaz Fox <coding@samantaz.fr>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83970
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
