mirror of
https://review.coreboot.org/flashrom.git
synced 2025-06-30 21:52:36 +02:00
ea91d4fcf4
Some devices such as the GSC knows how it is wired to AP and EC flash
chips, and can be told which specific device to talk to. Other devices
such as Servo Micro and HyperDebug are generic, and do not know how they
are wired, the caller is responsible for first configure the appropriate
MUXes or buffers, and then tell the debugger which port to use (Servo
Micro has just one SPI port, HyperDebug is the first that has multiple).
The Raiden protocol allows both the cases of USB devices knowing their
wiring and not.
If I were to declare the protocol in Rust, this is how the information
of the Raiden protocol "enable request" would be encoded:
```
enum {
EnableGeneric(u8),
EnableAp,
EnableEc,
...
}
```
The first label `EnableGeneric(u8)` is to be used with HyperDebug that
does not know how its ports are wired, and allow access by index.
The other labels `EnableAp` and `EnableEc` are to be used with the GSC.
The actual transmission of the enum above uses the bRequest and low byte
of wValue of a USB control request, but that is a detail and not
conceptually important.
Until now, `-p raiden_debug_spi:target=AP` or `...:target=EC` could be
used to make flashrom use `EnableAp` or `EnableEc`, and if neither was
given, it would default to `EnableGeneric`, which now that wValue is
used means `EnableGeneric(0)`.
I find it rather straight-forward, that `-p raiden_debug_spi:target=1`,
`...:target=2`, etc. should translate to `EnableGeneric(1)`, etc.
This patchset achieves this, by adding a second 16-bit parameter value,
next to request_enable.
I have tested that flashrom can detect the same Winbond flash chip
"W25Q128.V..M" with two different Raiden USB devices as below.
TEST=flashrom -p raiden_debug_spi:serial=0701B044-91AC3132,target=AP
TEST=flashrom -p raiden_debug_spi:serial=205635783236,target=1
Signed-off-by: Jes B. Klinke <jbk@chromium.org>
Change-Id: I03bf4f3210186fb5937b42e298761907b03e08b7
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
flashrom README
===============
flashrom is a utility for detecting, reading, writing, verifying and erasing
flash chips. It is often used to flash BIOS/EFI/coreboot/firmware images
in-system using a supported mainboard, but it also supports flashing of network
cards (NICs), SATA controller cards, and other external devices which can
program flash chips.
It supports a wide range of flash chips (most commonly found in SOIC8, DIP8,
SOIC16, WSON8, PLCC32, DIP32, TSOP32, and TSOP40 packages), which use various
protocols such as LPC, FWH, parallel flash, or SPI.
Do not use flashrom on laptops (yet)! The embedded controller (EC) present in
many laptops might interact badly with any attempts to communicate with the
flash chip and may brick your laptop.
Please make a backup of your flash chip before writing to it.
Please see the flashrom(8) manpage :doc:`classic_cli_manpage`.
Building / installing / packaging
---------------------------------
flashrom supports building with **make** and **meson**.
TLDR, building with meson
"""""""""""""""""""""""""
::
meson setup builddir
meson compile -C builddir
meson test -C builddir
meson install -C builddir
For full detailed instructions, follow the information in
:doc:`dev_guide/building_from_source`
TLDR, building with make
""""""""""""""""""""""""
::
make
make install
For full detailed instructions, follow the information in
:doc:`dev_guide/building_with_make`
Contact
-------
The official flashrom website is:
https://www.flashrom.org/
For available contact methods see :doc:`contact`