Using both a Dediprog SF100 and a Bus Pirate, read and erase works
correctly on a MT25QL128 but writes were failing to take effect.
Currently, the entry in flashchips.c indicates that this device supports
4-byte addressing. Micron's datasheet indicates that it does not.
After removing FEATURE_4BA_WREN from feature_bits, both SF100 and
Bus Pirate were able to successfully read, erase, and write a
MT25QL128 so also marking as tested.
Change-Id: I6341456c722840a413bd2c51fe9a78bbda5cdbab
Signed-off-by: Rick Altherr <kc8apf@kc8apf.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71206
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As noted in a comment on
`commit 86fc9cf7ab221bc54ef6f10252e296fc2d7a22d2`, the GD25Q256D
datasheet indicates that the chip does not require a WREN command to
enter 4BA mode.
Testing has confirmed that a WREN command is not required, so change the
flashchip feature flags from FEATURE_4BA_WREN to FEATURE_4BA.
Ticket: https://ticket.coreboot.org/issues/356
BUG=none
BRANCH=none
TEST=read/write/erase/verify GD25Q256D flash with FT2232H programmer
TEST=called spi_enter_exit_4ba(true), dumped registers, checked ADS=1.
Change-Id: I96e48933f33c52c0d10a0d4cb7f7e07c1fceab99
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This paves the way to allow for the conversion of flashchip printlock
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: Icff868d9454e9b0a059a736457bb562430436033
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This paves the way to allow for the conversion of flashchip unlock
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: I3ed51142cd22becc8286959f5504565158fa2de0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This paves the way to allow for the conversion of flashchip erase_block
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: I122295ec9add0fe0efd27273c9725e5d64f6dbe2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69131
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I612d46fefedf2b69e7e2064aa857fa0756efb4e7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66788
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I80149de169464b204fb09f1424a86fc645b740fd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I00aaab9c83f305cd47e78c36d9c2867f2b73c396
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Replace the `decode_range` function pointer in `struct flashchip` to an
enum value. The enum value can be used to find the corresponding
function pointer by passing it to `lookup_decode_range_func_ptr()`.
Removing function pointers like `decode_range` makes it possible to represent chip data in a declarative format that does not have to be
stored as C source code.
BUG=b:242479049
BRANCH=none
TEST=ninja && ninja test
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: If6d08d414d3d1ddadc95ca1d407fc87c23ab543d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67195
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to its datasheet, Spansion S25FL512S supports writing/
reading its extended address register via 0x17/0x16 opcodes. With
that enabled, we can also enable the EAR7 feature, i.e. toggling
4BA mode via bit 7 of that register.
S25FL512S did not advertise EAR support at all, so we set it to
TEST_UNTESTED again.
Change-Id: Ib214e509a5c294ab60460a2b5d00a713a119ab3f
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65265
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
According to their datasheets, ISSI IS25LP256 and IS25WP256 support
both 0xc5/0xc8 and 0x17/0x16 opcodes to write / read their extended
address register. Flashrom will use 0xc5 by default if available,
so adding the FEATURE_4BA_EAR_1716 flag makes no difference for now
(FEATURE_4BA_EAR_C5C8 is included in the already selected FEATURE_4BA
set). It's better to have a comprehensive description of the chips,
though, in case somebody wants to use them in the future with a
master that restricts available opcodes.
Change-Id: I03e4ff825c7742e7ff79b51b75293d53a091d4d4
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
So far, we assumed the 0xc5/0xc8 instructions by default and allowed
to override the write instructions with the `.wrea_override` field.
This has some disadvantages:
* The additional field is easily overlooked. So when adding a new
flash chip, one might assume only 0xc5/0xc8 are supported.
* We cannot describe flash chips completely that allow both
instructions (and some programmers may be picky about which
instructions can be used).
Therefore, replace the `.wrea_override` field with a feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I6d82f24898acd0789203516a7456fd785907bc10
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64636
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There are two competing sets of instructions to access the extended
address register of 4BA SPI chips. Some chips even support both sets.
To prepare for other instructions than the default 0xc5/0xc8, rename
the original feature flag.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iacb7b68a9e3444fe28873ff0fe5e3fab16643c8c
Ticket: https://ticket.coreboot.org/issues/357
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64635
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
These chips seem to be rather regular, supporting 2.7V..3.6V, the
common erase block sizes 4KiB, 32KiB, 64KiB and the usual block-
protection bits.
Status/configuration register naming differs from other vendors,
though. These chips have 2 status registers plus 3 configuration
registers. Configuration registers 1 & 2 match status registers
2 & 3 of what we are used from other vendors. Read opcodes match
too, however writes are always done through the WRSR instruction
which can write up to 4 bytes (SR1, CR1, CR2, CR3).
S25FL256L supports native 4BA commands and entering a 4BA mode.
However, it uses an unusual opcode (0x53) for the 32KiB 4BA block
erase.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I356df6649f29e50879a4da4183f1164a81cb0a09
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64747
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Spansion flash chips S25FL128L and S25FL256L use the WRSR instruction to
write more than 2 registers. So align SR2 and SR3 support: The current
FEATURE_WRSR_EXT is renamed to FEATURE_WRSR_EXT2 and FEATURE_WRSR_EXT3
is added. Also, WRSR3 needs a separate flag now.
Verified that FEATURE_WRSR_EXT2 still works using the `dummy_flasher`.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ibdfc6eb3d2cfecbf8da0493d067031ddb079a094
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64746
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Add a check so that the erase functions for all flashchips are in
increasing order of their respective eraseblock sizes. This is required
for the implentation of the improved erasing algorithm. The patch uses
the count of eraseblocks in each erase function to determine the order
(More eraseblocks means that the function has smaller eraseblock size).
Also fix the structs in flashchips.c which were found to be not
conforming to this test.
TEST = make && ./flashrom
Change-Id: I137cb40483fa690ecc6c7eaece2d9d3f7a851bb4
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64961
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Wire "variable size" feature in dummy programmer via opaque infra.
This patch fixes the broken build with CONFIG_DUMMY=no.
Dummyflasher registers opaque master for the case when it is
initialised with EMULATE_VARIABLE_SIZE. Dummy opaque master emulates
read/write/erase as simple memory operations over
`data->flashchip_contents`.
The feature works via "Opaque flash chip" in flashchips.c which has
one block eraser at the moment. If this changes in future, each block
eraser needs to be updated in `probe_variable_size`.
Fixes: https://ticket.coreboot.org/issues/365
TEST=the following scenarious run successfully
Testing build
$ make clean && make CONFIG_DUMMY=no
$ flashrom -h : dummy is not in the list
$ make clean && make CONFIG_EVERYTHING=yes
$ flashrom -h : dummy is in the list
Testing "variable size" feature
$ flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE -V
$ flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE
-r /tmp/dump.bin -V
$ head -c 8388608 </dev/urandom >/tmp/image.bin
$ flashrom
-p dummy:image=/tmp/image.bin,size=8388608,emulate=VARIABLE_SIZE
-w /tmp/dump.bin -V
also same as above with erase_to_zero=yes
Testing standard flow
$ flashrom -p dummy:emulate=W25Q128FV -V
$ flashrom -p dummy:emulate=W25Q128FV -r /tmp/dump.bin -V
$ head -c 16777216 </dev/urandom >/tmp/image.bin
$ flashrom -p dummy:image=/tmp/image.bin,emulate=W25Q128FV
-w /tmp/dump.bin -V
Testing invalid combination of programmer params (`init_data` fails
and prints error message which is WAI)
$ flashrom -p dummy:size=8388608 -V
-> init_data: size parameter is only valid for VARIABLE_SIZE chip.
$ flashrom -p dummy:emulate=VARIABLE_SIZE -V
-> init_data: the size parameter is not given.
$ flashrom -p dummy:emulate=W25Q128FV,erase_to_zero=yes -V
-> init_data: erase_to_zero parameter is not valid for real chip.
Change-Id: I76402bfdf8b1a75489e4509fec92c9a777d0cf58
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64488
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Configuration for W25Q64 was tested on hardware (W25Q64FV).
Emulation of W25Q128 in dummyflasher will be extended to support WP.
Haven't tested this one on hardware, but it's the same configuration as
for W25Q64 except that it has WPS.
W25Q64JV chip was renamed to W25Q64JV-.M (those with QPI).
W25Q64.V chip was split into W25Q64BV/W25Q64CV/W25Q64FV (no SR3 and WPS)
and W25Q64JV-.Q (SR3 and WPS, but no QPI).
Change-Id: Iccb69a8d3a0dd2192e2c938caddaf07b1889ed35
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59071
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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>
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>
