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>
If not static, this causes a compile-time error because it doesn't have
a prototype.
TEST=meson setup --cross-file meson_cross/i586_djgpp_dos.txt; ninja
Change-Id: I1a43d89b9aabea7dab302350b1abf6bf613a3449
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
I found that cross-compiling with GCC 12.2.0 targeting DJGPP from Linux
on x86_64 that meson used my system include directory
(/usr/include/x86_64-linux-gnu/) and pulled in include files that are
incompatible with DJGPP. Setting sys_root prevents meson from assuming
they're compatible between the build and host systems, fixing those
compile-time errors.
TEST=meson setup --cross-file meson_cross/i586_djgpp_dos.txt; ninja
libflashrom.h no longer causes "features.h: No such file or
directory" errors via /usr/include/x86_64-linux-gnu/sys/types.h
Change-Id: Ib9cf70f6f94782c5303fb232aaf4a46192907f66
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82212
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
flashrom_tester prints hints on how to modify hardware write protect
state as follows:
...
> connect the battery (and/or open the WP screw)
...
> disconnect the battery (and/or open the WP screw)
...
The first advice should be "[...] close the WP screw".
TEST=`flashrom_tester --flashrom_binary=$(which flashrom) \
internal Erase_and_Write Fail_to_verify`
Change-Id: I45f06db51e92e68bf724b13bdf5b31bba511d270
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82083
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Evan Benn <evanbenn@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25L1633E 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.
MX25L1633E datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8617/MX25L1633E,%203V,%2016Mb,%20v1.8.pdf
Change-Id: I63ee0182ad6e62b7408136285aa0e927d53f7bc8
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25L3239E 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.
MX25L3239E datasheet is available at the following URL:
https://www.mxic.com.tw/Lists/Datasheet/Attachments/8613/MX25L3239E,%203V,%2032Mb,%20v1.3.pdf
Change-Id: Ic7a848028fe937deb1bf83ef2a9dddf1330334b6
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81563
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As proposed on the mailing list ("RFC: remove the calibrated delay
loop" [1]), this removes the calibrated delay loop and uses OS-based
timing functions for all delays because the calibrated delay loop can
delay for shorter times than intended.
When sleeping this now uses nanosleep() unconditionally, since usleep
was only used on DOS (where DJGPP lacks nanosleep). When busy-looping,
it uses clock_gettime() with CLOCK_MONOTONIC or CLOCK_REALTIME depending
on availability, and gettimeofday() otherwise.
The calibrated delay loop is retained for DOS only, because timer
resolution on DJGPP is only about 50 milliseconds. Since typical delays
in flashrom are around 10 microseconds, using OS timing there would
regress performance by around 500x. The old implementation is reused
with some branches removed based on the knowledge that timer resolution
will not be better than about 50 milliseconds.
Tested by reading and writing flash on several Intel and AMD systems:
* Lenovo P920 (Intel C620, read/verify only)
* "nissa" chromebook (Intel Alder Lake-N)
* "zork" chromebook (AMD Zen+)
[1]: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/HFH6UHPAKA4JDL4YKPSQPO72KXSSRGME/
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I7ac5450d194a475143698d65d64d8bcd2fd25e3f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81545
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
