Perhaps some of the users will be able to follow the instructions
and send a patch to mark chip as tested. The option to send report
to the mailing list remains available as before.
Change-Id: I36105725058f2fecb82408c369b70b3324502ece
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81266
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
By default, we busy-loop (a.k.a., "delay") for most delay values, and
only allow sleeping for large delays. But busy-looping is expensive, as
it wastes CPU cycles.
In a simple program that runs a bunch of samples of [1] over 1000
samples, I find that for 0.1 s (100000 us):
64x2 AMD CPU (CONFIG_HZ=250 / CONFIG_NO_HZ_FULL=y):
min diff: 60 us
max diff: 831 us
mean diff: 135 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=1):
min diff: 70 us
max diff: 1556 us
mean diff: 146 us
4+2 Mediatek MT8183 CPU (CONFIG_HZ=1000 / CONFIG_NO_HZ_IDLE=y /
sysctl kernel.timer_highres=0):
min diff: 94 us
max diff: 7222 us
mean diff: 1201 us
i.e., maximum 1.5% error, typically ~0.1% error with high resolution
timers. Max 7% error, typical 1% error with low resolution timers. The
error is always in the positive direction (i.e., sleep longer than the
requested delay, not shorter than the request).
This seems reasonable.
[1] Stripped / pseudocode:
clock_gettime(CLOCK_MONOTONIC, before);
nanosleep({ .tv_nsec = usecs * 1000 }, NULL);
clock_gettime(CLOCK_MONOTONIC, after);
diff = abs((after - before) / 1000 - usecs));
Change-Id: Ifd4821c66c5564f7c975c08769a6742f645e9be0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80808
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
flashrom_init() may run through an expensive delay calibration phase,
depending on the system timer behavior (e.g., if high resolution timers
are disabled). This is wholly unnecessary if we're only going to dump
usage output or similar.
Defer the calibration until we've finished our CLI overhead.
BUG=b:325539928
TEST=`flashrom --help` with `sysctl kernel.timer_highres` == 0
Change-Id: I57949ab511df04c6922008fa8cb12467154e2c5e
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Flashrom has several magic programmer_delay() calls scattered throughout
its codebase (see cli_classic.s/main() and
flashrom.c/flashrom_image_write(), at least). These delays are
superfluous for the linux_mtd programmer, because it's an opaque
programmer in which all protocol details are handled by the kernel
driver.
Stub out the delay function, so we don't waste up to 1.1 seconds of
needless delay time, depending on the operation and CLI vs libflashrom
usage.
BUG=b:325539928
TEST=`elogtool add 0xa7` on a linux_mtd system (such as a Mediatek
Chromebook):
Time improvement - reduces from ~1.5s wall clock to about 0.4s
CPU usage: -90%, as most of the CPU cycles (before this change) are
spent in needless magic-delay busy loops
Change-Id: I3ac69d3fd7cfc689c5b32c130d044516ed846c29
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80771
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Same approach as it was before: founder and current project lead.
Change-Id: I1043b9499ab22da5ec981592d7b4311f027c4b5f
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81106
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's not valid to separately check the major and minor versions. The
proper minor check would be something like:
if (fmap->ver_major == FMAP_VER_MAJOR &&
fmap->ver_minor > FMAP_VER_MINOR)
ERROR();
But this code was alleged (at introduction in [1]) to have come from
cbfstool, and cbfstool doesn't bother with a minor version check. This
check is only for finding the FMAP while searching the flash; it isn't
actually here for integrity and compatibility purpose.
Drop the MINOR version check; align with cbfstool on the MAJOR version
check; and match the cbfstool comments for is_valid_fmap(), to emphasize
the lack of precision.
[1] Commit c82900b66142 ("Add support to get layout from fmap (e.g.
coreboot rom)")
BRANCH=none
BUG=b:288327526
TEST=libflashrom + ChromiumOS flashmap
Change-Id: I984835579d3b257a2462906f1f5091b179891bd0
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79060
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
* serprog.h doesn't exist, so refer to .c source instead
* in the doc, no other command has S_CMD_ prefix either
Change-Id: Ic83e7fd80840f2db0b006935a964721da0388068
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Match the version string for `make` builds to that of `meson` builds
from both Git- and non-Git (release or current snapshot) source trees.
Change-Id: I8694e618878823a9e96b1f2bcfa63f6c71d3c2ed
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79152
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Also add link to "How to add new doc" into a collection of
Contributors howtos.
The doc stays in root of docs, and also in the main left-side
menu on the website, so that it is very easy to discover. Everyone
who has even the slightest motivation to update the docs, should
be able to find instructions easily.
Change-Id: I882de0614ab76b8e83b0fafa67296526fecd8a16
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80631
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As of version 3.x, `sphinx-build` outputs man pages to "8" directory
instead of "man8" expected by Makefile and doc/meson.build. See:
https://github.com/sphinx-doc/sphinx/issues/7996https://github.com/sphinx-doc/sphinx/issues/9217
Current solution is to rename "8" to "man8" after documentation build.
That enables successful build and installation, as well as dependency
tracking at build-system level, but not on `sphinx-build` own level
upon which `meson` build blindly relies.
Change-Id: I9cd280551a1ba4d17edb2e857d56f80431b61e1b
Signed-off-by: Anton Samsonov <devel@zxlab.ru>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77778
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
partial_lock_test (Lock_top_quad, Lock_bottom_quad, Lock_bottom_half,
and Lock_top_half) tries to:
1. Disable HWWP
2. Lock partial
3. Enable HWWP
4. Try to write the locked partial and expect a failure
...
The 4th step only works on flashrom binary since the binary will set
FLASHROM_FLAG_VERIFY_AFTER_WRITE=1 by default and it will error out
while verifying.
But libflashrom does not set any flag beforehand, so it has
FLASHROM_FLAG_VERIFY_AFTER_WRITE=0 and thus it will think the write
command works normally and raise no error. This causes the issue that
flashrom_tester with libflashrom has been failed until today.
To solve this issue, there are two solutions:
1. Take care of the default flags in libflashrom
2. Always pass --noverify to flashrom binary and verify it afterwards.
To make both methods more consistent, I fix it with approach 1.
BUG=b:304439294
BRANCH=none
TEST=flashrom_tester internal --libflashrom Lock_top_quad
Change-Id: I7a8ac0c0984fef3cd9e73ed8d8097ddf429e54b2
Signed-off-by: roccochen@chromium.com <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79304
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For reference, link to doc about adding new chip
on the old website:
https://wiki.flashrom.org/Development_Guidelines#Adding/reviewing_a_new_flash_chip
Docs on how to update test status of flashchips never existed before.
Change-Id: I8dde689f2a0430ae10d3fa68bee727c5a9d70aec
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/80205
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
The test cases from #16 onwards cover the case when layout region is
not aligned with eraseblock region, and therefore either layout start
boundary or end boundary needs to be extended to align with
eraseblock.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I726a30b0e47a966e8093ddc19abf4a65fb1d70ce
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78985
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In the case when layout region is not aligned with eraseblock,
end region boundary is extended to match the eraseblock. There is
a special handling of this extended area (between original end of
region and extended one). Fix the offset of this extended area by +1
so that it covers the extended area and not the original region.
Before the patch, the last byte of the original region was failed to
write since it was treated as if an extended area, while it was the
last byte of the normal layout region.
Ticket: https://ticket.coreboot.org/issues/494
Change-Id: I7f78a0090065cd2a952cba1a5d28179483ba4c55
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78984
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
datasheet: https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20221129/DS-00562-GD25LQ255E-Rev1.1.pdf
BUG=b:311336475
TEST=Verified on karis
w/o this patch:
$ flashrom_tester --flashrom_binary ./flashrom internal Lock_top_quad
--> Failed
w/ this patch:
$ flashrom_tester --flashrom_binary ./flashrom internal Lock_top_quad
--> Pass
This lock_top_quad test did(copied from partial_lock_test()):
* Disable hardware WP so we can modify the protected range.
* Then enable software WP so the range is enforced and enable
hardware WP so that flashrom does not disable software WP during the
operation.
* Check that we cannot write to the protected region.
* Check that we can write to the non protected region.
Change-Id: I1425e931433c00caceaabc6037a79099d6d5eac5
Signed-off-by: Tyler Wang <tyler.wang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79460
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Previously, in the worst-case scenario of erasing region content then
writing new data, three rounds of verification were performed inside of
the `erase_write` function through calls to:
1. `check_erased_range` when erasing with respect to region boundaries
2. `check_erased_range` for the entire erase block after the loop
containing verification 1 completed
3. `verify_range` when all erases/writes were complete
Verification 2 duplicated verification 1 and was orphaned by commit
fa8808595a, which dropped its paired erasefn call but missed this
related step.
Verification 3 duplicated verification which occurs in
`flashrom_image_write` based on `flashctx flags`.
Now, these 2 redundant verifications are removed to improve the
performance of `erase_write`.
This change was tested using the linux_spi programmer to erase and write
to an MT25QL512 chip.
Change-Id: I638835facd9311979c4991cc4ca41a4b9e174bd5
Signed-off-by: Carly Zlabek <carlyzlabek@gmail.com>
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79354
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
After WP output format changed, the flashrom_tester will always read
software write protect is disabled.
BUG=b:300300436
TEST=Verify on flashrom_tester
Change-Id: I755891e0d8b5857650febe08c2094733cf1f4c79
Signed-off-by: Scott Chao <scott_chao@wistron.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77887
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Tested-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.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>
If none of "Full name" or "Display name" is set for a Gerrit account,
code reviews emails are sent from "Name of user not set" instead of
a user name. It is worth clarifying explicitly in the docs.
Change-Id: I69b6f5c1c56a2798dd156582cb5fa246b2396ab3
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79250
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Stanislav Ponomarev <me@stasponomarev.com>
CONFIG_INTERNAL depends on raw mem access resulting in the following
build failure on sh4 since version 1.3.0:
/home/thomas/autobuild/instance-3/output-1/per-package/flashrom/host/bin/../lib/gcc/sh4a-buildroot-linux-gnu/12.3.0/../../../../sh4a-buildroot-linux-gnu/bin/ld: libflashrom.a(internal.o): in function `internal_chip_readn':
internal.c:(.text+0x8): undefined reference to `mmio_readn'
Fixes the build raised by buildroot autobuilders with the following
options:
- CONFIG_FT2232_SPI=no
- CONFIG_USBBLASTER_SPI=no
- CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=yes
- CONFIG_ENABLE_LIBPCI_PROGRAMMERS=yes
Here is the target information:
C compiler found: sh4a-buildroot-linux-gnu-gcc.br_real (Buildroot 2022.08-rc1-5515-gf1a47904b63) 12.3.0
Target arch: sh
Target OS: Linux
Target endian: little
Full build log:
- http://autobuild.buildroot.org/results/f74a9d315fb519f284428234713f43fcf4e35fd0
Change-Id: I7610f5f7cc5b114ffa90d5752155acc8b6b7c9f7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
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>
During the development of an esp32 serprog-compatible SPI programmer,
and implementation of the TCP over Wi-Fi for serprog,
I discovered that sp_flush_incoming() silently fails
if the underlying sp_fd descriptor is a TCP socket.
This patch adds a check for this case - tcflush returns ENOTTY,
meaning tcflush is not supported for not terminal objects,
in this case a fallback serialport_read_nonblock loop is used.
TESTED=esp32-serprog, TCP-over-WiFi mode, ~90% connection attempts fail to synchronize without patch; no synchronization issues with patch applied.
Signed-off-by: Stanislav Ponomarev <me@stasponomarev.com>
Change-Id: I9724a2fcd4a41dede2c15f83877efa6c3b0b7fae
Reviewed-on: https://review.coreboot.org/c/flashrom/+/79112
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>
The test checks that algorithm for erase functions selection
works and there are no regressions.
Specifically, test contains an array of test cases. Each case
initialises a given initial state of the memory for the mock chip,
and layout regions on the chip, and then performs erase and write
operations.
At the end of operation, test asserts the following:
- the state of mock chip memory is as expected, i.e. properly erased
or written
- erase blocks are invoked in expected order and expected number
of them
- chip operation (erase or write) returned 0.
Change-Id: I8f3fdefb76e71f6f8dc295d9dead5f38642aace7
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Erasefn was invoked over the same block of memory twice.
This patch removes the second redundant invokation. It was
accidentally introduced during earlier refactoring of the code.
Change-Id: I92351eba0fd29114ce98b4a839358e92d176af28
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/77747
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@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>
Running tests is one of the regular things to do in dev process,
same as compile, so it should be highlighted in the TLDR section
of the document.
The patch adds test command to TLDR version in README file, and
in dedicated meson instructions doc.
Change-Id: I67d5f4decdac15e6a72f4372135dab7d44396594
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78689
Reviewed-by: Jes Klinke <jbk@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
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>
The code uses "%-4s" to print the master names and thus assumes that
all names have 4 characters or less. Convert "unknown" to "DevE",
short for Device Expansion in order to properly display the table.
Test: Run flashrom -p internal -VV
Change-Id: I0d10e2771c7a27c1a73ed53a33e68a04eb9e1e00
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78301
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Allow nm, the number of flash masters, to be equal to
ARRAY_SIZE(master_names). The previous logic was probably overlooked
when ich_number_of_masters() was introduced. The loop below makes sure
that it doesn't access the master_names array out of bounds.
Change-Id: Ib9276a6c29952487db6e60fb583942c0f24cd6ef
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78300
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
As a starting point, copying coreboot's one in the absence
of our own.
coreboot's CoC exists for some time and is known to work, so
it's a good starting point. We can iterate on this and make
upgrades and amendments that make sense for flashrom community.
Meanwhile we can share code of conduct with coreboot. We
do have the same servers and infrastructure anyway.
Change-Id: Icd82ba79687da3a2698d84f5cbfe824fbab0c426
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/78203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
