Tested using the linux_spi programmer on a Raspberry Pi.
Datasheet:
https://media.digikey.com/pdf/Data%20Sheets/Macronix/MX25L3255E.pdf
Signed-off-by: Joseph C. Lehner <joseph.c.lehner@gmail.com>
Change-Id: I65968771e22e6b823d2d6192c33f5b0cba25d5b9
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57410
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Layouts can be expensive to derive (reading from flash), so we might
want to reuse a layout for different purposes. Today, it's not possible
to undo a flashrom_layout_include_region() operation (to, say, operate
on a different region). Add such an API.
Change-Id: I7ea3e0674f25e34bf2cfc8f464ae7ca1c1a3fbfd
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/76005
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested: read, write and erase.
Chip (and datasheet) have recenty been removed from XMC's website
but can still be retrieved through web archive:
https://web.archive.org/web/20221122191724/https://www.semiee.com/file/XMC/XMC-XM25QH128A.pdf
Signed-off-by: Stijn Segers <foss@volatilesystems.org>
Change-Id: Iced40403c6694a55fd648ea2785cdcba21712234
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69309
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
I took the original patch from Ondrej Hennel [1] and applied the
requested changes. Reading, erasing and writing works.
[1] https://patchwork.ozlabs.org/project/flashrom/list/?series=261647
Change-Id: Iffd7c4284d4d96b30a94f5dee882b5403fdfc183
Signed-off-by: Mario Kicherer <dev@kicherer.org>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested read/write/erase/probe operations with a ch341a_spi programmer.
Datasheet is available at https://www.mouser.de/datasheet/2/590/DS-AT25DF011_032-1098683.pdf
Signed-off-by: Hanno Heinrichs <hanno.heinrichs@rwth-aachen.de>
Change-Id: I5a2141f1380e864c843d6a3008fdb02dc1b75131
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/51048
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The flashbase is a machine-sized integer representation of
address space and so use the appropriate type that is correctly
sized to encode such data.
The flashbase is assigned to 'base' in 'map_flash()' and the
type correctly changed to uintptr_t in commit 4e32ec19b124a7
therefore makes for a consistent type usage whenever stored.
While `sizeof(unsigned long)` and `sizeof(uintptr_t)` are both `8` under
most circumstances on a 64bit platform and thus have enough bits to
represent all addresses on the platform, the C standard does not
guarantee this. Only `uintptr_t` and `void *` has a guaranteed
isomorphism as `uintptr_t` is defined by the platforms toolchain support
whereas the conversion from `void *` to an integer is implementation
defined and that the memory address value may contain additional bits
describing the validation data or provenance of the address. Therefore a
integer is insufficient to contain all the necessary information for
that specific platform so this may not always work out for all platforms
and toolchain combinations.
Spotted-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Change-Id: Ib9057e438731b9cccde0e24d5c8f758c3af1d47f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75328
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
Flashrom only tries to use WP-based unlocking if it detects that WP
operations are supported. However WP support was detected in a way that
ignored WP operations provided by opaque masters.
This stopped flashrom from automatically unlocking with some opaque
masters, particularly linux_mtd.
This commit also deletes part of a test that required the chip unlock
function to be called before read/write/erase operations because WP
unlocking is now used instead of chip unlocking.
BUG=b:280111380
BRANCH=none
TEST=Checked flashrom automatically unlocked flash on strongbad (MTD)
Change-Id: I1774ad64d82ae47cd085df6045e17e283855c01f
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Some systems, DJGPP/DOS for now, may not provide getopt and their gnu
extensions. So provide a fallback implementation.
The code is based on musl libc.
Change-Id: I6ebbde075014e3b45b0f9e04b34b72aa969e1197
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73102
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to how internal is structured around chipset_flash_enable()
entry we need to prepare a crafted programmer_cfg that contains
a board_enable substructure with data derived from the board_enable
subsystem. While this is certainly not perfection, it does make
clear the relationships between board_enable into chipset_flash_enable
and subsequently the overall internal programmer initialisation
in a RAII fashion at the type level over closure upon global
state that is impossible to reason about.
Also flip predicate in report_nonwl_laptop_detected() and
return early with the trivial base-case.
TEST=`$ sudo ./flashrom -p internal --flash-name`.
Change-Id: I459215253845c2af73262943ce91a36464e9eb06
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Some boards need to configure the programmer in specific ways.
For example, a programmer such as internal may need to be configured
either as laptop or not type and as such the board enable needs the
ability to feed state back into the programmer configuration. Plumb
this though by creating a board_cfg structure that can be packed.
Change-Id: I7058a693e714a6966a842ae97cc8da7296e63e5e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71623
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prefix the remaining global cases with `g_` to avoid shadowing
issues and for easy greping.
Change-Id: I3d5ad6c0623269492d775a99a947fd6fe26c5f91
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Avoid global symbol shadowing in local functions.
Change-Id: Idfca0b7e46d8051bf680227250cf40483e19dc53
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
See https://www.mxic.com.tw/Lists/Datasheet/Attachments/8662/MX25V1635F,%202.5V,%2016Mb,%20v1.4.pdf .
I've tested this patch with the MX25V1635F I have here, using serprog
and ftdi by (re)writing a few images to the flash and seeing if changes
were stored correctly. This also included erasing and rewriting the
memory with completely different data, so erase is tested, too.
Change-Id: I58ddaaa96ef410d50dde3aaa20376c5bbf0f370b
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
See https://www.macronix.com/Lists/Datasheet/Attachments/8405/MX25V8035F,%202.5V,%208Mb,%20v1.0.pdf .
I've only tested this patch with the MX25V1635F I have here, though
other chips in the series exist as well. Tested using serprog and ftdi
by writing a few images to the flash and seeing if changes were stored
correctly.
Change-Id: Ic5be2da4cfa2a2ff044a519bb6f367f21c15e4b8
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
See https://www.macronix.com/Lists/Datasheet/Attachments/8670/MX25V4035F,%202.5V,%204Mb,%20v1.2.pdf .
I've only tested this patch with the MX25V1635F I have here, though
other chips in the series exist as well. Tested using serprog and ftdi
by writing a few images to the flash and seeing if changes were stored
correctly.
Change-Id: I8b26926c354b840ca7b14b4c5cb000e3c02f5137
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Converting the printlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: I9131348f72c1010e2c213dca4dc4b675a8d8681e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
As Edward pointed out correctly this function does more than abstracting
the different versions of `pci_get_dev()`. It also hide the usage of
the global `struct pci_access pacc` from the caller.
This reverts commit 0e8902f1ff2b927bb91a5e89e4fde3d8d71f6692.
Change-Id: I0cd2f54cb6a6e35dc353476e0f5e502cbbd06cba
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Converting the blockprotect unlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: Ie5c5db1b09d07e1a549990d6f5a622fae4c83233
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This function is only called once. Move the content of the function into
the caller.
Change-Id: Id2983420080f75ae6992edfb032bf5c83b29c803
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73570
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This version was released in september 2005 and had a breaking api
change. Drop it so that we don't need to maintain the old codepath any
longer. Beside that, we have already a second codepath which is using
the new `pci_get_dev` variant exclusively.
Change-Id: If943db350b561a005d8292a53d9255223db3d571
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Some NetBSDs have the pci.h under pciutils/ instead of pci/. But we
can't say for sure which variants uses which include path. Just test
them with the __has_include() compiler macro.
https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005finclude.html
Change-Id: Ib20de6bffede910b89937f554b4d56f4799f0762
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73292
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => true' as to not need this
boilerplate as it implies default behaviour of a supported
opcode within the `check_block_eraser()` match supported loop.
Ran;
```
$ find . -name '*.[c,h]' -exec sed -i '/.probe_opcode = default_spi_probe_opcode,/d' '{}' \;
```
Change-Id: Id502c5d2596ad1db52faf05723083620e4c52c12
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70264
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Avoid these leaking into driver implementations as a NULL
field now implies their implementation. This removes one
source of a driver bug where both `mst->command` AND
`mst->multicommand` are set to default implementations
which is actually a cyclical control flow condition.
The driver however must still have either `mst->command` OR
`mst->multicommand` defined and so both cannot be NULL.
This simplifies the code and driver development.
Change-Id: I4ef95846c2f005cf4aa727f31548c6877d2d4801
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Add a new wp_cfg_to_reg_values() function that takes a generic wp_cfg
instance and returns the chip-specific values that need to be written to
the chip's registers to enable the specified protection range/mode.
The function returns three values for each chip register:
- reg_values[reg] - Value writeprotect will write to reg
- bit_masks[reg] - Bit mask for WP-related bits in reg
- write_masks[reg] - Bit mask for writable WP-related bits in reg
(i.e. the ones writeprotect will try to write)
BUG=b:260019525,b:259013033,260020006
BRANCH=none
TEST=ninja test
Change-Id: Ib2a47153b230c9f82bb4eca357c335f2abbacc20
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69847
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Add support for the WCH CH347, a high-speed USB to bus converter
supporting multiple protocols interfaces including SPI. Currently only
mode 1 (vendor defined communication interface) is supported, mode 2
(USB HID communication interface) support will be added later. The code
is currently hard coded to use CS1 and a SPI clock of 15 MHz, though
there are 2 CS lines and 6 other GPIO lines available, as well as a
configurable clock divisor for up to 60MHz operation. Support for these
will be exposed through programmer parameters in later commits.
This currently uses the synchronous libusb API. Performance seems to be
alright so far, if it becomes an issue I may switch to the asynchronous
API.
Tested with a MX25L1606E flash chip
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: I31b86c41076cc45d4a416a73fa1131350fb745ba
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70573
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ASMedia ASM106x series is a PCIe-SATA controller chip. It supports
an attached SPI flash chip that can contain configuration and PCI option
ROM. The interface is a simple shifter accessed via PCI config space,
up to 4 bytes at a time. Add a programmer driver for it.
Tested on a G536PCE1061V11 IO-PCE1061-V1.1 PCIe card, and
a MPCE2ST-A01 VER006S mini-PCIe card, both with chips marked ASM1061,
both enumerate as:
01:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02) (prog-if 01 [AHCI 1.0])
Subsystem: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:1060]
Change-Id: I591b117be911bdb8249247c20530c1cf70f6e70d
Signed-off-by: Alex Badea <vamposdecampos@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73037
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Call the function before tcsetattr() settings are known, then again
with settings prepared but not yet applied and finally a third time
after tcsetattr().
Darwin support needs this change; there custom_baud code must be
called to modify the settings passed to tcsetattr() and then again
after tcsetattr() returns.
The change should be non-functional on all currently supported systems;
current code calls set_custom_baudrate() before any tcsetattr()
settings are prepared, so we have three stages in total.
This change originates from discussion of the macOS patch proposed by
Denis Ahrens in https://review.coreboot.org/c/flashrom/+/67822
Change-Id: I40cc443cfb7bf6b212b31826d437b898cc13c427
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70569
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The parallel internal programmer is its own implementation. Move
it and call into it from the top-level internal.c programmer
implementation.
Change-Id: Idabeceb59a36680f5fbb45d3ee4bd5dbf837373b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71834
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
1) Add function to flatten out the addresses of the flash chip as per
the different erase functions. This function will return a list of
layouts which is dynamically allocated. So after use all the layouts as
well as the list itself should be freed. The free_erase_layout function
does that.
2) Add function to align start and end address of the region (in struct
walk_info) to some erase sector boundaries and modify the region start
and end addresses to match nearest erase sector boundaries. This
function will be used in the new algorithm for erase function selection.
3) Add function that returns a list of sectors (as seen by the first
erase function) that need erasing.
4) Add a function to call the erase algorithm.
Change-Id: Ic57ca1cca3d1646543f6b5939ba9c35db8d08256
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The dummyprogrammer in the opaque case can have a NOP delay
to avoid wasting CPU time and energy.
BUG=b:266014935
TEST=builds
Change-Id: Ia86ad21f011214abc2aa0891a43559f91e2a9591
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72424
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Chip restore callbacks currently are used by
- spi25_statusreg.c unlock functions to restore status register 1.
- s25f.c to restore config register 3.
Both of these cases only need to save a single uint8_t value to restore
the original chip state, however storing a void pointer will allow more
flexible chip restore behaviour. In particular, it will allow
flashrom_wp_cfg objects to be saved and restored, enabling
writeprotect-based unlocking.
BUG=b:237485865,b:247421511
BRANCH=none
TEST=Tested on grunt DUT (prog: sb600spi, flash: W25Q128.W):
`flashrom --wp-range 0x0,0x1000000 \
flashrom --wp-status # Result: range=0x0,0x1000000 \
flashrom -w random.bin # Result: success \
flashrom -v random.bin # Result: success \
flashrom --wp-status # Result: range=0x0,0x1000000`
Change-Id: I311b468a4b0349f4da9584c12b36af6ec2394527
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70349
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The new erase algorithm uses some of the functions which are static to
`flashrom.c`. So make these functions global and add prototypes to
`include\flash.h` and `include\layout.h'.
Change-Id: I7ee7e208948337b88467935fd2861b5f9ad6af9d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Make `force_boardenable` stack local to the internal_init()
entry-point. It's life-time should not exceed that of the
internal's init entry function.
Change-Id: I3324681f024003694a5531d9d35bb13d2c583eb0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70031
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Validate (flash->chip->bustype == BUS_SPI) as ich copies the
chip flags in the opaque master and tries incorrectly
to issue 4BA commands which results in failure.
The issue was detected only in the case of chips >16MB, in
this case 'W25Q256FV' that has the feature bits:
```
.feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_4BA_ENTER_WREN |
FEATURE_4BA_EAR_C5C8 | FEATURE_4BA_READ | FEATURE_4BA_FAST_READ |
FEATURE_WRSR2,
```
The regression was noticed from,
commit 0741727925b841c2479b993204ce58c5eb75185a ichspi.c: Read chip ID and use it to populate `flash->chip`
TEST=In the case of 'W25Q256FV' on TigerLake.
Change-Id: I7cce4f9c032d33c01bf616e27a50b9727a40fe1b
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71269
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-by: Sam McNally <sammc@google.com>
A NULL func pointer is necessary and sufficient for the
condition `NULL func pointer => fallback_chip_X' as to not
need this explicit specification.
Therefore drop the explicit need to specify these fallback
callback function pointer in the par_master struct.
This is a reasonable default for every driver in the tree.
Furthermore, move the 'fallback_chip_X()' func from the
generic programmer.c register logic into its relevant
home of parallel.c and make static local to clean up
link-time symbol space.
This simplifies the code and driver development.
Change-Id: If25c0048a07057aa72be6ffa8d8ad7f0a568dcf7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71745
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add flags to allow libflashrom users to configure how operations that
include unreadable or unwritable regions should be behave.
If the flags are set to true, a read/write operation will just skip the
inaccessible region and will still be executed in other regions.
If the flags are set to false, the inaccessible region will cause the
entire operation to fail.
BUG=b:260440773
BRANCH=none
TEST=builds
Change-Id: I9b96fb04b863625d2c9f9a00b97c35b3ddb0871b
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70128
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add a get_region function to spi and opaque masters so that they can
expose access permissions for multiple regions within the flash.
A get_region() implementation is added for the ichspi driver in a
following patch.
Finally, another patch uses get_region() to make read_flash() and
write_flash() skip inaccessable regions, making read, write, and erase
operations work on Intel platforms with active an CSME coprocessor.
This logic will be integrated with layout in the future, but for now
this moves ichspi support forward without making refactoring too hard
later on.
BUG=b:260440773
BRANCH=none
TEST=ninja test
Change-Id: I8c43f6b705f36ef18842a04ba6241d3a0b36b232
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70126
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add protection bits to `struct flash_region` to keep track of the CSME
restrictions for each flash region.
BUG=b:260440773
BRANCH=none
TEST=builds
Change-Id: I0e5b3b4369dc868a8a64338935c5c5249b9a4ada
CoAuthored-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70437
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The romentry structure is the container ADT with some
annotated meta-data such as 'included' or 'file' however
the substantive substructure is a 'flash_region'. Therefore
factor this out.
That is to say, the link list node 'romentry' is obscured by the implementation details of its use-case of 'flash_region' that we
clear up here.
BUG=b:260440773
BRANCH=none
TEST=flashrom_tester
Change-Id: I768742b73db901df5b5208fcbcb8a324a06014c2
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69196
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
