Add reg_bits for W25Q256JW_DTR as per the datasheet.
BUG=b:263410331
TEST=Verified on google/rex.
w/o this patch:
Failed to get WP status: WP operations are not implemented for this chip
w/ this patch:
flashrom -p internal --wp-range 0x0,0x2000000
flashrom -p internal --wp-enable
flashrom -p internal --wp-status
flashrom -p internal -E <---- failed to erase the flash as WP (which is
expected)
Signed-off-by: Kapil Porwal <kapilporwal@google.com>
Change-Id: I8ac23f706d4293a7d7d11ad6b2f62526fb075367
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70549
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
