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>
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>
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>
Use build system to check header presence:
* getopt.h (from include/cli_classic.h)
* pciutils/pci.h (from include/platform/pci.h)
Tested with <getopt.h> and <pci/pci.h> using GNU Make 4.1, 4.2.1, 4.4.1
and Meson 0.56.0, 1.2.1 against GCC 13.2.1 and GCC 5.5-, 7.3-compatible
(EDG 4.14-, 5.1-based) on openSuSE Tumbleweed and a custom LFS distro.
Change-Id: Ic544963ffd29626ae0a21bdddb1c78850cc43ec6
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77089
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Q127C and Q128C are not the same. Q127C doesn't support QPI but Q128C
does. So we need to split the existing GD25Q127C/GD25Q128C into two
separated entries. We also introduce the new flashchip Q128E and merge
it into Q127C.
Datasheets:
Q128E: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00480-GD25Q128E-Rev1.2.pdf
Q127C: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00220-GD25Q127C-Rev2.3.pdf
Q128C: https://www.endrich.com/sixcms/media.php/2/GD25Q128C-Rev2.pdf
Q128E and Q127C/Q128C have compatible main functions, their differences
are:
* Q128E uses 55 nm process, while Q127C/Q128C use 65nm
* Q128E/Q127C does not support QPI
* Q128E/Q127C have OTP: 3072B, while Q128C are 1536B
* Q128E's fast read clock frequency is 133MHz, while Q127C/Q128C are
104MHZ
So we decided to merge Q128E into Q127C.
We also tested that Q128E could pass flashrom_tester while probing it as
127C/128C, so the main functionalities are compatible.
Change the chip name from GD25Q127C/GD25Q128C to two entries
GD25Q127C/GD25Q128E and GD25Q128C to make it more accurate.
Chip revision history:
- The 'GD25Q127C/GD25Q128C' definition was added in
`commit e0c7abf219b81ad049d09a4671ebc9196153d308` as 'GD25Q128C' and
later renamed to 'GD25Q127C/GD25Q128C'
BUG=b:304863141, b:293545382
BRANCH=none
TEST=flashrom_tester with flashrom binary could pass with Q128E,
which contains probe, read, write, erase, and write protect
Signed-off-by: Hsuan Ting Chen <roccochen@google.com>
Change-Id: I3300671b1cf74b3ea0469b9c5a833489ab4914f5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Other chips (at least Winbond) will benefit from this change.
Also, drop the FIXME comment, as it can be misleading. The
"pretty print" functions should only display values from the
Status Register, so using an inappropriate function might only
confuse user.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I7169a2312698343e1065cdca91a3985e00cb3804
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Clean commit 51e1d0e4b7
'Add support for Intel Emmitsburg PCH' which broke
CHIPSET_5_SERIES_IBEX_PEAK detection and which assumes C740 is the same
as C620, while its more a close relative to Intel's H570 PCH.
Based on Intel SPI Programming Guide #619386.
Test: Run on Intel ArcherCity CRB with Intel's C741 PCH
using the 'internal' programmer.
Test: Run on BMC and accessed the SPI flash chip over
'linux_mtd' programmer.
Change-Id: I80eebc0fcc14de9df823aceaee77870ad136f94a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78186
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Layouts can be expensive to derive (reading from flash), so we might
want to reuse a layout for different purposes. Today, it's not possible
to undo a flashrom_layout_include_region() operation (to, say, operate
on a different region). Add such an API.
Change-Id: I7ea3e0674f25e34bf2cfc8f464ae7ca1c1a3fbfd
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/76005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
The flashbase is a machine-sized integer representation of
address space and so use the appropriate type that is correctly
sized to encode such data.
The flashbase is assigned to 'base' in 'map_flash()' and the
type correctly changed to uintptr_t in commit 4e32ec19b1
therefore makes for a consistent type usage whenever stored.
While `sizeof(unsigned long)` and `sizeof(uintptr_t)` are both `8` under
most circumstances on a 64bit platform and thus have enough bits to
represent all addresses on the platform, the C standard does not
guarantee this. Only `uintptr_t` and `void *` has a guaranteed
isomorphism as `uintptr_t` is defined by the platforms toolchain support
whereas the conversion from `void *` to an integer is implementation
defined and that the memory address value may contain additional bits
describing the validation data or provenance of the address. Therefore a
integer is insufficient to contain all the necessary information for
that specific platform so this may not always work out for all platforms
and toolchain combinations.
Spotted-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ib9057e438731b9cccde0e24d5c8f758c3af1d47f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Flashrom only tries to use WP-based unlocking if it detects that WP
operations are supported. However WP support was detected in a way that
ignored WP operations provided by opaque masters.
This stopped flashrom from automatically unlocking with some opaque
masters, particularly linux_mtd.
This commit also deletes part of a test that required the chip unlock
function to be called before read/write/erase operations because WP
unlocking is now used instead of chip unlocking.
BUG=b:280111380
BRANCH=none
TEST=Checked flashrom automatically unlocked flash on strongbad (MTD)
Change-Id: I1774ad64d82ae47cd085df6045e17e283855c01f
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
