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>
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>
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 8ab49e72af
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>
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>
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>
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>
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 c82900b661 ("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>
Match the version string for `make` builds to that of `meson` builds
from both Git- and non-Git (release or current snapshot) source trees.
Change-Id: I8694e618878823a9e96b1f2bcfa63f6c71d3c2ed
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Also add link to "How to add new doc" into a collection of
Contributors howtos.
The doc stays in root of docs, and also in the main left-side
menu on the website, so that it is very easy to discover. Everyone
who has even the slightest motivation to update the docs, should
be able to find instructions easily.
Change-Id: I882de0614ab76b8e83b0fafa67296526fecd8a16
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
