Original progress reporting implemented in CB:49643 and it has some
issues, for example:
size_t start_address = start;
size_t end_address = len - start;
End address is anything but length minus start address.
update_progress(flash,
FLASHROM_PROGRESS_READ,
/*current*/ start - start_address + to_read,
/*total*/ end_address);
Total should just be length if that's how current value is computed.
---
libflashrom needs to know total size ahead of time.
That's init_progress() and changed update_progress().
It also needs to store the last current value to be able to update it.
That's stage_progress in flashrom_flashctx.
Measuring accurately amount of data which will be read/erased/written
isn't easy because things can be skipped as optimizations. The next
patch in the chain aims to address this, there are TODO/FIXME
comments there.
---
CLI shares terminal with the rest of the code and has to maintain more
state to handle that reasonably well.
Similar to CB:64668, an effort is made to keep the progress on a
single line. Non-progress output is kept track of to know when
moving to a new line cannot be avoided.
---
A script to test the CLI:
\#!/bin/bash
t=${1:-rewW}
shift
if [[ $t =~ r ]]; then
echo ">>> READ"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -r dump.rom --progress "$@"
echo
fi
if [[ $t =~ e ]]; then
echo ">>> ERASE"
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -E --progress "$@"
echo
fi
if [[ $t =~ w ]]; then
echo ">>> WRITE (without erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -w zero.rom --progress "$@"
echo
fi
if [[ $t =~ W ]]; then
echo ">>> WRITE (with erase)"
dd if=/dev/zero of=zero.rom bs=1M count=16 2> /dev/null
dd if=/dev/random of=random.rom bs=1M count=16 2> /dev/null
./flashrom -p dummy:emulate=W25Q128FV,freq=64mhz,image=random.rom -w zero.rom --progress "$@"
echo
fi
Co-developed-by: Anastasia Klimchuk <aklm@flashrom.org>
Co-developed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: If1e40fc97f443c4f0c0501cef11cff1f3f84c051
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/84102
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Based on public Intel 700 Series PCH datasheet, DOC 743835 rev 004.
The IDs of IoT chipset SKUs (ending with E) can only be found in "12th
Gen Intel® Core™ Processors Family (Formerly Known as Alder Lake -S)
for IoT Platforms External Design Specification (EDS) Addendum" DOC
634528 rev 2.7 (NDA).
TEST=Probe flash on Z790 chipset. Run the ich_descriptors_tool and
check the output is correct as expected.
Change-Id: I13ac52d5400c0e2260e12d605077fc2182c379ef
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
In the latest pciutils(v3.13.0), it supports accessing pci registers
by ecam. This patch uses libpci version check to decide whether
flashrom calls libpci and use 0xcf8/0xcfc or ecam to access pci
registers.
BUG=b:359813524
TEST=with libpci >= 3.13.0, flashrom is working with ECAM access
Change-Id: I4549f87c8b01da0a1d3d8ce0b3b75c1f5fa2cbab
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hsuan-ting Chen <roccochen@google.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
As was described in the version 1.4 release notes, this deletes the
Makefile and supporting elements leaving Meson as the only supported
buildsystem.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: Ib3cf22cf636ef9b70527b734ffa34aead2a74edd
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83673
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Feature bits are too complicated to understand if we only read the
codes/datasheets. Add a new section in how_to_add_new_chip to add more
details about each feature bits.
Add the detailed explanation for WRSR handling first. If this new
section looks good, I'll try to add some more sections in further
commits.
BUG=b:345154585
TEST=meson compile -C builddir and view the doc.
Change-Id: I34c20933a375380c8702f79ac637595cd3466000
Signed-off-by: Hsuan Ting Chen <roccochen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82908
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Current numbers are taken from the output of `flashrom -L` command.
Intro page still has a room for improvement, but as a first step the
numbers need to be updated. In future, maybe there is a way to update
the numbers less manually.
Change-Id: I7531521955dcf01348ed2ba9c54316b32b9cd925
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/83130
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default toctree in the index file displays full tree of docs
with all the nested levels, and it's too much detail. Besides, left
side menu displays the tree anyway, so duplication is not needed.
Supported hardware section has the deepest nesting out of all other
docs.
This patch changes high-level index files to only display flat list
of next level subtree. On deeper level, full index is displayed.
Change-Id: Ia15e9766cce6f19be1e69fbb1236a327ae3d57b3
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/82196
Reviewed-by: Sydney <git@funkeleinhorn.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When html page is generated, all headers are generated as links on
the page. It is useful to have OS specific instructions as a link
to share with people.
Change-Id: I78645131b1f0acbedcf11964a204a24c45b62cff
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/81780
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi
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>
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>
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>
