Used to control skipping of write-protected part of a chip.
Change-Id: Icdc56cb1876aab8f8229cd1a485aa297d8b7b1e9
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Allow specialisation in opaque masters, such as ichspi hwseq, to
write to status registers.
Also update the dispatch logic in libflashrom to call wp code when
status register access functions are provided by an opaque master.
BUG=none
BRANCH=none
TEST=flashrom --wp-status on AMD and Intel DUTs
Change-Id: I3ab0d7f5f48338c8ecb118a69651c203fbc516ac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Co-Authored-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/64375
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
The doxygen documentation was in the libflashrom.c file. Move the
documentation to the libflashrom.h file. This allows foreign function
interface binding generators (eg rust bindgen) that operate on the .h
file to generate documentation for the target language. Some doxygen
errors were also corrected, mostly undocumented or wrongly labeled
parameters.
To test, I have diffed and inspected the doxygen documentation before
and after the change. All functions are documented the same, and the
structs and enums are now also included in the docs.
Change-Id: I856b74d5bfea13722539be15496755a95e701eea
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63903
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This commit adds a generic framework to allow opaque programmers to
implement writeprotect operations and uses the framework to support
writeprotect operations on linux MTD device files.
The generic framework comprises three new functions in
`struct opaque_master` that are called from libflashrom:
- wp_write_cfg()
- wp_read_cfg()
- wp_get_ranges()
For linux_mtd, only the read/write functions are implemented. Linux's
MTD interface doesn't provide a way to get available ranges, so calling
get_wp_ranges() on the linux_mtd master will return
FLASHROM_WP_ERR_RANGE_LIST_UNAVAILABLE.
BUG=b:182223106
BRANCH=none
TEST=WP ops on hana DUT (MT8173) with W25Q32DW flash
TEST=flashrom --wp-enable --wp-range <non-empty> succeeds
TEST=flashrom --wp-enable --wp-range <empty> fails as expected
TEST=flashrom --wp-disable --wp-range <empty> succeeds
TEST=flashrom --wp-disable --wp-range <non-empty> fails as expected
TEST=flashrom --wp-status succeeds
Change-Id: I5c86e28cdec44bec49ba1d36f8ab62241b9b01da
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61897
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
In function flash_layout_read_from_ifd variable chip_layout remains
uninitialized if prepare_flash_access returns false. This uninitialized
variable (which contains a garbage value) is passed to
flashrom_layout_release. Thus initialize it with NULL. For completeness,
also initialize dump_layout with NULL.
Change-Id: Iacbd7bf9cdf897cc2a732c1dc6568845a4ab804d
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62725
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Generate list of available ranges by enumerating all possible values
that range bits (BPx, TB, ...) can take and using the chip's range
decoding function to get the range that is selected by each one.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-list
Change-Id: Id51f038f03305c8536d80313e52f77d27835f34d
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58481
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
New functions are exposed through the libflashrom API for
reading/writing chip's WP settins: `flashrom_wp_{read,write}_cfg()`.
They read/write an opaque `struct flashrom_wp_cfg` instance, which
includes the flash protection range and status register protection mode.
This commit also adds `{read,write}_wp_bits()` helper functions that
read/write chip-specific WP configuration bits.
BUG=b:195381327,b:153800563
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} at end of patch series
Change-Id: I3ad25708c3321b8fb0216c3eaf6ffc07616537ad
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/58479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
free() allows NULL and it makes error paths easier to handle when one
just needs to write `free(x);` without needing to care if `x` was
allocated already. Let's follow this rule in flashrom_flash_release().
flashrom_layout_release() already checks for NULL.
Change-Id: Id119c2e4f3aa1b11313059f11aac73c3e583185c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62340
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
off_t is a special POSIX type that is used to represent file offsets in
certain APIs (e.g. lseek(), mmap()), and should not be reused to
represent anything else (such as flash offsets). In particular, the
width of the type may change based on the definition of the
_FILE_OFFSET_BITS macro. Using such a type at the libflashrom interface
is particularly dangerous, because if a program is built with a
different _FILE_OFFSET_BITS value than libflashrom, the resulting ABI
corruption will cause very very nasty and confusing bugs. This patch
replaces all instances of off_t that are not related to file offsets
with (s)size_t.
BUG=b:219811851
TEST=`elogtool list` on cherry.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I68a386973f79ea634f63dfcd7d95a63400e1fdee
Reviewed-on: https://review.coreboot.org/c/flashrom/+/61943
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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>
Also, a `layout.c` internal version mutable_layout_next() that
allows to modify layout entries and a shorthand to look up an
entry by name, _layout_entry_by_name().
Use the new functions where applicable and the code is not
dropped later in this train, and also to compare the layouts
in flashrom_layout_read_from_ifd() in depth.
Change-Id: I284958471c61344d29d92c95d88475065a9ca9aa
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33542
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
const char **flashrom_supported_programmers(void) returns an array of
strings without returning the array size or making a NULL
termination. This can lead to undefined behavior when iterating over the
array.
Change-Id: I0157926a654e337c14d840dd398e5576471c304f
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55350
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Spelling out the struct type name hurts readability and introduces
opportunities for bugs to happen when the pointer variable type is
changed but the corresponding sizeof is (are) not.
TEST=`make CONFIG_EVERYTHING=yes CONFIG_JLINK_SPI=no VERSION=none -j`
with and without this patch; the flashrom executable does not change.
Change-Id: Icc0b60ca6ef9f5ece6ed2a0e03600bb6ccd7dcc6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/55266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>