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>
Due to how internal is structured around chipset_flash_enable()
entry we need to prepare a crafted programmer_cfg that contains
a board_enable substructure with data derived from the board_enable
subsystem. While this is certainly not perfection, it does make
clear the relationships between board_enable into chipset_flash_enable
and subsequently the overall internal programmer initialisation
in a RAII fashion at the type level over closure upon global
state that is impossible to reason about.
Also flip predicate in report_nonwl_laptop_detected() and
return early with the trivial base-case.
TEST=`$ sudo ./flashrom -p internal --flash-name`.
Change-Id: I459215253845c2af73262943ce91a36464e9eb06
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Some boards need to configure the programmer in specific ways.
For example, a programmer such as internal may need to be configured
either as laptop or not type and as such the board enable needs the
ability to feed state back into the programmer configuration. Plumb
this though by creating a board_cfg structure that can be packed.
Change-Id: I7058a693e714a6966a842ae97cc8da7296e63e5e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71623
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Converting the printlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: I9131348f72c1010e2c213dca4dc4b675a8d8681e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Converting the blockprotect unlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: Ie5c5db1b09d07e1a549990d6f5a622fae4c83233
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This version was released in september 2005 and had a breaking api
change. Drop it so that we don't need to maintain the old codepath any
longer. Beside that, we have already a second codepath which is using
the new `pci_get_dev` variant exclusively.
Change-Id: If943db350b561a005d8292a53d9255223db3d571
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
