Follow up (or fix) on
commit 6571f263b52710579f27b3c53ade52d46acbc8e3
which adds ability to set maximum log level to log callback API.
And INFO as the default.
Without this patch cli options -V, -VV, -VVV not working anymore.
cli at the moment processes all the messages in the callback,
so log level should be maximum possible to get all the messages.
Alternative to this could be setting the default max log level
for callback as SPEW.
Tested by running with -V, -VV, -VVV
flashrom -p dummy:emulate=W25Q128FV,freq=64mhz -r dump.rom --progress
Change-Id: I70a02ea1a1d692267fd6d92cdb5273786a913777
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/87174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dmitry Zhadinets <dzhadinets@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial version of API for progress callback would require the
callback function to make a second call to get the needed data about
progress state (current, total etc).
This patch changes the callback API, so that callback function gets
all needed data straight away as parameters, and with this,
callback has all the data to do its job.
Since the initial version was submitted and it was in the tree for a
while, the change needs to add a _v2 suffix for new thing and
deprecated attribute for old thing.
Testing: both unit tests and cli are libflashrom clients.
All unit tests run successfully, for the cli all scenarios from
commit 75dc0655b95dde91f1426a7e5aecfc04d7b8d631 run successfully.
Change-Id: Ia8cc0461c449b7e65888a64cdc594c55b81eae7a
Signed-off-by: Anastasia Klimchuk <aklm@flashrom.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/86031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
This is a simple refactor that aims to simplify maintenance and to
clarify file dependency inside the project.
Currently, many declarations reside in flash.h making it difficult to
really understand file dependency.
Change-Id: I4209d5ed205ca14c39e83aa923e103b7282a7059
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85134
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Make the filename parameter directly following -r/-w/-v optional, since
the -i parameter allows the image to be written to be sourced from
multiple files, regions to be read from flash and written to separate
image files, and regions to be verified using an image file only
containing that region.
Since the filename parameter following -w/-v was ignored when a
filename was specified following `-i <region>:<filename>`, this patch
essentially removes the requirement to provide an unused parameter.
Based on https://review.coreboot.org/c/flashrom/+/52362.
TEST=run the following commands on a supported board:
flashrom -p internal -r /tmp/coreboot.rom
flashrom -p internal -r --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -r /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
flashrom -p internal -w /tmp/coreboot.rom
flashrom -p internal -w --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -w /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
flashrom -p internal -v /tmp/coreboot.rom
flashrom -p internal -v --ifd -i bios:/tmp/coreboot.rom
flashrom -p internal -v /tmp/coreboot.rom --ifd -i bios:/tmp/bios.bin
Change-Id: I6eba095d478f1a7bdbc3854627a656f93dd9e452
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85159
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The header only defines getop related stuff so it seems more intuitive
this way.
Change-Id: Iaceeabedc26e93147d8122376d88e730aad1e355
Signed-off-by: Antonio Vázquez Blanco <antoniovazquezblanco@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/85072
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 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>
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>
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>
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>
DJGPP for compiling DOS has other sizes for the normal int types and
therefore throwing errors when using %i %d or %x with uint32_t.
Fix these warnings by using the macros created for it and provided in
inttypes.h.
Change-Id: Ia75b6df981ce60c891161fe553c7ceab8570178d
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73040
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
The previous implementation had no error handling, as a result the
flashrom could crash if the computer ran out of memory. The new
version returns NULL in such cases.
Also, rewrite lots of `if` conditions to one cycle, store a name of
buses and `enum chipbustype` in an array by using a custom struct.
The caller always expected a non-null value, so change its behavior to
handle a possible null value or use the `?` symbol. As far as `free()`
can handle null pointers, do nothing with such callers.
TEST=ninja test
Change-Id: I59b9044c99b4ba6c00d8c97f1e91af09d70dce2c
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/408
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Move variables that represent parsed options to `cli_options`
structure. This patchset also introduces the following functions:
- parse_options() which parses command line arguments and fills
the structure.
- free_options() that releases an allocated data from the
structure.
This is one of the steps on the way to simplify the main function
by using helper functions with descriptive names.
TOPIC=split_main_func
TEST=the following scenarious run successfully
./flashrom -p dummy:emulate=S25FL128L -V
./flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE \
-r /tmp/dump.rom
./flashrom -p dummy:emulate=W25Q128FV -l /tmp/rom.layout \
-i boot -w /tmp/rom.tr.img
./flashrom -p dummy:emulate=W25Q128FV --wp-list
./flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-enable \
--wp-range=0x00c00000,0x00400000 \
--wp-status
$ head -c 16MiB </dev/urandom >/tmp/image.rom
./flashrom -p dummy:image=/tmp/image.rom,emulate=S25FL128L \
-c S25FL128L -E -V
Change-Id: Id573bc74e3bb46b7dc42f1452fff6394d4f091bc
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66343
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This cast should not be required.
Change-Id: Ia3a658dd6f4986eb6da84a11bce66f53e1571469
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72966
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
The romentry structure is the container ADT with some
annotated meta-data such as 'included' or 'file' however
the substantive substructure is a 'flash_region'. Therefore
factor this out.
That is to say, the link list node 'romentry' is obscured by the implementation details of its use-case of 'flash_region' that we
clear up here.
BUG=b:260440773
BRANCH=none
TEST=flashrom_tester
Change-Id: I768742b73db901df5b5208fcbcb8a324a06014c2
CoAuthored-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69196
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
--include argument was introduced and replaced --image argument in
commit 45d50a101e8073191e6d88143990ed91d3bfe815
This patch cleans up remaining few places where old `--image`
argument was mentioned so that now all the documentation has
`--include`. --image is deprecated.
Both old --image and new --include have the same short version -i
and it remains the same. The code remains the same since the code
handles --include already.
Tested by running
flashrom -h
man ./flashrom.8.tmpl
Ticket: https://ticket.coreboot.org/issues/372
Change-Id: If457e2b8548034868105b515125d7e8b4d5f6134
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70003
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Pass by argument the max_rom_decode structure such that the
function is pure and defined upon its parameters.
Note, unfortunately a itermediate step of a '_' suffix is
required for the 'max_rom_decode' parameter as to not alias
the global symbol within the function body.
Change-Id: Ia01f77993deab68e251850008e885828e55b9462
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68479
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With `i586-pc-msdosdjgpp-gcc (GCC) 12.2.0`, `uint32_t` is defined as
`long unsigned int`, which is not the same as `unsigned int`. As the
`flashrom_layout_get_region_range()` function is part of libflashrom
API, adjust `cli_classic.c` instead to avoid type mismatches.
Change-Id: Ie8f5bc0d9296f7c6b8f8a351b53052f5fe86b09d
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69451
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Perform the check right in read_wp_bits() as it's used by various WP
operations and also because its results won't make sense if WPS bit is
on and can't be changed.
Change-Id: I143186066a1d3af89809b7135886cb8b0d038085
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66836
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Apart from the very bespoke case of 'probe_w29ee011()'
the override 'chip_to_probe' name is a nature parameter
to 'probe_flash()'. However we can deal with w29ee011
by providing a probe specific validation function to
check if the chip can indeed be overriden.
TEST=`./flashrom -p internal --flash-name`.
Change-Id: Ifcdace07ea2135d83dea92cfa5c6bec8d7ddf05d
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
The count_max_decode_exceeding() function is only ever called
within the cli_classic logic so move it there and make it
static. This further cleans up the flashrom.c symbol namespace.
Change-Id: If050eab7db8560676c03d5005a2b391313a0d642
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68438
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Modify the `programmer_delay` function signature to allow passing
the flashrom context. Programmers that depend on internal delay
should provide NULL as a context. The use of this function parameter
will be introduced in CB:67393.
TOPIC=programmer_handle_global
TEST=builds
Change-Id: Ibb0bce26ce2052853ee52158d7ba742967a9e229
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66373
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Print errors if --wp-region is used without a layout file or the layout
file doesn't contain the region.
BUG=b:247055486
TEST=builds
Change-Id: Ie606ba7f8a423405099679ca62169c395d994b5d
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67725
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The write_buf_to_include_args() helper is only ever used
by the cli frontend therefore make it static local to the
user.
BUG=b:242246291
TEST=builds
Change-Id: Ia16bf4b8e46a011aa45f98089d43904b077833a0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66648
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The read_buf_from_include_args() helper is only ever used
by the cli frontend therefore make it static local to the
user.
BUG=b:242246291
TEST=builds
Change-Id: I9dee63d67320085e16c64eefb2723169f49f07aa
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
write_buf_to_include_args() does not need the whole flashctx,
rather it works with a fix layout and buffer. Just pass what
state is actually required.
BUG=b:242246291
TEST=builds
Change-Id: I885c4395356eef27746c66300233f07f4718ccdf
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66644
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
read_buf_from_include_args() does not need the whole flashctx,
rather it works with a fix layout and buffer. Just pass what
state is actually required.
BUG=b:242246291
TEST=builds
Change-Id: Ieadd68895c7ba05cc3d770d304351b02622f14d7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66633
Reviewed-by: Evan Benn <evanbenn@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Use the bool type instead of integer in the main function where
possible, since this represents the purpose of some variables much
better. Also, then we don't have to use the "!!" operator to turn any
number into one or zero, which is used as an equivalent to true and
false.
Also, since we have booleans and integers now, slightly change the
ordering of the variable declarations, so that the integers come before
the booleans.
Tested some parameters using the following commands:
flashrom -L
flashrom -p dummy
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -v foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -w foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -r foo1
flashrom -p dummy:emulate=SST25VF040.REMS,image=foo2 -c "SST25LF040A" --progress -E
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I06572da040e12ac88f8e5fc39f60a9e212b86bd7
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64564
Reviewed-by: Evan Benn <evanbenn@google.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Projects using libflashrom like fwupd expect the user to wait for the
operation to complete. To avoid the user thinking the process has
"hung" or "got stuck" report back the progress complete of the erase,
write and read operations.
Add a new --progress flag to the CLI to report progress of operations.
Include a test for the dummy spi25 device.
TEST=./test_build.sh; ./flashrom -p lspcon_i2c_spi:bus=7 -r /dev/null --progress
Change-Id: I7197572bb7f19e3bdb2bde855d70a0f50fd3854c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
If parameter --wp-region is used and wp_region is allocated,
free the last one at the exit of the application.
Found-by: scan-build, clang v13.0.1
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I8520e302e9d63ed1215c5d9beb90a93fb52a91fe
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
STANDALONE mode was used to build flashrom without having support for
file handling. This was relevant to build libflashrom on top of
libpayload. For a while now, the code which is covered by STANDALONE has
moved to cli_*.c and is not used for libflashrom. Therefore we can drop
STANDALONE mode.
Change-Id: I58fb82270a9884a323d9850176708d230fdc5165
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63469
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This change adds follow up changes to the man page:
- Explain (-) argument for -w/-v operations
- Expand on region name handling of -x operation
Also updates cli_classic.c to match with --help output.
BUG=b:224364316
Change-Id: I0cba593da3926c8587027789f4e1e89a2329ca7f
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Delete writeprotect code that was previously extracted from the cros tree.
This is the first of a series of commits adding writeprotect support.
Following commits incrementally implement writeprotect operations,
culminating in writeprotect support for three example chips: GD25LQ128,
GD25Q32, and GD25Q256.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom -{r,w,E}
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I67e9b31f86465e5a8f7d3def637198671ee818a8
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
flashrom_programmer_shutdown(NULL) is an equiv call
to programmer_shutdown() however this further decouples
cli from flashrom core logic at link-time, prefering to
instead enter via libflashrom instead.
BUG=none
TEST=`make`.
Change-Id: Ie194fa2e891797a29d05d7e9d0c7226fd62c0679
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61584
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
These helpers are only used by the CLI logic and so we localise
them here to move towards cli_classic being a pure libflashrom
user.
BUG=b:208132085
TEST=`make`
Change-Id: If1112155e2421e0178fd73f847cbb80868387433
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60070
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Inline emergency_help_message() to cli_classic call site.
This leaves do_erase() a redudant wrapper and moves us a step
closer to cli_classic as a pure libflashrom user by using
flashrom_flash_erase().
BUG=b:208132085
TEST=`flashrom -E`
Change-Id: I8566164e7dbad69cf478b24208014f10fb99e4d0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
While using the libflashrom API to read specific regions
there is no currently no general way to find the offset
into the read buffer of the expected region.
flashrom_layout_include_region() probably should have
returned the region offset and size if it was included.
However to avoid a change in API signature we can instead
hoist up get_region_range() into the API to be called after.
BUG=b:207808292
TEST=`make` && tested in porting cbfstool use-case.
Change-Id: I8cf95b5eaec943a51d0ea668f26a56bf6d6b4446
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/60881
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
It initializes an empty layout. Currently the maximum number of entries
has to be specified, which will vanish once we use dynamic allocation
per entry.
We replace the two special cases `single_layout` and `ich_layout` with
dynamically allocated layouts. As a result, we have to take care to
release the `default_layout` in a flashctx once we are done with it.
Change-Id: I2ae7246493ff592e631cce924777925c7825e398
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33543
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
CONFIG_DEFAULT_PROGRAMER_NAME replaces CONFIG_DEFAULT_PROGRAMMER.
It uses the name of the programmer for identification.
make CONFIG_DEFAULT_PROGRAMER_NAME=dummy and
meson -Ddefault_programmer_name=dummy will extend to
CONFIG_DEFAULT_PROGRAMER_NAME=&programmer_dummy in the code.
Change-Id: I976447787c6f6bfbdc0145d80d61e1ddcf97ac33
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55123
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
