Probing v2 can (if requested) go through all flashchips and find
all the matching chip definitions. This is the way cli behaves,
so cli becomes a client of probing v2.
Previously cli and libflashrom had different probing logic, and
different code in different source files.
This patch also adds tests for probing v2.
Testing from the cli:
./flashrom -p dummy:emulate=W25Q128FV -r dump.rom
./flashrom -p dummy:emulate=MX25L6436 -r dump.rom
./flashrom -p dummy:emulate=MX25L6436 -c "MX25L6473E" -r dump.rom
./flashrom -p dummy:emulate=SST25VF032B -E
./flashrom -p dummy:emulate=S25FL128L -r dump.rom
./flashrom -p dummy:emulate=INVALID -r dump.rom
./flashrom -p dummy:emulate=MX25L6436 -c "NONEXISTENT" -r dump.rom
Change-Id: Idfcf377a8071e22028ba98515f08495ed2a6e9f0
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
There were no options available to obtain the list of programmers.
The implementation is based on flashrom_supported_flash_chips.
Arrays of constant strings are returned, and the array must be
freed using flashrom_data_free.
Testing: Both unit tests and CLI tools serve as libflashrom clients.
All unit tests run successfully.
Change-Id: Ib5275b742b849183b1fe701900040fee369a1d78
Signed-off-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86921
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Before this commit, any message from Flashrom would trigger
the user's callback. This could lead to additional delays
and slow down overall Flashrom performance.
This patch adds the ability to configure the log level for
messages from Flashrom. It sets the default log level to INFO
Testing: Both unit tests and CLI tools serve as libflashrom clients.
All unit tests run successfully.
Change-Id: I095d48b8feb5fbc950a36eb17bed0d7cb8d9df64
Signed-off-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87047
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The initial implementation does not account for user_data, requiring
the calling application to use a global scope. This may lead to issues
related to object lifecycle management and other architectural
concerns.
This patch adds user_data to the user’s log callback. Moreover, it
performs message formatting, so the application only needs to pass
the formatted string to the selected output.
The change does not break the existing logging API but extends it.
A new API version is introduced with the v2 suffix.
Testing: Both unit tests and CLI tools serve as libflashrom clients.
All unit tests run successfully.
Change-Id: Iea738bd371fa3d69b9cf222c89ee67490d30af39
Signed-off-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86875
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 75dc0655b9 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>
This is a simple refactor that aims to simplify maintenance and to
clarify file dependency inside the project.
Currently, many declarations reside in flash.h making it difficult to
really understand file dependency.
Change-Id: I4209d5ed205ca14c39e83aa923e103b7282a7059
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85134
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Make the filename parameter directly following -r/-w/-v optional, since
the -i parameter allows the image to be written to be sourced from
multiple files, regions to be read from flash and written to separate
image files, and regions to be verified using an image file only
containing that region.
Since the filename parameter following -w/-v was ignored when a
filename was specified following `-i <region>:<filename>`, this patch
essentially removes the requirement to provide an unused parameter.
Based on https://review.coreboot.org/c/flashrom/+/52362.
TEST=run the following commands on a supported board:
flashrom -p internal -r /tmp/coreboot.rom
flashrom -p internal -r --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -r /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
flashrom -p internal -w /tmp/coreboot.rom
flashrom -p internal -w --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -w /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
flashrom -p internal -v /tmp/coreboot.rom
flashrom -p internal -v --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -v /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
Change-Id: I6eba095d478f1a7bdbc3854627a656f93dd9e452
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85159
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>
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>
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>
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>
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>
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>
