As noted in a comment on
`commit 86fc9cf7ab221bc54ef6f10252e296fc2d7a22d2`, the GD25Q256D
datasheet indicates that the chip does not require a WREN command to
enter 4BA mode.
Testing has confirmed that a WREN command is not required, so change the
flashchip feature flags from FEATURE_4BA_WREN to FEATURE_4BA.
Ticket: https://ticket.coreboot.org/issues/356
BUG=none
BRANCH=none
TEST=read/write/erase/verify GD25Q256D flash with FT2232H programmer
TEST=called spi_enter_exit_4ba(true), dumped registers, checked ADS=1.
Original-Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70342
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
(cherry picked from commit 7f3c3f5c4807f4f3c0c2de405189e86b3f8d77a3)
Change-Id: I96e48933f33c52c0d10a0d4cb7f7e07c1fceab99
Signed-off-by: Evan Benn <evanbenn@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70323
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
strdup return values should be checked for NULL to catch the
potential error case of out of memory.
This patch re-writes ternary conditionals so that strdup return
values could be checked for all branches fof execution.
Follow up on
commit 45d50a101e8073191e6d88143990ed91d3bfe815
Ticket: https://ticket.coreboot.org/issues/372
Original-Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70006
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
(cherry picked from commit 59ce5615b768fe9d4d2506cb13c6781cd83a12e6)
Change-Id: I6c22196be6847a8c9704f1de936604a51b4b8a28
Signed-off-by: Evan Benn <evanbenn@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70322
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
--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
Original-Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70003
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-by: Felix Singer <felixsinger@posteo.net>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
(cherry picked from commit 8274c6321ae2ff29bc9eb0de9dc32d289d3c2cc5)
Change-Id: If457e2b8548034868105b515125d7e8b4d5f6134
Signed-off-by: Evan Benn <evanbenn@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The patch adds one paragraph of information about meson into the
README file. This meant to be the minimum required to unblock
release candidate. README file will have a more substantial
upgrade soon.
Ticket: https://ticket.coreboot.org/issues/354
Original-Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70176
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
(cherry picked from commit 80408ceafc2a9a550bb5ef7aabd772dbf5d34487)
Change-Id: I2a27d8f2ba42e18be2485ae95bec1b4c874bb4f7
Signed-off-by: Evan Benn <evanbenn@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70321
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Craask and similar DUT's are erroneously probing random second chips.
```
Found chipset "Intel Alder Lake-N".
Enabling flash write... SPI Configuration is locked down.
FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
FREG1: BIOS region (0x003a0000-0x00ffffff) is read-write.
FREG2: Management Engine region (0x00001000-0x0039ffff) is read-write.
OK.
Found Winbond flash chip "W25Q128.V..M" (16384 kB, Programmer-specific) on host.
Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
Found MoselVitelic flash chip "V29C51000T" (64 kB, Parallel) mapped at physical address 0x00000000ffff0000.
```
This seems to be due to `laptop_ok` becoming a stale global state
after the first operation leading to probing on unrelated buses.
Therefore unconditionally reset the global state upon entry into
the internal driver.
BUG=b:260518132,b:260151917
TEST=Craask reportly no longer finds duplicate chip.
Original-Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70026
Original-Reviewed-by: Sam McNally <sammc@google.com>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
(cherry picked from commit c2af789c5ea5821f61fac5532d81e94742e0e00b)
Change-Id: I2c00c351904307eeb1488c5dfaffc91d6468ee25
Signed-off-by: Evan Benn <evanbenn@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70327
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
For compliance and to check if the commit message matches the
development guidelines, add a linter checking for the sign-off-by line
in the commit message. Also, hook it up to the test_build.sh script
which is used for CI builds.
These scripts were copied from the coreboot repository and were adjusted
so that they work for flashrom.
Original-Signed-off-by: Felix Singer <felixsinger@posteo.net>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/70079
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Change-Id: I03f1827803f8492d60a0a44174d5822c2265bfcb
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70243
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Flash chips XM25QH256C and XM25QU256C support the 4-byte program
command (0x12) according to their datasheets, but the feature flag is
not enabled in flashchips.c, so enable it to allow this feature to be
used.
TICKET: https://ticket.coreboot.org/issues/371
BUG=b:259493706
TEST=build
Original-Signed-off-by: Liam Flaherty <liamflaherty@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69713
Original-Reviewed-by: Felix Singer <felixsinger@posteo.net>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Change-Id: I96c80762fcda2af6028c7a53d8c545b0c6565cbd
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70204
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch fixes a potential issue where the SPI controller register
HSFC.FDBC (bits 24-29) value gets incorrectly calculated while passing
the `len` as `0` instead of `1`.
As per Intel EDS, `0b` in the FDBC represents 1 byte while `0x3f`
represents 64-bytes to be transferred. The number of bytes
transferred is the value of this field plus 1.
If we would like to transfer 1 byte then we need to set `0b` in
FDBC for operations like read, write, flash id as to account for
the `set byte count` hence, the `len` argument should be `1`.
Additionally, as per EDS, the FDBC field is ignored for any block
erase command.
BUG=b:258280679
TEST=Able to build flashrom and perform below operations on Google,
Rex and Google, Kano/Taeko.
During `--wp-disable` HW seq operation that requires 1 byte data
transfer.
HSFC.FDBC value while passing `len` as `0` = 0x3f (represents 64-byte)
HSFC.FDBC value while passing `len` as `1` = 0x0 (represents 1-byte)
Original-Signed-off-by: Subrata Banik <subratabanik@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69789
Original-Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: I5b911655649c693e576497520687d7810bbd3c54
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70039
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch fixes a regression introduced with
commit 7ed1337309d3fe74f5af09520970f0f1d417399a (ichspi: Factor out
common hwseq_xfer logic into helpers).
The reason for the regression is ignoring the fact that the Fast SPI
controller MMIO register HSFC (0x06) might not hold the default zero
value before initiating the HW sequencing operation.
Having a `1b` value in the HSFC.FDBC (bits 24-29) field would represent
a byte that needs to be transfered.
While debugging the regression, we have observed that the default value
in the FDBC (prior to initiate any operation) is 0x3f (instead of
zero) which represents 64-byte transfer.
localhost ~ # iotools mmio_read32 0x92d16006
0x3f00
<Fast SPI MMIO BAR: 0x92d16000 and HSFC offset: 0x06>
FDBC offset during `--wp-disable` operation represents higher numbers of
bytes than the actual and eventually results in the error.
Additionally, dropped unused variable (struct hwseq_data *hwseq_data).
BUG=b:258280679
TEST=Able to build flashrom and perform below operations on Google, Rex
and Google, Kano/Taeko.
Without this patch:
HSFC register value inside ich_start_hwseq_xfer() before initiating
the HW seq operations: 0x3f00
HSFC register value inside ich_start_hwseq_xfer() during the HW seq
operations (Read Status): 0x3f11
With this patch:
HSFC register value inside ich_start_hwseq_xfer() before initiating
the HW seq operations: 0x0
HSFC register value inside ich_start_hwseq_xfer() during the HW seq
operations (Read Status): 0x11
Additionally, verified other HW sequencing operations (like read, write,
erase, read status, write status, read ID) working fine without any
error.
Original-Signed-off-by: Subrata Banik <subratabanik@google.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69788
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: I4cc3f24f880d1d621f1f48a6e6b276449fa46f98
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69998
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Opaque masters, by design, populate the flashchip structure during
the execution of their probe function. Therefore any opaque master
operation displays a message to the user:
"This flash part has status UNTESTED for operations: WP".
However, for all the other operations (read, write, erase) opaque
masters always mark them as tested. Thus, align WP as marked tested
inline with other opaque chip operations.
BUG=b:258755442
TEST=the following does not display untested message:
1) flashrom -p dummy:size=8388608,emulate=VARIABLE_SIZE
2) flashrom -p internal (on Intel device)
Original-Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69842
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Original-Reviewed-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I5ae4cb49eb0abc6ab26cfe2f3359e4e50dd4fd4f
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69997
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Since linux_mtd supports write-protect, its probe function needs
to mark Opaque chip as tested for WP. Programmers which are
opaque masters are responsible for populating flashchip#tested
struct in probe function.
Without the patch, any operation running via linux_mtd displays
a message "This flash part has status UNTESTED for operations: WP".
With the patch, the message is not displayed anymore.
BUG=b:258755442
BRANCH=none
TEST=flashrom -p host on ARM dut
Found Programmer flash chip "Opaque flash chip"
(8192 kB, Programmer-specific) on host.
No operations were specified.
Original-Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69518
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Original-Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Original-Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Change-Id: Icc0521c28555a93f26ce66bdbeaa68590f10c358
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69996
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.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.
Original-Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/c/flashrom/+/69451
Original-Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Original-Reviewed-by: Evan Benn <evanbenn@google.com>
Original-Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Original-Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Change-Id: Ie8f5bc0d9296f7c6b8f8a351b53052f5fe86b09d
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69995
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This reverts commit 40892b0c08fbc8029921e91511dd3f91fc956f90.
The feature of returning progress for libflashrom users was
introduced in original commit, however later a bug was found and
reported as https://ticket.coreboot.org/issues/390.
Reverting in a release branch to unblock release candidate, since
it is unknown how much time needed to fix the bug. Meanwhile the
feature remains in a master branch and will be fixed under
ticket 390.
TEST=scenarios below run successfully
1) flashrom -h does not show --progress
2) flashrom -p dummy:emulate=W25Q128FV -r /tmp/dump.bin
3) flashrom -p dummy:emulate=W25Q128FV -v /tmp/dump.bin
4) flashrom -p dummy:emulate=W25Q128FV -E
5) head -c 16777216 </dev/urandom >/tmp/image.bin
flashrom -p dummy:image=/tmp/image.bin,emulate=W25Q128FV \
-w /tmp/dump.bin
Change-Id: Id3d7ffcaf266a60a44eb453fd09b7c63c05349c2
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The "Promontory" code is riddled with issues, some of them can result in
soft bricks. Moreover, Promontory doesn't have a SPI controller.
Drop support for "Promontory" in flashrom for now: it's holding back the
entire project and it's unlikely that it'll be fixed in a timely manner.
Change-Id: I1457946dce68321b496d9ffa40a0c5ab46455f72
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68824
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Swift Geek (Sebastian Grzywna) <swiftgeek@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Align hwseq path in ichspi with the rest of the flashrom tree
by making hwseq_data a heap allocation within the life-time of
the driver managed by the driver registration API.
Change-Id: Ib362c5ab2d3e8afee2c3c7d3135cc4414d6bd6c3
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68774
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Allow helpers to derive driver specific data from the driver
specific context instead of being a closure over a static
global variable.
Change-Id: Ib0ccf4b32fd1e2be2ecc3a4a4c6e397c8e901a0a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68773
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Change is a NOP to prepare ichspi to remove hwseq_data being
a global symbol in CB:68774. This allows for the helper
functions to derive their data from the driver data context.
Change-Id: I67b5aa6350930d912e5036473ac3e792debac0bd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Rename the list of source files to `test_srcs` so that there is less
confusion with the variable `srcs` from the top-level meson.build file
containing the flashrom source files.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: Ica0fc3923070bff63323204bd58edb5276dc9493
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68228
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I612d46fefedf2b69e7e2064aa857fa0756efb4e7
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66788
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I80149de169464b204fb09f1424a86fc645b740fd
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66782
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
This forges the way for flashchips.c to be pure declarative
data and lookup functions for dispatch to be pure. This
means that the flashchips data could be extracted out to
be agnostic data of the flashrom code and algorithms.
TEST='R|W|E && --flash-name' on ARM, AMD & Intel DUT's.
Change-Id: I00aaab9c83f305cd47e78c36d9c2867f2b73c396
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66781
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested reading, writing and erasing the flash chip of a Prodrive
Hermes mainboard with an Intel C246 PCH. However, since ME-enabled
chipsets are marked as DEP instead of OK, this one shall also be.
Change-Id: I07d6c4a60e468c61eba836db91e1335f4a762048
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68594
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
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>
Replace the `decode_range` function pointer in `struct flashchip` to an
enum value. The enum value can be used to find the corresponding
function pointer by passing it to `lookup_decode_range_func_ptr()`.
Removing function pointers like `decode_range` makes it possible to represent chip data in a declarative format that does not have to be
stored as C source code.
BUG=b:242479049
BRANCH=none
TEST=ninja && ninja test
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Change-Id: If6d08d414d3d1ddadc95ca1d407fc87c23ab543d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67195
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Make the `get_params()` function provide a pointer to `struct
rayer_programmer` directly, instead of having a `prog_type` string
passed around three functions.
Change-Id: I83e34382ee9814f224025e21e5099fdab73cee8c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68239
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Roll up the programmer type table search and match logic into
it's own function and lexically scope the 'rayer_spi_types'
table into the function while we are here.
Change-Id: Id226ea61132ecc30fd8696e1d8ea50373e752cac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68238
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The intermediate variable in this case serves no extra
assistance in readability or additional control flow
branching. Just assign the result directly into the
driver state tracker.
Change-Id: Idedabb7b1c401d666b3b7e621e75704c7e765fd1
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68232
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Deconvolve programmer parameter parse logic out of main
'rayer_spi_init()' entry-point function control flow.
Change-Id: I287aa2e5d94e872553d08c0750f8dc6d60b9caff
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68230
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The raiden_debug_spi programmer will query the connected USB devices and
match against criteria other than the pid rather than iterate through
the vid:pid table.
The fixme has been updated to explain why the dev_entry table is empty.
TICKET: https://ticket.coreboot.org/issues/394
BUG=b:253320285
TEST=build
Change-Id: I43e364c02f42dd499d3c9ca3e0a03ead673da3e6
Signed-off-by: Liam Flaherty <liamflaherty@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68364
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.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>
The 'programmer' intended to be used in the control flow
of 'programmer_init()' is a parameter to the function. Therefore
use that symbol directly over the global copy of it.
Change-Id: I71e61f0633bac2fc472971249910bf3bf57cd0eb
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68249
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new programmer driver for the DirtyJTAG project (a USB-JTAG
firmware for STM32 MCUs).
Successfully tested with DirtyJTAG 1.4 running on an Olimex STM32-H103
development board and a SST25VF020B SPI flash chip.
Change-Id: Ic43e9a014ed7d04e429e73b30c9dcfdde1a78913
Signed-off-by: Jean THOMAS <virgule@jeanthomas.me>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67878
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
get_default_layout() is undefined without a
init_default_layout() so separate out that logic
from probe_flash().
Change-Id: I8fd0af8fb1c32dc9f2b00cc39b518d2f4d98e3ac
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68296
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
No need to malloc() and then do a DIY memset to zero of the
heap. Just use calloc(1, ..) to get a zeroed heap.
Change-Id: Id6cf2c4591aec0620f15d8a39495d2bff6597f96
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
When a file object is created, Meson also checks if the file actually
exists and an error points to the specific line of meson.build if not.
If just a list of filenames is used, then the error occurs at the line
where the list is used.
Thus, use file objects in tests/meson.build for more useful error
messages.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I0b9144a6b76c1772833817b4e6873818dcf36b05
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68197
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
This adds a manpage section describing the mediatek_i2c_spi programmer,
including some discussion of devices that are supported as well as which
systems use them.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: Ia63df470170fbadcabadcdad8e5acc0cde3a274b
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
As suggested by Angel Pons, add the function `is_internal_programmer`
to cut down on some pre-processor usage by moving it into the new
function.
The function then checks if the internal programmer is the
selected one. If the internal programmer is not built in, then it
just returns false.
Change-Id: I43243b990192077583a9a3a95d35844923d9c158
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66684
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
dev_id, a uint8_t, was shifted left by 24 bits. After promotion to int,
this results in shifting into the sign bit, which is undefined
behaviour. Cast to uint32_t to prevent the promotion to signed int.
BUG=None
BRANCH=None
TEST=None
Change-Id: I88188ef2ba2af919eeae9ba08916374d31d8b989
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68127
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
No opaque masters have a custom mapper. The returned chipaddr is not
fed back into the read/write/erase functions, so this would only be
useful for side effects.
Change-Id: I36f05154edda371b51f8ff416f019837ff1c243d
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68092
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
