As proposed on the mailing list ("RFC: remove the calibrated delay
loop" [1]), this removes the calibrated delay loop and uses OS-based
timing functions for all delays because the calibrated delay loop can
delay for shorter times than intended.
When sleeping this now uses nanosleep() unconditionally, since usleep
was only used on DOS (where DJGPP lacks nanosleep). When busy-looping,
it uses clock_gettime() with CLOCK_MONOTONIC or CLOCK_REALTIME depending
on availability, and gettimeofday() otherwise.
The calibrated delay loop is retained for DOS only, because timer
resolution on DJGPP is only about 50 milliseconds. Since typical delays
in flashrom are around 10 microseconds, using OS timing there would
regress performance by around 500x. The old implementation is reused
with some branches removed based on the knowledge that timer resolution
will not be better than about 50 milliseconds.
Tested by reading and writing flash on several Intel and AMD systems:
* Lenovo P920 (Intel C620, read/verify only)
* "nissa" chromebook (Intel Alder Lake-N)
* "zork" chromebook (AMD Zen+)
[1]: https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/HFH6UHPAKA4JDL4YKPSQPO72KXSSRGME/
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I7ac5450d194a475143698d65d64d8bcd2fd25e3f
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81545
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
The MX25R8035F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25R8035F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8749/MX25R8035F,%20Wide%20Range,%208Mb,%20v1.6.pdf
Change-Id: Iec244ffc29278c1f8c3ae47d17af2c4fe5fbe498
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81837
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MX25L12850F has been tested by ch341a programmer : read, write,
erase and wp.
We have tested --wp-enable, --wp-disable, --wp-list and --wp-range
commands for write-protect feature.
MX25L12850F datasheet is available at the following URL:
https://www.macronix.com/Lists/Datasheet/Attachments/8632/MX25L12850F,%203V,%20128Mb,%20v1.0.pdf
Change-Id: I71ac70d273904f94d015401f9d8df587084efad0
Signed-off-by: DanielZhang <danielzhang@mxic.com.cn>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81350
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Use build system to check header presence:
* getopt.h (from include/cli_classic.h)
* pciutils/pci.h (from include/platform/pci.h)
Tested with <getopt.h> and <pci/pci.h> using GNU Make 4.1, 4.2.1, 4.4.1
and Meson 0.56.0, 1.2.1 against GCC 13.2.1 and GCC 5.5-, 7.3-compatible
(EDG 4.14-, 5.1-based) on openSuSE Tumbleweed and a custom LFS distro.
Change-Id: Ic544963ffd29626ae0a21bdddb1c78850cc43ec6
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77089
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Q127C and Q128C are not the same. Q127C doesn't support QPI but Q128C
does. So we need to split the existing GD25Q127C/GD25Q128C into two
separated entries. We also introduce the new flashchip Q128E and merge
it into Q127C.
Datasheets:
Q128E: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00480-GD25Q128E-Rev1.2.pdf
Q127C: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20220714/DS-00220-GD25Q127C-Rev2.3.pdf
Q128C: https://www.endrich.com/sixcms/media.php/2/GD25Q128C-Rev2.pdf
Q128E and Q127C/Q128C have compatible main functions, their differences
are:
* Q128E uses 55 nm process, while Q127C/Q128C use 65nm
* Q128E/Q127C does not support QPI
* Q128E/Q127C have OTP: 3072B, while Q128C are 1536B
* Q128E's fast read clock frequency is 133MHz, while Q127C/Q128C are
104MHZ
So we decided to merge Q128E into Q127C.
We also tested that Q128E could pass flashrom_tester while probing it as
127C/128C, so the main functionalities are compatible.
Change the chip name from GD25Q127C/GD25Q128C to two entries
GD25Q127C/GD25Q128E and GD25Q128C to make it more accurate.
Chip revision history:
- The 'GD25Q127C/GD25Q128C' definition was added in
`commit e0c7abf219b81ad049d09a4671ebc9196153d308` as 'GD25Q128C' and
later renamed to 'GD25Q127C/GD25Q128C'
BUG=b:304863141, b:293545382
BRANCH=none
TEST=flashrom_tester with flashrom binary could pass with Q128E,
which contains probe, read, write, erase, and write protect
Signed-off-by: Hsuan Ting Chen <roccochen@google.com>
Change-Id: I3300671b1cf74b3ea0469b9c5a833489ab4914f5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78348
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Other chips (at least Winbond) will benefit from this change.
Also, drop the FIXME comment, as it can be misleading. The
"pretty print" functions should only display values from the
Status Register, so using an inappropriate function might only
confuse user.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I7169a2312698343e1065cdca91a3985e00cb3804
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78874
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Clean commit 51e1d0e4b7670e5822560acc724a6a8dd00b6af4
'Add support for Intel Emmitsburg PCH' which broke
CHIPSET_5_SERIES_IBEX_PEAK detection and which assumes C740 is the same
as C620, while its more a close relative to Intel's H570 PCH.
Based on Intel SPI Programming Guide #619386.
Test: Run on Intel ArcherCity CRB with Intel's C741 PCH
using the 'internal' programmer.
Test: Run on BMC and accessed the SPI flash chip over
'linux_mtd' programmer.
Change-Id: I80eebc0fcc14de9df823aceaee77870ad136f94a
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78186
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
XM25QH80B has the same ID as M45PE80, but has more features.
Tested with CH341A.
Change-Id: Ib51225426d8d1a381d45af3574e5ba2bf02837aa
Signed-off-by: Sungbo Eo <mans0n@gorani.run>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63516
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Based on https://github.com/flashrom/flashrom/pull/204
squashed with fixes of IS25WQ040 size: it is 4Mbits, not 4MBytes, see
https://www.issi.com/WW/pdf/25WQ020-040.pdf
Tested read, write and erase with ft2232_spi-based "Tigard" programmer.
Change-Id: I072c6b94d7931637d1c2721c3316205f2d57320e
Signed-off-by: Roman Stingler <roman.stingler@gmail.com>
Signed-off-by: Vasily Galkin <galkin-vv@ya.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58179
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
