Chips I had available for testing were tested with all writeprotect
commands and an FT232H adapter. Chips I wasn't able to test were just
checked against the datasheets.
Chips used for testing (including chips added in previous patches) are
listed in the table below:
Flashrom Chip name | Chip(s) tested
---------------------------------+----------------------------
AT25SL128A |
EN25QH128 |
GD25LQ128C/GD25LQ128D/GD25LQ128E | GD25LQ128DSIG
GD25LQ64(B) | GD25LQ64CWIG
GD25Q127C/GD25Q128C | GD25Q127CSIG, GD25Q128ESIG
GD25Q256D | GD25Q256DYIG
GD25Q64(B) | GD25Q64CSIG
W25Q128.JW.DTR |
W25Q128.V..M |
W25Q128.W |
W25Q256JV_M |
W25Q256.V |
W25Q64.W |
XM25QH128C |
XM25QH256C |
BUG=b:182223106
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status}
Change-Id: I7f3d4c4148056098a845b5c64308b0333ebda395
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62214
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow chips to specify functions that map status register bits to
protection ranges. These are used to enumerate available ranges and
determine the protection state of chips. The patch also adds a range
decoding function for the example chips. Many other chips can also be
handled by it, though some will require different functions (e.g.
MX25L6406 and related chips).
Another approach that has been tried in cros flashrom is maintaining
tables of range data, but it quickly becomes error prone and hard to
validate.
Using a function to interpret the ranges allows compact encoding with
most chips and is flexible enough to allow chips with less predictable
ranges to be handled as well.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=dumped range tables, checked against datasheets
Change-Id: Id163ed80938a946a502ed116e48e8236e36eb203
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58480
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch adds a register bit map `struct reg_bit_info`, with fields
for storing the register, bit index, and writability of each bit that
affects the chip's write protection. This allows writeprotect code to be
independent of the register layout of any specific chip. The new fields
have been filled out for example chips.
The representation is centered around describing how bits can be
accessed and modified, rather than the layout of registers. This is
generally easier to work with in code that needs to access specific bits
and typically requires specifying the locations of fewer bits overall.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: Id08d77e6d4ca5109c0d698271146d026dbc21284
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58477
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This patch adds support for reading and writing the second status
register and enables it on a limited set of flash chips.
Chip support for RDSR2/WRSR2/extended WRSR is represented using feature
flags to be consistent with how other SPI capabilities are represented.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
TEST=logged SR2 read/write values during wp commands
Change-Id: I34a503b0958e8f2f22a2a993a6ea529eb46b41db
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
I have successfully tested it with FT2232H-programmer.
Change-Id: Ia9a32146b225eca66e9a6bfef45be5f2b24aef46
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58971
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As reported by Wolf Dieter Brandt in his e-mail from 09.Aug.2021.
Change-Id: I0c19f84780e7fa3699fd706f8e105fc5937ba8bf
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Just add the name to the existing entry, as usual it is supposed to be
compatible.
Signed-off-by: Tao Xia <xiatao5@huaqin.corp-partner.google.com>
Change-Id: I14ab7e04f5209d2bcf34b0d2de9da2c01bf32d00
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56546
Reviewed-by: Weimin Wu <wuweimin@huaqin.corp-partner.google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
As defined by gigadevice. C, D and E are all meant to
be the same.
BUG=b:185957191
BRANCH=none
TEST=builds
Change-Id: I3bef9386a185a0e8c54c125af5509b63540995aa
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55742
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Just add the name to the existing entry, as usual it is supposed to be
compatible.
Change-Id: I59c8067f15b5ceac5a2e2f8fe93431a465f17e23
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As mentioned in mail from Bernd.Stoeferle@elbitsystems-de.com on 22.12.2020.
Change-Id: Ie49332333f49a40f7bd8f3b5e42a8e2ad6995618
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/50720
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
According to the W25Q64JW datasheet rev. E, only devices ending with the
letter 'M' have a device ID of 8017h. There are other variants with
different device IDs. This patch makes the 'W25Q64JW...M' definition
consistent with the 'W25Q32JW...M' definition.
The device ID macro defined in flashchips.h has also been renamed from
WINBOND_NEX_W25Q64JW to WINBOND_NEX_W25Q64JW_M.
BUG=b:166294558
BRANCH=none
TEST=builds
Change-Id: Ib0dc914da286a191d22e666332b1063b88db4251
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54291
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The chip was added to cros flashrom in
`commit 1fc77dd1ee27a5d6e58a82c6ed6ed390a15372d7`.
Quoting from the commit message:
> We have varied the correct chip name is reported as well as
> write and read 16MBytes of random data and verified the checksum's match.
> Further, --wp-list appears to report the correct ranges.
>
> BUG=b:130199963
> BRANCH=none
> TEST=Ran flashrom with a Dediprog SF100, RW random data and checksum matched.
Change-Id: I7425e12658dd69c4ec8d3309dd591d09a935bb4d
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/53946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Only mattering difference to the MX25L3273E seems to be the voltage
range (starting at 2.65V instead of 2.7V). I don't think that would
justify yet another entry.
Change-Id: I73402dddedf360ab84caed4c019efe27b477d4c2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52570
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Looks like BoHong Microelectronics has the same vendor ID and makes very
similar chips. For instance, Boya BY25Q128AS and BoHong BH25Q128AS have
the same specifications and their datasheets are mostly identical.
Change-Id: I8d6951797daeeecca6af200c995297c0394adefd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52550
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chip was marked as TESTED_OK_PREW in the cros tree by
`commit 419e32ae457cc36b03757b89471a7ce3770e9611`.
Quoting from the original commit message:
> TEST=Tested writes using Servo
Change-Id: Id7f44a41d6b2c397f1ce2e345f8ab44e95e4cfa2
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51736
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chip was marked as TESTED_OK_PREW in the cros tree by
`commit b2f900273aac329b82089e4dbc5a8ba3d032fff0`.
Quoting from the original commit message:
> TEST=read and write BIOS on glimmer with Eon device.
Change-Id: I13dc3e6bde9e4581fdd5856a412918784b913fbc
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51734
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The following adds support for the Adesto AT25SF128A-SHB-T part.
We have varied the correct chip name is reported as well as write
and read 16MBytes of random data and verified the checksum's match.
Further, --wp-list appears to report the correct ranges.
BUG=None
BRANCH=none
TEST=Ran flashrom with a Dediprog SF100, RW random data and checksum
matched.
Original-Change-Id: Ic22ca588f33753fdf492e8445324bcc0a809d3e2
Original-Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/1593201
Original-Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Original-Tested-by: Martin Roth <martinroth@chromium.org>
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
(cherry picked from commit 1fa87e058b72a2de1e9127a45e9978361de48479)
Note: this does not include the changes made to writeprotect.c in the
original patch, as they depend on a large amount of additional
writeprotect code that is currently only present in the cros tree, and
the intention here is just to reduce the diff in flashchips.c.
The `.wp` field has also been removed.
Change-Id: I1ce2a6699a1f0116306f668123673a1ba9c932d2
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51097
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
I have successfully probed/read/erased/written a GD25LQ128D, so marking
this entry as tested.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: Ic5329ebe81b6c1eabfb594f7f7affb3fd460db6b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49229
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds a support of 4-byte address format for VARIABLE_SIZE
dummy flash device, so that it can emulate an flash size larger than
16 MBytes.
- assigned a feature bits FEATURE_4BA to VARIABLE_SIZE flash config.
- added codes handling two commands, JEDEC_READ_4BA and
JEDEC_BYTE_PROGRAM_4BA.
- changed blockeraser to use Chip-Erase command so that it can be
free from flash address byte format.
TEST=ran the command line below:
$ flashrom -p dummy:image=${TMP_FILE},size=33554432, \
emulate=VARIABLE_SIZE -w ${IMG_32MB} -V -f
$ flashrom -p dummy:image=${TMP_FILE},size=16777216, \
emulate=VARIABLE_SIZE -w ${IMG_16MB} -V -f
$ flashrom -p dummy:image=${TMP_FILE},size=8388608, \
emulate=VARIABLE_SIZE -w ${IMG_8MB} -V -f
Signed-off-by: Namyoon Woo <namyoon@google.com>
Change-Id: Ia59eecfcbe798d50f8dacea98c3c508edf8ec77e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/44881
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is designed for firmware updater to pack firmware image
preserving some specific partitions in any size.
BUG=none
TEST=ran the command line below:
$ flashrom -p dummy:image=${TMP_FILE},size=16777216, \
emulate=VARIABLE_SIZE -w ${IMG} -V -f
$ flashrom -p dummy:image=${TMP_FILE},size=auto, \
emulate=VARIABLE_SIZE -w ${IMG} -V -f
Signed-off-by: Namyoon Woo <namyoon@google.com>
Change-Id: Iff266e151459561b126ecfd1c47420b385be1db2
Reviewed-on: https://review.coreboot.org/c/flashrom/+/44879
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
W25Q256JW currently has two variants, the W25Q256JW with device
ID 0x6019 added in commit be4682d and the W25Q256JW_DTR (aka
W25Q256JW-IM) with device ID 0x8019 added by this patch.
Winbond W25Q256-series chips have a few device IDs:
0x4019: W25Q256FV
0x6019: W25Q256JW
0x7019: W25Q256JV
0x8019: W25Q256JW_DTR
Hence we need to be more specific with naming than usual to avoid a
false positive with wildcards.
Change-Id: I50a6de2c915f9201c458378fcc49130ead73d8c4
Signed-off-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/42386
Reviewed-by: Simon Buhrow
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This commit adds support for the Winbond W25X05CL SPI flash chip. The
Winbond W25X05CL is a 512Kib (64 KiB) SPI flash chip with 4KiB sectors.
I have tested this patch with a Bus Pirate (v3b) and an in-circuit W25X05CL
flash chip using a test clip. Reading, erasing, and writing all function
as expected.
Change-Id: I19c33c7da374f0263f30577a10a0f0f1afa4febc
Signed-off-by: Jacob Appelbaum <jacob@appelbaum.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/43573
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Nicklas Lennert wrote me via the flashrom mailing list that
he successfully ran read, write and verify cmd.
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Change-Id: I3608945a38b5ed42b8b2b9b2b388cdea97141d7b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40855
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This reverts commit a3519561bd0fb44153bb376322b799000657576f.
Breaks support for most SPI flash chips. It's too big and too
invasive to be reviewed as a single commit.
The changes to `spi_poll_wip():spi25.c` were not noticed in the
original review that were from the similarly named function and
file `s25f_poll_status():s25f.c` in the downstream Chromium fork.
V.2: Rebase and rephrase commit msg to reflect how the issue
slipped in.
Change-Id: Id2a4593bdb654f8a26957d69d52189ce61621d93
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shiyu Sun <sshiyu@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This may seem too big just to support yet another flash chip, but in
reality it brings support for whole new family of S25FS
Spansion/Cypress flash chips. These chips require handling of some
special status registers for erasing or writing, with very specific
timing checks in place.
For example, WIP status bit will remain being set to 1 if erase or
programming errors occur, and in that case chip 'software reset' has
to be performed otherwise the chip will remain unresponsive to all
further commands. Also, special CR3NV register (Configuration Register
3 Nonvolatile) status bits needs to be read and set by using RDAR
(ReaD Any Register) and WRAR (WRite Any Register) OP commands, and
these states are needed to determine which type of reset feature is
enabled at the time (legacy or S25FS type) in the first place,
determine whether Uniform or Hybrid sector architecture is used
at the time, or set programming buffer address wrap point (256 or 512
bytes). Furthermore, S25FS chip status register has to be restored to
its original state (hence that ugly CHIP_RESTORE_CALLBACK) following
erasing or writing, failing to do so may result in host being unable
to access data on the chip at all.
Finally, although this brings support for the whole family of chips,
I only have one such chip to do the actual testing, S25FS128S (Small
Sectors), which I had fully tested on ch341a and FT4232H programmers,
with confirmed working probe, read, erase and write.
Full summary of changes are here:
flashchips:
add new flashchip sctructure property:
.reset
add chip definitions:
S25FS128S Large Sectors
S25FS128S Small Sectors
flash:
add macro (chip_restore_func_data call-back):
CHIP_RESTORE_CALLBACK
flashrom:
add struct:
chip_restore_func_data
add call-back function:
register_chip_restore
spi:
add OP codes:
CMD_RDAR, CMD_WRAR, CMD_WRAR_LEN, CMD_RSTEN, CMD_RST
add register bit function definitions:
CR3NV_ADDR, CR3NV_20H_NV
add timers:
T_W, T_RPH, T_SE
spi25:
refactor (based on chromiumos implementation) function:
spi_poll_wip
port these functions from chromiumos:
probe_spi_big_spansion
s25fs_software_reset
s25f_legacy_software_reset
s25fs_block_erase_d8
spi25_statusreg:
port these functions from chromiumos:
spi_restore_status
s25fs_read_cr
s25fs_write_cr
s25fs_restore_cr3nv
Most of the ported functions are originally from s25f.c found at
https://chromium.googlesource.com/chromiumos/third_party/flashrom
with exception of spi_restore_status which is defined in
spi25_statusreg.c. The rest of macros and OP codes are defined in
same files as in this commit.
Change-Id: If659290874a4b9db6e71256bdef382d31b288e72
Signed-off-by: Samir Ibradzic <sibradzic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
BUG=b:153515968
BRANCH=kukui
TEST=flash coreboot on kakadu and get successful result.
Change-Id: I8637129421a3b0f96bd8dffa4f50783ea6931967
Signed-off-by: Scott Chao <scott.chao@bitland.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40275
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Support GD25WQ80E, which is the internal flash of IT81202.
TEST=Building flashrom and flashing FW image into IT81202 successfully.
Change-Id: Ib5feaa6ecc7b11b2218e5f02c087b4331388bef8
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
32Mbit (4MiB) [x1/x2/x4] Wide Voltage Range (VCC 1.65V-3.6V). It is
similar to the already-supported MX25R6435F, but the total size is
halved.
Tested on ch341a, FT4232H and FT2232H (PicoTAP) programmers, confirmed
working probe, read, erase and write.
Fixes: https://github.com/flashrom/flashrom/issues/43
Change-Id: I6e79115adba17d13d24bc85d78707d53fd4a0be5
Signed-off-by: Samir Ibradzic <sibradzic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39532
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
As found on the Tesla AP2.5 board.
Based on https://mail.coreboot.org/pipermail/flashrom/2013-June/011066.html
Tested with:
flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -r content.bin
Signed-off-by: Bernhard Urban-Forster <lewurm@gmail.com>
Change-Id: Ifa9b7615951125b6bbc1f051370ef54896bf506c
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38596
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
This commit adds support for the Adesto AT25SF321 SPI flash chip. Probe
and read operations have been tested via FT2232H interface, but writes
have not been verified.
Datasheet is available at the following URL:
https://www.adestotech.com/wp-content/uploads/DS-AT25SF321_047.pdf
Change-Id: I7410815e063ffe154a97d7ea5881c8eb82025f56
Signed-off-by: Peter Adkins <pete@kernelpicnic.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36904
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Port the code from chromeos flashrom
BUG=b:144297264
TEST=Tested using W25Q128JWDTR in SPI mode
Signed-off-by: Peichao.Wang <peichao.wang@bitland.corp-partner.google.com>
Change-Id: Ifc28878b17dc10da2cfd8f82fffbd57adb22799e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36717
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds missing voltage and capacity variants for N25Q and MT25Q
series devices. This also fixes a typo in some model numbers where the
last letter should have been a G instead of an E. Added devices include:
N25Q256..1E
N25Q512..1G
N25Q00A..1G
N25Q00A..3G
MT25QU128
MT25QL128
MT25QU256
MT25QU512 tested by Jacob Creedon <jcreedon@google.com>
MT25QL01G tested by Konstantin Grudnev <grudnevkv@gmail.com>
MT25QU01G
MT25QL02G
MT25QU02G
Two have been tested as indicated, all other variants added are marked
untested.
Signed-off-by: Jacob Creedon <jcreedon@google.com>
Change-Id: I85630e4f6c0aa3b261f9871b7d363dad278b997e
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34491
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Automotive 2 Mbit (256KiB) serial SPI bus EEPROM
PREW tested successfully with use of ch341a programmer
on Linux host 5.2.0-1-MANJARO x86_64
Signed-off-by: Konstantin Grudnev <grudnevkv@gmail.com>
Change-Id: Ic29cd9051c7eac4822d620c299834134f987f01b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/34496
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add a printlock attribute for the Winbond W25Q128.V..M chip. The
printlock attributes matches the ChromiumOS repo's definition of this
chip.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I775d5d40677593dcb2d05750f8bbc62871b0e551
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35549
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Mark Winbond W25Q40EW as TESTED_PREW.
The Winbond W25Q40EW has been marked TESTED_PREW in the ChromiumOS
repository. ChromiumOS has the same defintion for this chip as this
repo, except that ChromiumOS does not have FEATURE_OTP.
Signed-off-by: Alan Green <avg@google.com>
Change-Id: I4be5b2e1069a3f735f0dc6ec92d5f4c8946fbb02
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
