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 patch also includes small changes to README file that were
agreed earlier:
changing all links to https
re-ordering of sections as Build instructions, Installations,
Packaging, Contact
Change-Id: I6e0debc0e15a9c4866f6d16fb010cd3f13171ff3
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Currently, it's not possible to compile the upstream branch using the
`make' command without sphinx beeing installed.
Check if sphinx-build is installed and only then build or install the
man-page.
The problem was noticed from commit
f4f2f3dd19784efa26fd5619b7a44b4cdf14b04c move manpage to sphinx.
Change-Id: If1b81d9bc25ecac19d493b44b00a7c42d0643fe6
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74519
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Hook logging callback so unit-tests print what they are doing.
This make debug far easier for a failing test.
BUG=none
TEST=ninja test.
Change-Id: I7ab0ff0915a76eea9857fc876493615c06193a37
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74932
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Flashrom only tries to use WP-based unlocking if it detects that WP
operations are supported. However WP support was detected in a way that
ignored WP operations provided by opaque masters.
This stopped flashrom from automatically unlocking with some opaque
masters, particularly linux_mtd.
This commit also deletes part of a test that required the chip unlock
function to be called before read/write/erase operations because WP
unlocking is now used instead of chip unlocking.
BUG=b:280111380
BRANCH=none
TEST=Checked flashrom automatically unlocked flash on strongbad (MTD)
Change-Id: I1774ad64d82ae47cd085df6045e17e283855c01f
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74930
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
There's basically no benefit to running `make` over directly running the
script that configures hooks, and implementing similar support in Meson
is difficult. Remove the Makefile target to achieve feature parity
between the build systems.
Ticket: https://ticket.coreboot.org/issues/486
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I278408bd515c5a5599b5c45c597cc66485a87082
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74924
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
To create a distribution package with meson you run
`meson dist -C <your_build_dir>`
This will collect all git tracked files and pack them into an archive.
There is no way to collect version information for that.
So now the base version stands in the VERSION file. To relase a flashrom
version you change that file and tag the changing commit.
When building from git the git version is embedded in the flashrom
binary. E.g.:
flashrom 1.4.0-devel (git:v1.2-1172-g7f186838) on Linux 6.1.3 (x86_64)
Change-Id: Idc17eadb397b3c579bddfbf9ae6bf1b171f5dfb7
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72657
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On failure of erasefn in erase_write it didn't set the error value in
ret which caused send success status as return value.
Change-Id: Ia3bd5fd250dcd0a03f0281c478b9bacb71872f31
Signed-off-by: Aarya Chaumal <aarya.chaumal@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74882
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This is just a copy of https://www.flashrom.org/Contact.
Change-Id: Ibfba6a59c5a945b4238d16e07a07584f94159568
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73822
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
These build instructions are mostly based on `Documentation/building.md`
and the wiki.
There are some `.. todo::` sections still present in the
documentation. They will be completed later. For some of the todos
content needs to be written, some others require custom sphinx-plugins
to be implemented.
The `.. todo::` sections are only visible in the source, not in the
rendered html.
Change-Id: I96771e98b313a6d26dd2be940ff37998d4124324
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73359
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
With `meson setup --cross-file meson_cross/i586_djgpp_dos.txt builddir`
you can build flashrom as DOS executable.
Change-Id: Iabda73942c1e64cd46604c78533982374f78e1a4
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73439
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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 main purpose of this patch is to run unit tests on BSD family
of OSes. The root cause is `fileno` syscall which is a macro that
can be expanded to either a function call (for multi-threaded
environment) or to inline code (for single-threaded environment).
Said inline code accesses private field of file descriptor, and
this construction is impossible to mock in unit tests. Multi-
threaded environment has `fileno` as a function, which can be
mocked in unit tests.
On other OSes the patch just creates a thread which is doing nothing.
We avoid adding pre-processor conditionals since the cost is small.
Tested on
FreeBSD 13.1-RELEASE-p6 GENERIC amd64
NetBSD 9.2 (GENERIC) amd64
OpenBSD 7.2 GENERIC#7 amd64
DragonFly v6.4.0-RELEASE x86_64
Ubuntu 22.04.1 x86_64
Change-Id: I3d65c125183e60037ad07b9d54b8fffdece5a4e8
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74157
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
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>
Patch fixes the error:
error: second argument to 'va_arg' is of promotable type 'mode_t'
(aka 'unsigned short'); this va_arg has undefined behavior because
arguments will be promoted to 'int' [-Werror,-Wvarargs]
Discovered and tested on:
FreeBSD clang version 13.0.0
gcc 8.3.0 "cc 8.3 [DragonFly] Release/2019-02-22"
Also tested on:
gcc 11.3.0 "cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0"
Change-Id: I95b7c8dafdf4e7664c48a952acd7f8eaedb59ba7
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74202
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
The libusb_detach_kernel_driver() call may return
LIBUSB_ERROR_NOT_FOUND, which should not be treated as an error.
Wrapping the call in LIBUSB() caused the error code to be transformed by
LIBUSB_ERROR(), so LIBUSB_ERROR_NOT_FOUND was not recognized at the call
site and was treated as a real error.
BUG=b:278635575
TEST=flashrom -p raiden_debug_spi:target=AP
BRANCH=none
Change-Id: I38e4642bcbddaf3f37821093f6b919806134ed7b
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74537
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Use library() instead of both_libraries() to build libflashrom. The
built-in option `default-library` can be used to decide which kind of
libraries should be built. Make `both` the default and throw an error in
the case someone tries to build the classic_cli with a shared library.
Change-Id: I27f10fdf1227795a9a3b4e050a2d708b58f10ee7
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73101
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Ensure construction and extraction filenames are symmetrical
consistently within the layout structure.
Change-Id: I9a0c3130c0e7d88a8a69fd29362c338e20d2bae8
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72943
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
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>
Since the handle is no longer a global variable and only exists
during the lifetime of the driver, we can stop checking if the
handle equals NULL.
Change-Id: I1872495b83a522ceced331fef35d9d9d3b43fce5
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72808
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Move global singleton states into a struct and store within
the spi_master data field for the life-time of the driver.
This patchset also includes stdlib.h to be able to work with
memory allocation. Pass programmer's data as a parameter to
functions that need it.
This is one of the steps on the way to move spi_master data
memory management behind the initialisation API, for more
context see other patches under the same topic specified below.
TOPIC=register_master_api
TEST=Tested on flash W25Q128JVSQ
flashrom -E # Result: success
flashrom -v ff.bin # Result: verified
flashrom -w firmware.bin # Result: success
flashrom -v firmware.bin # Result: verified
Change-Id: I9fe72bff88b7f8778c1199bdab8ba43bf32e1c8c
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Ticket: https://ticket.coreboot.org/issues/391
Reviewed-on: https://review.coreboot.org/c/flashrom/+/72807
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>
Use `libusb_detach_kernel_driver` and `libusb_attach_kernel_driver`
instead of `libusb_auto_detach_kernel_driver` to be compatible with
older libusb versions without changing the behavior.
TEST=Build with libusb >= 1.0.9
Change-Id: I1363fea13368b7ac1e9a3829864d06d123c4e157
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67073
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
I haven't worked on flashrom in the last months and I'm also not
planning to continue working on it again. So I'm removing myself from
the maintainers file since I'm not maintaining anymore.
Items, which become unmaintained, are removed.
Change-Id: I33903c4e38a24e6bf3cb233d28b297d1fa3716a9
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/74274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Due to how internal is structured around chipset_flash_enable()
entry we need to prepare a crafted programmer_cfg that contains
a board_enable substructure with data derived from the board_enable
subsystem. While this is certainly not perfection, it does make
clear the relationships between board_enable into chipset_flash_enable
and subsequently the overall internal programmer initialisation
in a RAII fashion at the type level over closure upon global
state that is impossible to reason about.
Also flip predicate in report_nonwl_laptop_detected() and
return early with the trivial base-case.
TEST=`$ sudo ./flashrom -p internal --flash-name`.
Change-Id: I459215253845c2af73262943ce91a36464e9eb06
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73456
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Some boards need to configure the programmer in specific ways.
For example, a programmer such as internal may need to be configured
either as laptop or not type and as such the board enable needs the
ability to feed state back into the programmer configuration. Plumb
this though by creating a board_cfg structure that can be packed.
Change-Id: I7058a693e714a6966a842ae97cc8da7296e63e5e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71623
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use a consistent style, as is the case in the Linux kernel, of
the canonical form of nullarity checking. Thus, making the
function have a overall consistent style.
Change-Id: Id28b8b70d9ecc9f69a1b61684500d9c6023ca045
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73454
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The board_enable_safetycheck() call already checks nullarity
of the function pointer.
Change-Id: I956961ee7204d3a6a9066ba5945f95af1411e700
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73453
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prefix the remaining global cases with `g_` to avoid shadowing
issues and for easy greping.
Change-Id: I3d5ad6c0623269492d775a99a947fd6fe26c5f91
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/71622
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Avoid global symbol shadowing in local functions.
Change-Id: Idfca0b7e46d8051bf680227250cf40483e19dc53
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73646
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
See https://www.mxic.com.tw/Lists/Datasheet/Attachments/8662/MX25V1635F,%202.5V,%2016Mb,%20v1.4.pdf .
I've tested this patch with the MX25V1635F I have here, using serprog
and ftdi by (re)writing a few images to the flash and seeing if changes
were stored correctly. This also included erasing and rewriting the
memory with completely different data, so erase is tested, too.
Change-Id: I58ddaaa96ef410d50dde3aaa20376c5bbf0f370b
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
See https://www.macronix.com/Lists/Datasheet/Attachments/8405/MX25V8035F,%202.5V,%208Mb,%20v1.0.pdf .
I've only tested this patch with the MX25V1635F I have here, though
other chips in the series exist as well. Tested using serprog and ftdi
by writing a few images to the flash and seeing if changes were stored
correctly.
Change-Id: Ic5be2da4cfa2a2ff044a519bb6f367f21c15e4b8
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73823
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
See https://www.macronix.com/Lists/Datasheet/Attachments/8670/MX25V4035F,%202.5V,%204Mb,%20v1.2.pdf .
I've only tested this patch with the MX25V1635F I have here, though
other chips in the series exist as well. Tested using serprog and ftdi
by writing a few images to the flash and seeing if changes were stored
correctly.
Change-Id: I8b26926c354b840ca7b14b4c5cb000e3c02f5137
Signed-off-by: PoroCYon <p@pcy.be>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73582
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Converting the printlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: I9131348f72c1010e2c213dca4dc4b675a8d8681e
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
As Edward pointed out correctly this function does more than abstracting
the different versions of `pci_get_dev()`. It also hide the usage of
the global `struct pci_access pacc` from the caller.
This reverts commit 0e8902f1ff2b927bb91a5e89e4fde3d8d71f6692.
Change-Id: I0cd2f54cb6a6e35dc353476e0f5e502cbbd06cba
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73730
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Converting the blockprotect unlock function pointer
within the flashchip struct into enum values allows for
the flashchips db to be turn into pure, declarative data.
A nice side-effect of this is to reduce link-time symbol
space of chipdrivers and increase modularity of the
spi25_statusreg.c and related implementations.
BUG=none
TEST=ninja test.
Change-Id: Ie5c5db1b09d07e1a549990d6f5a622fae4c83233
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69933
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
It's impossible for flashrom_layout to represent zero-sized flash
regions but it is possible for a fmap to contain a zero-sized region
which causes the resulting layout to fail layout_sanity_checks(),
preventing use of that fmap.
Because it would very rarely make sense to be able to operate on
zero-sized regions anyway and changing layouts to be able to support
zero-size regions would entail large changes, instead ignore zero-size
regions when present in fmap.
TEST=Warning is now printed when using fmap that contains a zero-sized
area, and operations on other regions are allowed to proceed.
BUG=b:271933192
Change-Id: Ie20971f779acece7a0b3b8f38796fff128ce689a
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/73571
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
