Used to control skipping of write-protected part of a chip.
Change-Id: Icdc56cb1876aab8f8229cd1a485aa297d8b7b1e9
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Not all chips follow the same pattern. There are differences in how CMP
bit is treated or in block size used.
Change-Id: Ied7b27be2ee2426af8f473432e2b01a290de2365
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Sometimes it's only a matter of naming and these behave exactly like
SR2/SR3 (Spansion S25FL256L and S25FL128L), but in case of Macronix
MX25L6473E and MX25L6473F configuration register is read via a separate
RDCR command, but written as if it's SR2 using WRSR_EXT2.
Change-Id: I45f9afcc31f1928ef6263a749596380082963de4
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Not to be confused with "secure registers" of OTP.
Security register is a dedicated status register for security-related
bits. You don't write its value directly, issuing special write commands
with no data set separate OTP bits to 1 automatically (WRSCUR, WPSEL
commands). No WREN is necessary, but at least some datasheets indicate
BUSY state after those write commands.
Unlike cases where OTP bit is part of SR and can only be written while
in OTP mode, security register can only be written outside of the mode.
The register is found in at least these chips by Macronix:
* MX25L6436E
* MX25L6445E
* MX25L6465E
* MX25L6473E
Change-Id: Iae1753ca4cb051127a5bcbeba7f064053adb8dae
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Perform the check right in read_wp_bits() as it's used by various WP
operations and also because its results won't make sense if WPS bit is
on and can't be changed.
Change-Id: I143186066a1d3af89809b7135886cb8b0d038085
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Add a field, probe_opcode, to struct spi_master which points to a
function returning a bool by checking if a given command is supported by
the programmer in use. This is used for getting a whitelist of commands
supported by the programmer, as some programmers like ichspi don't
support all opcodes.
Most programmers use the default function, which just returns true.
ICHSPI and dummyflasher use their specialized function.
Change-Id: I6852ef92788221f471a859c879f8aff42558d36d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65183
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This code was originally introduced by ITE for now exceedingly old
Chromebooks. The code has had very little attention to maintain it,
unlikely tested for a long time and now seems to be just a technical
burden to the flashrom project.
If someone is later interested it could be resurrected for reference
from git history. However, it needs quite a bit of work to bring it back
into maintainable order.
BUG=b:156143896,b:170689483
TEST=tree builds under meson+make and unit tests pass.
Change-Id: I5e8cafd73db837941c518f0e2d72d8192274fd79
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65378
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the function name of extract_programmer_param() to
extract_programmer_param_str() as this function name will clearly
specify that it returns the value of the given parameter as a string.
Signed-off-by: Chinmay Lonkar <chinmay20220@gmail.com>
Change-Id: Id7b9fff4d3e1de22abd31b8123a1d237cd0f5c97
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65521
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
There is a function, spi_get_erasefn_from_opcode, which returns the
erase function for given opcode. Add a function which does the opposite
i.e. returns the opcode for given erase function.
Change-Id: Ia3aefc9b9465efdd16b1678bb2ada9a23f00d316
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Allow specialisation in opaque masters, such as ichspi hwseq, to
write to status registers.
Also update the dispatch logic in libflashrom to call wp code when
status register access functions are provided by an opaque master.
BUG=none
BRANCH=none
TEST=flashrom --wp-status on AMD and Intel DUTs
Change-Id: I3ab0d7f5f48338c8ecb118a69651c203fbc516ac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Co-Authored-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64375
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
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>
Projects using libflashrom like fwupd expect the user to wait for the
operation to complete. To avoid the user thinking the process has
"hung" or "got stuck" report back the progress complete of the erase,
write and read operations.
Add a new --progress flag to the CLI to report progress of operations.
Include a test for the dummy spi25 device.
TEST=./test_build.sh; ./flashrom -p lspcon_i2c_spi:bus=7 -r /dev/null --progress
Change-Id: I7197572bb7f19e3bdb2bde855d70a0f50fd3854c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Sergii Dmytruk
Edward O'Callaghan
Thomas Heijligen
Aarya Chaumal
Chinmay Lonkar
Nico Huber
Anastasia Klimchuk
Atul Dhudase
Richard Hughes