As reported by Charles Parent on the mailing list.
Change-Id: I9d8b0038673185103ba08c9797ff94f2f7639d6c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62664
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Now that we can make use of the extended-address register, we can also
advertise the `d8` eraser that can take 3- or 4-byte addresses.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Ticket: https://ticket.coreboot.org/issues/357
Change-Id: I8708294d42f5da80c0ca07ccdae627f13fd5c645
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64637
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
4BA support is implemented by now. So drop these obsolete comments.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I28c5d1de052c28735d5f07874874068ee744b77f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64600
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The W25Q256JV supports the full set of 4BA instructions, including two
native-4BA block erasers.
Signed-off-by: Nico Huber <nico.h@gmx.de>
Change-Id: I1a68121ff40d2b1769632d8e5151c2cd972c23ef
Ticket: https://ticket.coreboot.org/issues/362
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64599
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>
Add Winbond W25Q512NW-IM chip ID and specs to flashrom.
BUG=b:200173901
BRANCH=none
TEST=flash W25Q512NW-IM using CCD.
Original-Change-Id: I9debeda01d77444a5ebe9808ff80a337f320ef65
Original-Signed-off-by: Atul Dhudase <adhudase@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/flashrom/+/3171890
Original-Reviewed-by: Shelley Chen <shchen@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Shelley Chen <shchen@chromium.org>
Original-Commit-Queue: Shelley Chen <shchen@chromium.org>
(cherry picked from commit facb282e8939b8e4ad15d2478ed9ef86d98aed61)
Note: this commit was cherry-picked from the cros tree but
includes corrections to errors in the original commit's 4BA
feature flags that were spotted by Angel Pons
Change-Id: I9debeda01d77444a5ebe9808ff80a337f320ef65
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
As mentioned by Wolf Dieter Brandt in his mail from 07.Feb.22.
Change-Id: Idec3d82efbdf095c3d57bfe5f0fd487007b554cb
Signed-off-by: Simon Buhrow <simon.buhrow@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62712
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
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>
