The main purpose is to run one operation after the other to
check that data is carried in flash context correctly.
As the most common chains, the first tests perform:
probe+read
probe+write
probe+erase
Change-Id: I9b09e04c7dbee7e7658118d66aacb640885f4d23
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88257
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
TEST=ich_descriptors_tool is able to detect "wildcat" chipset and show
below information:
> ./util/ich_descriptors_tool/ich_descriptors_tool
Need the file name of a descriptor image to read from.
usage: './util/ich_descriptors_tool/ich_descriptors_tool -f
<image file name> [-c <chipset name>] [-d]'
...
...
To also print the data stored in the descriptor straps you have to
indicate the chipset series with the '-c' parameter and one of the
possible arguments:
- "ich8",
- "ich9",
- "ich10",
- "apollo" for Intel's Apollo Lake SoC.
- "gemini" for Intel's Gemini Lake SoC.
- "jasper" for Intel's Jasper Lake SoC.
- "meteor" for Intel's Meteor Lake SoC.
- "panther" for Intel's Panther Lake SoC.
- "wildcat" for Intel's Wildcat Lake SoC.
...
...
- "300" or "cannon" for Intel's 300 series chipsets.
- "400" or "comet" for Intel's 400 series chipsets.
- "500" or "tiger" for Intel's 500 series chipsets.
- "600" or "alder" for Intel's 600 series chipsets.
Change-Id: I2957eab19d8b8fdd2479f7d1b50ecdb48f491954
Signed-off-by: Varun Upadhyay <varun.upadhyay@intel.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88049
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We identified somebody whose name was malformed in git history such that
they were credited wrong in the hall of fame, so add some code to handle
names that manage to be committed with incorrect formatting.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I33b04932403b2d69da4648a3a7016aee57741d0d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88477
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Building authors/reviewers list (aka Hall of Fame) requires
more modern sphinx version than the rest of documentation. Also
we have separate meson options, `documentation` and
`generate_authors_list`, which both default to `auto`.
Auto mode is expected to check the environment and enable the
option if environment is suitable - or disable otherwise.
The patch check minimun required sphinx version specifically
for building hall of fame, the rest of documentation just checks
that sphinx is present.
So if developer has old version of sphinx, all the documentation
will be built, just without hall of fame.
Without this patch, developer with generate_authors_list=auto
(which is default) and old version of sphinx gets a build error
like this:
Exception occurred:
File "/usr/lib/python3/dist-packages/docutils/nodes.py",
line 652, in __getitem__
return self.attributes[key]
KeyError: 'colwidth'
and a stack trace from sphinx source code
Change-Id: I8f0ae62f33dca04c2c5233ea45c6263f10cbe4f9
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Previously probe_flash had the same return code for the case when
no chips were matched, and when some other error happened during
probing. However these are two different scenarios and it is useful
for the caller to distinguish between them.
In fact, the caller (libflashrom it is) wanted to distinguish
between "no chips found" and "some other probing error" from the
very beginning. libflashrom probe API documented returning special
error code for "other error".
However it was not possible to know when "other error" happened
because probe_flash never returned that back, it could only say
"no matched chips found".
This patch introduces -2 as "other error" code from probe_flash,
while -1 remains as "no chips found".
Both libflashrom probe APIs v1 and v2 are now handling "other error"
from probe_flash and return it to the API callers as was promised in
the documentation.
This also adds a unit test for error code propagation for "no chips
found" error.
Change-Id: I4a271550bea2b36c657c71ce6cb1927082663c3c
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88008
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Current method modifies the optarg string and
causes it to not get printed in future debug log.
For example writing the log to a file with -o
will show "Command line" without the size
parameter of the range.
Tested by logging the output and reading the log:
./flashrom -p linux_spi:dev=/dev/spidev0.0 -c "W25Q64JV-.Q" \
--wp-range 0x0,0x00001000 -o logfile && grep 'Command line' logfile
Change-Id: I77acd49a5fa17a0af69b4fb1371a131a5249d3dc
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/88162
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
More delay time is needed to stabilize the LDO and the decoupling
capacitors when power on feature is enabled. Specifically 100 ms
was tested on HT7333 and it's sufficient.
I used the power supply from the J-Link device pin 19.
this power is 5V, I put a 3.3V LDO (HT7333) after it, and this LDO
(and decoupling capacitors) need more time to fix output voltage.
Change-Id: Ic2dd94e99ac6ffa17a009b8488ce027698ae2c28
Signed-off-by: Attila Veghelyi <aveghelyi@dension.com>
Tested-by: Attila Veghelyi <aveghelyi@dension.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86085
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When using the on-chip FMAP to restrict flashrom operations to one or
more regions (--fmap), flashrom must first locate the FMAP. This
requires flashrom to read from multiple addresses, some of which
may be located in regions which are not readable (such as the
Intel ME region). In order to avoid a substantial amount of output from
read_flash() when trying to locate the FMAP in these regions, set
`the skip_unreadable_regions` flag before performing any reads to
locate the FMAP, and restore the original flag value when finished.
This resolves https://ticket.coreboot.org/issues/587
TEST=build flashrom, use cli to update COREBOOT and EC FMAP regions on
an Intel Alderlake-N platform board (starlabs/starlite_adl).
Change-Id: Ie78b977b4e6a5db02a25e69603f697834043ea99
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87748
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The only purpose of array of 8 flash contexts was to facilitate
probing of multiple chips. Probing is now done inside libflashrom,
and cli as a client of libflashrom only need to have one active
context.
In addition to array of 8, cli also had one more flash context,
`fill_flash` which is also now replaced by the same, one active
context.
Another detail is that array of 8 was effectively a limit of how
many mathing chips could be found. While 8 seemed a lot at the time
of initial implementation, at the moment we have an example of
6 matches already.
(see `./flashrom -p dummy:emulate=MX25L6436`)
Change-Id: Ia4284ae7aaa43fe59f0d3f57314ebc5cc93d2d9b
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87533
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
This log level is the maximum level that will trigger the log
callback. By default log callback should be triggered for all
messages, and then client can decide whether they want to lower
the level.
This also keeps the same behaviour for existing clients of
libflashrom, the same as it was before introducing the ability
to set max log level in log callback API.
Follow up on
commit 4e334c4f79
Change-Id: Id063c31e685c930b9f5632c7b86ffac6fe477fd5
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87180
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Follow up (or fix) on
commit 6571f263b5
which adds ability to set maximum log level to log callback API.
And INFO as the default.
Without this patch cli options -V, -VV, -VVV not working anymore.
cli at the moment processes all the messages in the callback,
so log level should be maximum possible to get all the messages.
Alternative to this could be setting the default max log level
for callback as SPEW.
Tested by running with -V, -VV, -VVV
flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -r dump.rom --progress
Change-Id: I70a02ea1a1d692267fd6d92cdb5273786a913777
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.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>
Mark both B150 and Q170 as tested (DEP, as writability depends on the
flash descriptor). B150 was found in a ThinkCentre M700 Tiny, and Q170
in a ThinkCentre M900 Tiny, both support internal flashing once coreboot
is flashed (and coreboot SPI flash lockdown is not enabled).
Change-Id: Iedf4c77e3228628ac1a8726c1a9b4fb733d63d40
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87045
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.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>
- Update the base system (alpine 3.8 -> 3.21)
- Update sphinx and its modules (and from pip-install to alpine-install)
- Remove unused features that increase maintenance overhead
(autobuild/livehtml and ditaa)
- Use the build system to generate docs (instead of calling sphinx in
its own, custom ways)
Change-Id: I844e4ea84b94444c96f29325fee205b0deb972da
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86681
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a build-time option to automatically generate a list of
authors from git history, and includes it in the documentation by
reading the output from git in a Sphinx extension. When git isn't
available or the project source doesn't appear to be a git checkout, the
list is not generated and gracefully replaced with a message explaining
its absence.
Change-Id: I1e9634a90e84262aafd80590deba9875f4b71a3c
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
