This commit adds uses the new rpmc command implementation to
add them as a new feature to the cli_client.
Also adds the necessary documentation for this new feature.
Tested on the Winbond W25R128JV as a 'SFDP-capable chip'.
This patch was done to add rpmc command support to flashrom.
This enables users to write root keys to their flash chips while they
flash data on the chip. This might become useful in the future as rpmc
support is extended in coreboot.
Also adds debug tools to flashrom, which might be useful in
implementing coreboots rpmc support.
Change-Id: I36c823bbee65f256eb6edabe6f058321c9a0cfa1
Signed-off-by: Matti Finder <matti.finder@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84840
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The patch updates calculation of total length for the operation
which is displayed with progress.
The reason is: even if, for example the whole chip erase or write
was requested, the actual length of bytes modified can be less than
whole chip size (areas which already have expected content,
are skipped).
Change-Id: I88ac4d40f1b6ccc1636b1efb690d8d68bdebec08
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84439
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The patch adds command line option to handle the following situation:
There is a region which is requested to be erased (or written, because
the write operation uses erase too). Some of the areas inside this
region don't need to be erased, because the bytes already have expected
value. Such areas can be skipped.
The logic selects eraseblocks that can cover the areas which need to be
erased. Suppose there is a region which is partially covered by
eraseblocks of size S (partially because remaining areas don't need to
be erased). Now suppose we can cover the whole region with eraseblock
of larger size, S+1, and erase it all at once. This will run faster:
erase opcode will only be sent once instead of many smaller opcodes.
However, this will run erase over some areas of the chip memory that
didn't need to be erased. Which means, the chip, as a hardware, will
wear faster.
New command line option sets the maximum % memory that is allowed for
redundant erase. Default is 0, S+1 size block only selected if all the
area needs to be erased in full. 50 means that if more than a half of
the area needs to be erased, a S+1 size block can be selected to cover
all area with one block.
The tradeoff is the speed of programming operation VS the longevity of
the chip. Default is longevity.
Change-Id: I154e8a713f626c37dbbe118db700055b96d24803
Co-developed-by: persmule <persmule@hardenedlinux.org
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Signed-off-by: persmule <persmule@hardenedlinux.org>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84721
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
The existing page on old wiki is very small and fits into
a manpage item:
https://wiki.flashrom.org/NICIntel
Change-Id: I139065611c68c0fa0a675fe49a6f8bc20e9057f7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83751
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The patch adds a section on a manpage to explain the freq
parameter in dummyflasher, and tests for various valid and invalid
values of freq parameter.
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: Iaca5d95f8f977bf0c2283c6458d8977e6ce70251
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84423
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CH347 SPI interface supports up to 60M.
For example, to set a 30M spi rate, use -p ch347_spi:spispeed=30M.
Change-Id: If2be48929db540a6598ac0b60b37e64597156db7
Signed-off-by: ZhiYuanNJ Liu <871238103@qq.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82776
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Old wiki website is retired and so is print_wiki.c
Change-Id: I9990add27f7fdddc23ddd1f33306566ce7548417
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83941
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
These programmers have a little information about them on wiki.
It's too little info to create a dedicated page for each
programmer, however info can go to the manpage.
For reference, wiki pages are the following:
https://wiki.flashrom.org/NIC3Comhttps://wiki.flashrom.org/Gfxnvidiahttps://wiki.flashrom.org/Supported_programmers (search for the
programmers in the table).
Change-Id: Id2a2aefc6a3c8348fdaa4498aaa704fd2da7602f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83467
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When working with low-voltage chips, the internal 10k pull-ups
of the Bus Pirate might be too high. In such cases, it's necessary
to create an external pull-up using lower-value resistors. For this,
you can use the 'hiz' parameter. This way, the Bus Pirate will
operate as an open drain with 'pullups=off'
So, why not just use the 'pullups=on' option for this scenario? I'm
trying to prevent a very typical human error in the training sessions
I conduct.
For example, in the previous session, a user might have left the VPU
(vextern) connected to 5V, and now they need to access a 1.8V chip.
If 'pullups=on' is used, the following will happen:
5V (VPU) --> CD4060 --> 2K (internal Bus Pirate) --> MOSI target chip.
By having the option to set a 'hiz=on', this can be avoided. Since the
pull-ups will remain deactivated while the Bus Pirate will function in
an open-drain mode
Return init error for invalid values of pullups, hiz, psus. Previously,
invalid values of the params pullups, hiz, psus were handled as "off"
(i.e. disabled). This created a potential human error when users were
running flashrom with e.g. pullups=1 and expected pullups to be on,
while the value 1 was handled as invalid and off.
Change-Id: I6d9909b23782ef3fcb1428fd127dae0d6b211855
Signed-off-by: David Reguera Garcia <dreg@rootkit.es>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
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>
The feature will have patches coming soon and not completely
ideal yet.
At the moment, read and verify operations can show progress,
erase and write are not completely ready yet.
Change-Id: I9cacc60cb357c29f6625126d22a67a56de560887
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75439
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Currently, the code assumes the nCS pin of spi nor flash is connected to
either nRESET(pin 15) or nTRST(pin 3). But it is incompatible with the
pinout from official JFlash SPI, whereas the nCS pin is wired to TMS(pin
7).
This commit adds cs=tms option to share the same pinout as JFlash SPI.
It works by toggling TMS in assert_cs and deassert_cs, and sets TMS to
zero in jlink_spi_send_command. The default option is set to cs=reset
for backward compatibility.
Tested on macOS 13.3.1 with JLink and Winbond W25Q128
Change-Id: I0cb467fcc2c403a25f260462de0cd020e7022bb1
Signed-off-by: Jiajie Chen <c@jia.je>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/75011
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
This adds a parameter to drive the aux pin low (or high if you
explicitly want the previous behavior). Some boards need to have a reset
pin driven low before the firmware can be safely flashed. With the Bus
Pirate, this is most easily done with the auxiliary pin.
Change-Id: Ieeecfdf1afc06dadda9b8f99547cd74854ca6775
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/43608
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Use sphinx (sphinx-doc.org) to generate the UNIX man page from an
reStructuredText file instead of dealing with plain groff.
Use `meson setup -Dman-pages=enabled` to build the man page, and
`meson setup -Ddocumentation=enabled` to build the web documentation
explicitly. Both are enabled automatically if sphinx-build is found.
The man page will be installed as `<meson_mandir>/man8/flashrom.8` and
The html documentation in <meson_datadir>/doc/flashrom/html`.
The Makefile builds only the man-page format.
Increase the minimum version of meson from 0.53.0 to 0.57.0 to be
able to pass environment variables to the custom_target() command. That
is needed to pass the FLASHROM_VERSION to the documentation.
Change-Id: Iee9f1164c5913e47385e6f7d51dc7775a58b5a67
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72619
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
