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>
The STLinkV3 Mini does not support the bridge API,
it return LIBUSB_IO_ERROR when querying
the bridge version. The official ST updater does
not lists the bridge version in the info screen.
Due to it's construction (additional connector on the
bottom) it is likely that ST disabled the bridge functions
on the castellated pads.
Change-Id: Ic1ea4ca7acedca5d374cff8fcef450c18e55a9e8
Signed-off-by: Miklos Marton <martonmiklosqdev@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83921
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the latest pciutils(v3.13.0), it supports accessing pci registers
by ecam. This patch uses libpci version check to decide whether
flashrom calls libpci and use 0xcf8/0xcfc or ecam to access pci
registers.
BUG=b:359813524
TEST=with libpci >= 3.13.0, flashrom is working with ECAM access
Change-Id: I4549f87c8b01da0a1d3d8ce0b3b75c1f5fa2cbab
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
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>
GD25LB512MF: 1.8V 512Mbit shipped with Quad enabled.
https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20231213/DS-01012-GD25LB512MF-Rev1.0.pdf
GD25LR512MF: all GD25LB512MF features + RPMC feature
The datasheet is identical with GD25LB512MF for the NOR flash side.
Tested both models on ch347 with erase, read, write, and protection.
Change-Id: I6a0061a43af5966c93c95645b51a640c00f3d829
Signed-off-by: Victor Lim <vlim@gigadevice.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83899
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
As was described in the version 1.4 release notes, this deletes the
Makefile and supporting elements leaving Meson as the only supported
buildsystem.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: Ib3cf22cf636ef9b70527b734ffa34aead2a74edd
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
added GD25LF256F on flashchips.c
added GIGADEVICE_GD25LF256F=0x6319 on flashchip.h
GD25LF256F is a higher performance 1.8V 256Mbit SPI flash
I have tested on CH347 with erase, program, read, protection.
Change-Id: I21a71606476e823faa38a7920aa2b10e25d68d26
Signed-off-by: Victor <vlim@gigadevice.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This document is converted from Technology page on wiki
https://wiki.flashrom.org/Technology
Change-Id: I93107d6b5530c301dd90f7177758632d9d1810eb
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83584
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The page on wiki is here:
https://wiki.flashrom.org/ISP
Change-Id: If4752f0f02ae973b3d832f42166de643d95c9f97
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83451
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
The wiki is moving around, and the URLs are probably not final. Until
the download locations can be nailed down to their final location, tell
curl to follow HTTP redirects.
Change-Id: I52f1c786a376f5c7394fa5bffc689e58f8691c75
Signed-off-by: Patrick Georgi <patrick@coreboot.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83672
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
These programmers have a little information about them on wiki.
It's too little info to create a dedicated page for each
programmer, however info can go to the manpage.
For reference, wiki pages are the following:
https://wiki.flashrom.org/NIC3Comhttps://wiki.flashrom.org/Gfxnvidiahttps://wiki.flashrom.org/Supported_programmers (search for the
programmers in the table).
Change-Id: Id2a2aefc6a3c8348fdaa4498aaa704fd2da7602f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83467
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
