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>
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>
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>
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>
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 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>
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>
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 51e1d0e4b7670e5822560acc724a6a8dd00b6af4
'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>
XM25QH80B has the same ID as M45PE80, but has more features.
Tested with CH341A.
Change-Id: Ib51225426d8d1a381d45af3574e5ba2bf02837aa
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63516
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on https://github.com/flashrom/flashrom/pull/204
squashed with fixes of IS25WQ040 size: it is 4Mbits, not 4MBytes, see
https://www.issi.com/WW/pdf/25WQ020-040.pdf
Tested read, write and erase with ft2232_spi-based "Tigard" programmer.
Change-Id: I072c6b94d7931637d1c2721c3316205f2d57320e
Signed-off-by: Roman Stingler <roman.stingler@gmail.com>
Signed-off-by: Vasily Galkin <galkin-vv@ya.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58179
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested using the linux_spi programmer on a Raspberry Pi.
Datasheet:
https://media.digikey.com/pdf/Data%20Sheets/Macronix/MX25L3255E.pdf
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
Change-Id: I65968771e22e6b823d2d6192c33f5b0cba25d5b9
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57410
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
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>
Tested: read, write and erase.
Chip (and datasheet) have recenty been removed from XMC's website
but can still be retrieved through web archive:
https://web.archive.org/web/20221122191724/https://www.semiee.com/file/XMC/XMC-XM25QH128A.pdf
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Change-Id: Iced40403c6694a55fd648ea2785cdcba21712234
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69309
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
I took the original patch from Ondrej Hennel [1] and applied the
requested changes. Reading, erasing and writing works.
[1] https://patchwork.ozlabs.org/project/flashrom/list/?series=261647
Change-Id: Iffd7c4284d4d96b30a94f5dee882b5403fdfc183
Signed-off-by: Mario Kicherer <dev@kicherer.org>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested read/write/erase/probe operations with a ch341a_spi programmer.
Datasheet is available at https://www.mouser.de/datasheet/2/590/DS-AT25DF011_032-1098683.pdf
Signed-off-by: Hanno Heinrichs <hanno.heinrichs@rwth-aachen.de>
Change-Id: I5a2141f1380e864c843d6a3008fdb02dc1b75131
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51048
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 4e32ec19b124a7
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>
Some systems, DJGPP/DOS for now, may not provide getopt and their gnu
extensions. So provide a fallback implementation.
The code is based on musl libc.
Change-Id: I6ebbde075014e3b45b0f9e04b34b72aa969e1197
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73102
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
