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>
The MX25R1635F 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.
MX25R1635F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8702/MX25R1635F,%20Wide%20Range,%2016Mb,%20v1.6.pdf
Change-Id: I6e2b417ab177039618069d8e35132ddbfb814f03
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81840
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The MX25R8035F 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.
MX25R8035F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8749/MX25R8035F,%20Wide%20Range,%208Mb,%20v1.6.pdf
Change-Id: Iec244ffc29278c1f8c3ae47d17af2c4fe5fbe498
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81837
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Region 9 for Intel Meteor Lake; update missing regions.
* Include Region 9 as officially required for Intel Meteor Lake platform.
* Incorporate missing region names from https://github.com/coreboot/coreboot/blob/main/util/ifdtool/ifdtool.c for completeness.
Region 5: Device Expansion (DE or DevExp)
Region 9: Device Expansion 2 (DE2 or DevExp2)
Region 10: Innovation Engine (IE)
Region 11: 10 GbE 0
Region 12: 10 GbE 1
Region 15: PTT
BUG=b:319773700
TEST=Run `flashrom -VV` on MTL and see all the regions are printed out
Change-Id: I3b164ce4ae84bfd523fcd8be416c5d13183ed632
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
When html page is generated, all headers are generated as links on
the page. It is useful to have OS specific instructions as a link
to share with people.
Change-Id: I78645131b1f0acbedcf11964a204a24c45b62cff
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi
`test_build.sh` is used by Jenkins, therefore it should build
everything. Docker container for Jenkins is expected to have all
the dependencies installed, and if some of them are missing, script
should fail.
Recently we had a situation when docker image was missing sphinx
and flashrom Jenkins was silently skipping building man-pages and
documentation. This patch prevents this happening again, because
building man pages and docs will be enforced.
Change-Id: Ib89abddad27d1168cf0a621cf4bdb9f541266165
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81665
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anton Samsonov <avscomputing@gmail.com>
This commit adds two new commands to the serprog protocol which allow
more fine grained control over the SPI bus. This enables more
applications over serprog like e.g. flashing AVR microcontrollers.
This can be tried with my forks of pico-serprog:
https://github.com/funkeleinhorn/pico-serprog/tree/spimode
and avrdude:
https://github.com/funkeleinhorn/avrgirl/tree/serprog-programmer
I announced this change in flashrom and flashprog IRC channels and got
overall positive feedback in the flashprog channel. The same changes
will be sent to flashprog to prevent diverging specs.
Change-Id: Idb5a9a3710fede322def5191d68b7fba0e135292
Signed-off-by: Funkeleinhorn <git@funkeleinhorn.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81428
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25L12850F 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.
MX25L12850F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8632/MX25L12850F,%203V,%20128Mb,%20v1.0.pdf
Change-Id: I71ac70d273904f94d015401f9d8df587084efad0
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81350
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Perhaps some of the users will be able to follow the instructions
and send a patch to mark chip as tested. The option to send report
to the mailing list remains available as before.
Change-Id: I36105725058f2fecb82408c369b70b3324502ece
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81266
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
By default, we busy-loop (a.k.a., "delay") for most delay values, and
only allow sleeping for large delays. But busy-looping is expensive, as
it wastes CPU cycles.
In a simple program that runs a bunch of samples of [1] over 1000
samples, I find that for 0.1 s (100000 us):
64x2 AMD CPU (CONFIG_HZ=250 / CONFIG_NO_HZ_FULL=y):
min diff: 60 us
max diff: 831 us
mean diff: 135 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=1):
min diff: 70 us
max diff: 1556 us
mean diff: 146 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=0):
min diff: 94 us
max diff: 7222 us
mean diff: 1201 us
i.e., maximum 1.5% error, typically ~0.1% error with high resolution
timers. Max 7% error, typical 1% error with low resolution timers. The
error is always in the positive direction (i.e., sleep longer than the
requested delay, not shorter than the request).
This seems reasonable.
[1] Stripped / pseudocode:
clock_gettime(CLOCK_MONOTONIC, before);
nanosleep({ .tv_nsec = usecs * 1000 }, NULL);
clock_gettime(CLOCK_MONOTONIC, after);
diff = abs((after - before) / 1000 - usecs));
Change-Id: Ifd4821c66c5564f7c975c08769a6742f645e9be0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80808
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
flashrom_init() may run through an expensive delay calibration phase,
depending on the system timer behavior (e.g., if high resolution timers
are disabled). This is wholly unnecessary if we're only going to dump
usage output or similar.
Defer the calibration until we've finished our CLI overhead.
BUG=b:325539928
TEST=`flashrom --help` with `sysctl kernel.timer_highres` == 0
Change-Id: I57949ab511df04c6922008fa8cb12467154e2c5e
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Flashrom has several magic programmer_delay() calls scattered throughout
its codebase (see cli_classic.s/main() and
flashrom.c/flashrom_image_write(), at least). These delays are
superfluous for the linux_mtd programmer, because it's an opaque
programmer in which all protocol details are handled by the kernel
driver.
Stub out the delay function, so we don't waste up to 1.1 seconds of
needless delay time, depending on the operation and CLI vs libflashrom
usage.
BUG=b:325539928
TEST=`elogtool add 0xa7` on a linux_mtd system (such as a Mediatek
Chromebook):
Time improvement - reduces from ~1.5s wall clock to about 0.4s
CPU usage: -90%, as most of the CPU cycles (before this change) are
spent in needless magic-delay busy loops
Change-Id: I3ac69d3fd7cfc689c5b32c130d044516ed846c29
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Same approach as it was before: founder and current project lead.
Change-Id: I1043b9499ab22da5ec981592d7b4311f027c4b5f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81106
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not valid to separately check the major and minor versions. The
proper minor check would be something like:
if (fmap->ver_major == FMAP_VER_MAJOR &&
fmap->ver_minor > FMAP_VER_MINOR)
ERROR();
But this code was alleged (at introduction in [1]) to have come from
cbfstool, and cbfstool doesn't bother with a minor version check. This
check is only for finding the FMAP while searching the flash; it isn't
actually here for integrity and compatibility purpose.
Drop the MINOR version check; align with cbfstool on the MAJOR version
check; and match the cbfstool comments for is_valid_fmap(), to emphasize
the lack of precision.
[1] Commit c82900b66142 ("Add support to get layout from fmap (e.g.
coreboot rom)")
BRANCH=none
BUG=b:288327526
TEST=libflashrom + ChromiumOS flashmap
Change-Id: I984835579d3b257a2462906f1f5091b179891bd0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* serprog.h doesn't exist, so refer to .c source instead
* in the doc, no other command has S_CMD_ prefix either
Change-Id: Ic83e7fd80840f2db0b006935a964721da0388068
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
