This change extends the ich_descriptors_tool to recognize and process
descriptors for Intel's upcoming Panther Lake SoC.
BUG=b:347669091
TEST=ich_descriptors_tool is able to detect "panther" 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.
...
...
- "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: I17d616d346daca15b43eb294401ac0c672b64c4a
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83149
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Recently Android Bionic LibC got sys/io.h. Use this header to access
ioperm(). Use Assembly for I/O, as Bionic does not have inb(), outb(),
etc.
Tested on Android 14 by adding flashrom and pciutils as external repositories, adding Android.bp blueprints (Android specialized build system - Soong), building, running and accessing (read, erase, write) SPI flash on x86 device.
Change-Id: Id80b83c2718679c925ed6ddfe33cbe837eea0429
Signed-off-by: Jakub Czapiga <czapiga@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83133
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Without this, default value is the first in enum, which is OK. While
in reality, for the chips in the patch block-protection is not
available, so should be NA.
wp test status support was introduced later than the others, so old
chips don't have this field initialised.
Change-Id: I6ed8e04cd215865dc6a7d9415634dedbe3014ab5
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83132
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This also expands the column for test status by 1 more char, since
now maximum status is longer, PREWB vs PREW.
print.c runs when command line option `flashrom -L` is invoked.
Change-Id: If697fe3ba93dbe34bb8f7a9a4b1686fdb8b3ee58
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83131
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
commit hash 85b977151b8f57 (ichspi.c: Add support for region 9 and
beyond in Meteor Lake) moved the Intel Meteor Lake macro in
programmer.h, causing flashrom to display an incorrect chipset name
for Meteor Lake platforms.
This patch updates the corresponding chipset_names index to resolve this
issue.
TEST=Verified correct chipset name in flashrom output for Meteor Lake
chipset (google/rex0 board).
Change-Id: Ic09cf0474c980369bcbf90924d45f697bc1b0a0d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83143
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Current numbers are taken from the output of `flashrom -L` command.
Intro page still has a room for improvement, but as a first step the
numbers need to be updated. In future, maybe there is a way to update
the numbers less manually.
Change-Id: I7531521955dcf01348ed2ba9c54316b32b9cd925
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83130
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds two lines at the very end of the section with supported
deviced per programmer. At the moment of this patch, numbers are:
Supported USB devices, total 30
Supported PCI devices, total 94
All other sections print total numbers, this was only one missing.
Change-Id: Ie011db3985172d05f5160d1cb1cc39a4422a5750
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83129
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When flash regions are protected, erase could incorrectly erase regions
which were meant to be protected by requesting the correct size but
using an erase opcode with coarser granularity than desired (for
instance using a 16-byte erase command while attempting to erase only 8
bytes).
This fixes that by exchanging the nesting of the loops over erase blocks
and flash regions.
Old:
- Select erasefns
- Loop over blocks to erase for each selected erasefn
- Loop over programmer flash regions within erase block
- Erase regions (may fail since selected erasefn will be
too big if flash region is smaller than erase block)
New:
- Loop over programmer flash regions within erase block
- Select erasefns within programer flash region
- Loop over blocks to erase for each selected erasefn
- Erase regions
Eraser selection and erasing has also been factored out into a helper
function to manage nesting depth.
TEST=New test cases pass, whereas some of them fail without the changes
to erasure_layout.c
BUG=https://ticket.coreboot.org/issues/525
Change-Id: Ic5bf9d0f0e4a94c48d6f6e74e3cb9cccdc7adec9
Co-authored-by: Nikolai Artemiev <nartemiev@google.com>
Co-authored-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82393
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
ME page existed on wiki here https://wiki.flashrom.org/ME
The contents are mostly unchanged, but one broken kernel link is
removed from Intel doc.
Change-Id: I79af5674f3af9ca880e89becd6a272a2cf8ed599
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82649
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
CH347F can work simultaneously with SPI, I2C and other signals.
CH347 introduce is available at the following URL:
https://www.wch-ic.com/products/CH347.html
Change-Id: I693baf1a0d9dc20757f56fba626b5f5ad20f71dd
Signed-off-by: ZhiYuanNJ Liu <871238103@qq.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
The MX25R4035F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25R4035F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8671/MX25R4035F,%20Wide%20Range,%204Mb,%20v1.4.pdf
Change-Id: I91dbc4735bf232e0b1dce72c7f06be967d35ebfb
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@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>
Although chipoff_t is fairly clearly documented on its own, it seems
fairly frequent that developers will treat the end address of a flash
region as an exclusive upper bound rather than the inclusive one it
should be; for example CB:82496 fixes an incorrect use that affected
multiple sites, and CB:73571 stemmed from a similar cause. Add a
clarifying comment to call attention to this, to help programmers avoid
making similar mistakes in the future.
Change-Id: I80b61a87ca31bd5a116224aadb4e211ee6841e1f
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82677
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
In CB:81792 (CL:5471748) we add write-protect support for MX25L12833F,
MX25L12835F/MX25L12873F, and MX25L12845E/MX25L12865E.
However, that CL contained a bug that it didn't set the feature_bits
correctly. We need to add:
* Add FEATURE_CFGR and FEATURE_SCUR for MX25L12833F
* Add FEATURE_CFGR and FEATURE_SCUR for MX25L12835F/MX25L12873F
* Add FEATURE_SCUR for MX25L12845E/MX25L12865E
BUG=b:332486637
TEST=In a host connect to ADL-n ChromeOS via servo, with this patch,
flashrom -p raiden_debug_spi:target=AP,custom_rst=true
,serial=$(dut-control -o ccd_serialname -p 9996) --wp-status
returns correct WP status.
TEST=without this patch, returns error with
"Cannot read SECURITY: unsupported by chip"
Change-Id: I001cde6816bd099317bc9c23904c5fcbe6003241
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82605
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
gcc-14 added a new `-Wcalloc-transposed-args` warning. Documentation
says:
```
Warn about calls to allocation functions decorated with attribute
alloc_size with two arguments, which use sizeof operator as the earlier
size argument and don’t use it as the later size argument. This is a
coding style warning. The first argument to calloc is documented to be
number of elements in array, while the second argument is size of each
element, so calloc (n, sizeof (int)) is preferred over
calloc (sizeof (int), n).
```
Let's fix the existing occurrences.
Found-by: gcc v14.1.1 20240507
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: Icb9842fbc2fa6ad4cd9dc9384c19fd3741eadb2e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82657
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Since Meteor Lake, configuring region access for FREG9 and higher is
necessary. This configuration is determined using BIOS_BM registers:
BIOS_BM_RAP (Offset 0x118): BIOS Master Read Access Permissions.
Each bit [15:0] corresponds to a region [15:0].
A set bit grants BIOS master read access.
BIOS_BM_WAP (Offset 0x11c): BIOS Master Write Access Permissions.
Each bit [15:0] corresponds to a region [15:0].
A set bit grants BIOS master write/erase access.
Move CHIPSET_METEOR_LAKE to the bottom of the ich_chipset list to ensure
that all the newer chipsets in the future will use BIOS_BM check by
default.
BUG=b:319773700, b:304439294
BUG=b:319336080
TEST=On MTL, use flashrom -VV to see correct FREG9 access
TEST=On ADL, use flashrom -VV to see not break anything
TEST=On APL, use flashrom -VV to see not break anything
Change-Id: I1e06e7b3d470423a6014e623826d9234fdebfbf9
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81357
Reviewed-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Mark XM25QU256C as tested for probe/read/erase/write.
Found in a Clevo V560TU, tested with a CH341a programmer. Flashrom log:
https://paste.flashrom.org/view.php?id=3732
Change-Id: Ia9226b71e355d2cc736af0ac4e039e8a3b73a84b
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82459
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25L3273F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25L3273F datasheet is available at the following URL:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8661/MX25L3273F,%203V,%2032Mb,%20v1.2.pdf
Change-Id: I4adaaa796d1db34702e7b0ed8e6fb167a3a5f6d7
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81562
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25L1636E has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25L1636E datasheet is available at the following URL:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8596/MX25L1636E,%203V,%2016Mb,%20v1.3.pdf
Change-Id: I415e2d6c89d3d59ba44e22753001c6f69421c39d
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81835
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
memcpy() function expects 2nd parameter to be non-null. Make sure that
the pointer is non-null before passing it to the function.
Also move allocations under if conditions to avoid allocating memory for
a potentially 0 size.
Found-by: scan-build, clang v17.0.6
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I99aad4119f9c11bea75e3419926cc833bc1f68c5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81548
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default toctree in the index file displays full tree of docs
with all the nested levels, and it's too much detail. Besides, left
side menu displays the tree anyway, so duplication is not needed.
Supported hardware section has the deepest nesting out of all other
docs.
This patch changes high-level index files to only display flat list
of next level subtree. On deeper level, full index is displayed.
Change-Id: Ia15e9766cce6f19be1e69fbb1236a327ae3d57b3
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82196
Reviewed-by: Sydney <git@funkeleinhorn.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows the CH347 programmer to be used without root permissions.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: Ia83fa08f6d7c2f449b1a5c0c387c6d4368b99e3a
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82162
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25R2035F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25R2035F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8696/MX25R2035F,%20Wide%20Range,%202Mb,%20v1.6.pdf
Change-Id: I00e76ef942976e3e102cf71fe695c6287b392b64
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81839
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Ensure ChromeOS ebuild (ecargo_test) runs all unit tests, including
those under flashrom/src/cmd.rs which were previously being skipped due
to not being in the default Cargo workspace.
By adding flashrom/ to the [workspace] section of Cargo.toml, these
tests will now be consistently included when building and testing
flashrom-tester on ChromeOS.
References:
* ebuild of flashrom-tester: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-apps/flashrom-tester/flashrom-tester-9999.ebuild
* ecarg_test: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/eclass/cros-rust.eclass#765
BUG=b:338962302
TEST=(ChromeOS)
FEATURES=`test emerge-corsola flashrom-tester`
Could see tests like `cmd::tests::decode_io_opt ... ok`
TEST=(UPSTREAM)
1. Build flashrom by `meson`
2. Build bindings/rust/libflashrom by `cargo build`
3. Build util/flashrom_tester by
`cargo build`
`cargo test --workspace`
Could see tests like `cmd::tests::decode_io_opt ... ok`
Change-Id: Ic23bc35592e6d7d8dd24c71630ea9a2eb2d58573
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82231
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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>
This allows the minimum time that default_delay() will choose to sleep
for instead of polling to be configured at build-time. The default
remains unchanged at 100 milliseconds for now.
The test's correctness has been checked by testing with minimum sleep
time left at its default and set to a non-default value smaller than 100
microseconds (both pass without sleeping, verified with strace) and with
the minimum sleep time set to 0 (causing the test to be skipped). The
configured value from the macro needs to be stored in a const to avoid
-Werror=type-limits errors when configured to be zero.
Change-Id: Ida96e0816ac914ed69d6fd82ad90ebe89cdef1cc
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81606
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
