| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a check that redirects mock io functions to the real
implementations. Real I/O functions are needed for the coverage tool to
be able to create and write files.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0817fce6ea0f53a4c127794a0d8246504675f805
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69539
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
BRANCH=None
TEST=None
Change-Id: I4dff96c264b3ada354538b434b2808fb66c7ef59
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69538
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
open has a second form with a mode_t argument. When mocking without this
argument a caller trying to O_CREAT would have their mode_t argument
discarded and a random stack variable would be used instead.
BUG=b:187647884
BRANCH=None
TEST=meson test
Change-Id: I8c134e6d36a248d0f51985e389085a9e585fb83d
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69263
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
BRANCH=None
TEST=None
Change-Id: I8e0611c415c921f5b04b20270fb26e147fefd1b8
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69537
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Change-Id: I96e48933f33c52c0d10a0d4cb7f7e07c1fceab99
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The config data in the conf object is specific to the man file. Thus,
rename it accordingly and also move the declaration to the place where
it is used.
Change-Id: Icf24b9c47d4c7553f1ec045a9dfd3685b1376445
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
|
|
|
|
|
|
|
|
|
|
|
| |
Clang 15 complains about it. Remove it.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I340208f513bed57a9cc2bba880a2400352c5cc42
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70247
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The manpage suggests that ft2232_spi chips are only capable of up to
6 MHz SPI clock frequencies, whereas flashrom disables the divide-by-5
prescaler on the 'H' chips allowing up to 30 MHz frequencies. This
detail was already present in the comments of ft2232_spi.c.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Change-Id: Id7690e1d4e11a3d0495afbc650f3c67430946468
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70218
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Change-Id: I6e84997f910928d3973a4e5826a2d4196bdb2916
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70242
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Alexander Goncharov <chat@joursoir.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not just exit in the middle of the process, rather return
a value back up to the caller to allow proper resource cleanup's
to occur.
Change-Id: Ie4186a40071e9a7296d601582ff15ad7df09c70a
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69474
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
| |
Change-Id: Id84a9f15c33781efc494ed36a1c7cec82a0333d6
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69472
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make the spi25 register read/write functions return SPI_INVALID_OPCODE
if the programmer blocks the read/write opcode for the register.
Likewise, make ichspi read/write register functions return
SPI_INVALID_OPCODE for registers >SR1 as they cannot be accessd.
Make writeprotect ignore SPI_INVALID_OPCODE unless it is trying to
read/write SR1, which should always be supported.
BUG=b:253715389,b:253713774,b:240229722
BRANCH=none
TEST=flashrom --wp-{enable,disable,range,list,status} on dedede
Change-Id: I2145749dcc51f4556550650dab5aa1049f879c45
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add unit tests for programmer_table, flashchips, and board_matches
structs. The tests are derived from the selfcheck function, checking
that the required fields have been filled in.
BUG=b:140595239
BRANCH=None
TEST=meson test
Change-Id: I41cd014d9bf909296b6c28e3e00548e6883ff41a
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69620
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Probing an opcode generally shouldn't involve mutating the flashctx
state and currently no probe_opcode functions do that.
Make the flashctx arg const so that call sites don't need to have a
non-const pointer.
BUG=b:253715389,b:253713774
BRANCH=none
TEST=ninja test
Change-Id: I19e98be50d682de2d2715417f8b7b8c62b871617
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70030
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Change-Id: I03f1827803f8492d60a0a44174d5822c2265bfcb
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70079
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Change-Id: I2c00c351904307eeb1488c5dfaffc91d6468ee25
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/70026
Reviewed-by: Sam McNally <sammc@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@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
Change-Id: I96c80762fcda2af6028c7a53d8c545b0c6565cbd
Signed-off-by: Liam Flaherty <liamflaherty@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69713
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test upgrades mocks to simulate a read request. Read buffer
is populated with chip manufacture id and chip model id to emulate
successful probing.
TEST=ninja test
Change-Id: I0a2d5591d097435fc69719e1d9bd153433425821
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/68755
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TEST=the following scenarios run tests successfully
1) ch341a_spi is enabled
result: all tests run and pass, including ch341a
2) ch341a_spi is disabled
result: ch341a_spi test is skipped, the rest of tests run and pass
3) libusb isn't presented in the system
result: tests for usb programmers are skipped, the rest of tests run
normally
Change-Id: If28fbe09ad685082152aa3a7e8d5a150169aee9e
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67664
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds mocks for several libusb functions are introduced
in one of the previous commits.
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Change-Id: I5a316687ab39a112d968eeaedb71f7b4b659d8d5
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69873
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The patch adds wrappers for libusb functions that are used in the
ch341a programmer and have not yet been introduced.
Change-Id: Ic11efb9fd746cb91911dbe87e1c0028759f5bb0b
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69872
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=None
BRANCH=None
TEST=None
Change-Id: I6cca635212867dad5a8e391a46b1d943530c539a
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69621
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for new write protect error.
BUG=None
BRANCH=None
TEST=cargo test
Change-Id: I2adaad6552a601147e779c85a2a51d2e39b91c28
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extract the code that converts `struct wp_bits` into a collection of
register values and bit masks out of `write_wp_bits()` into a new
function.
This avoids monadic transformer stacks where unit-testing cannot
penetrate well to give suitable coverage, therefore keep the bit
logic in a separate pure function.
BUG=b:260019525,b:259013033
BRANCH=none
TEST=ninja test
TEST=flashrom --wp-{{dis,en}able,range,list,status} on dedede
Change-Id: I604478ecbb70392c5584bf5d87c76b6f20f882b1
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69846
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
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)
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I5b911655649c693e576497520687d7810bbd3c54
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69789
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I4cc3f24f880d1d621f1f48a6e6b276449fa46f98
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69788
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
Change-Id: I5ae4cb49eb0abc6ab26cfe2f3359e4e50dd4fd4f
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69842
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>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
partial_lock test was bypassing the WriteProtectState cache of the
software write protect by directly calling env.cmd.wp_range. It was also
unnesesarily disabling software WP. Fix those issues and more clearly
document what the test is doing and expecting.
BUG=b:244663741
BRANCH=None
TEST=flashrom_tester --libflashrom host
Change-Id: Ic3f89ff5d22e74e4e6c94e755b936e58cb27182d
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69418
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
wp_toggle and wp_range had some confusing behaviour where enabling wp
would set a range, but disabling wp would not unset the range
(explicitly). This was a way to workaround the MTD kernel driver
semantics. Now make things very explicit, enabling software write
protect will set the range to the whole chip. Disabling write protect
will set the range to 0,0. This makes all drivers behave the same as
MTD, and documents the exact behaviour explicitly.
BUG=b:244663741
BRANCH=None
TEST=flashrom_tester --libflashrom host # MTD and non-MTD
TEST=flashrom_tester --flashrom_binary # MTD and non-MTD
Change-Id: Ia01d612d988e6580a7c5f0fd448ccc319ce9b181
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
os-release does not quite have as much information so use lsb-release.
BUG=b:258289727
BRANCH=None
TEST=flashrom_tester --libflashrom host Lock
Change-Id: If3452ead9e02e0ddeaa0fdf4852d7c17a8ab7650
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69403
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check that the hardware and software WP state are as expected in the
setter methods.
BUG=b:244663741
BRANCH=None
TEST=flashrom_tester --libflashrom host
Change-Id: Ie7f90ab478dca6f92eaa0908443e3cb156ea0319
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69402
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the WriteProtectState 'stack' implementation and the push
function. This functionality allowed states to be stacked and then
automatically unrolled via RAII lifetimes. This was useful. However this
unrolling could make errors in a flashrom_tester run much harder to
understand, as the actual failure would be followed by multiple write
protect calls that could subsequently fail, potentially causing panicing
inside the panic handler and the process to be hard aborted and the
restore golden image function would not be run.
The new approach is to prefer code simplicity. Ideally this makes errors
easier to diagnose from logs. To that end the lifetime has been
simplified. The stack has been removed. The mutex has been removed.
This means tests may not be running in the same environment they were
previously. However if they continue to specify their requirements with
set_sw and set_hw there will be no difference and the errors will be
clear.
BUG=b:259494812
BRANCH=None
TEST=flashrom_tester --libflashrom host
Change-Id: I1c4251f69b42a327383b8a99fa933f411feb9568
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document clearly what the test is doing and expects. Do not use the
push() function as it confuses the logs in the case of error.
BUG=b:258357944
BRANCH=None
TEST=flashrom_tester --libflashrom host Lock
Change-Id: Ibad559a8ff9696fd91f45bca9d9ceb6e90c41393
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69400
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 065366d (flashrom_tester: Change timestamp to UTC microsecond)
changed the time format, breaking the unit test. This patch
fixes the unit test.
BUG=None
BRANCH=None
TEST=cargo test
Change-Id: Iba42a9026b41ddb61bb704aa1c26783cd251d787
Signed-off-by: Evan Benn <evanbenn@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69765
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hwaccess_physmap.c: make `void *sys_physmap(()` static
hwaccess_x86_io.c: Add missing include
Change-Id: I5062c5a62b90f7a189488f3f569dc357bd2cb85f
Signed-off-by: Thomas Heijligen <thomas.heijligen@secunet.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69831
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This paves the way to allow for the conversion of flashchip printlock
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: Icff868d9454e9b0a059a736457bb562430436033
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69844
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This paves the way to allow for the conversion of flashchip unlock
func ptr to enumerate values. This change should be a NOP.
TEST=`diff -u <(objdump -D flashchips.o_bk) <(objdump -D flashchips.o)`.
Change-Id: I3ed51142cd22becc8286959f5504565158fa2de0
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69843
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'chip_safety_check()' already validates the chip structure
within 'prepare_flash_access()' before all subsequent chip operations
such as 'verify_range()' and therefore the chip structure is
guaranteed to be valid in the domain of those operations.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ifc57dd89715115e03d013691352463a8b3c0dc52
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69471
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.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.
Change-Id: Icc0521c28555a93f26ce66bdbeaa68590f10c358
Signed-off-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/69518
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These weren't split:
* MX25L3206E/MX25L3208E
Tested: https://github.com/Dasharo/flashrom/pull/8
* MX25L6405
* MX25L6405D
* MX25L6406E/MX25L6408E
Tested: https://github.com/Dasharo/flashrom/pull/8
MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F was split into:
* MX25L6436E/MX25L6445E/MX25L6465E
- security register
- WPS
- tested: https://github.com/Dasharo/flashrom/pull/8
* MX25L6473E
- security register
- OTP TB bit in CONFIG/STATUS2 (0x15 opcode)
- WPS
* MX25L6473F
- NO security register
- OTP TB bit in CONFIG/STATUS2 (0x15 opcode)
- NO WPS
Change-Id: Ib3db9d39ffacd3e9e44de92c6cfb6c3ecc8615bd
Tested-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66216
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
| |
Change-Id: Ib0f3cb9516cea7bb678842a358a82099221e1ed9
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66215
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split chips:
* W25Q32.V -> W25Q32BV/W25Q32CV/W25Q32DV, W25Q32FV and W25Q32JV
* W25Q32.W -> W25Q32BW/W25Q32CW/W25Q32DW, W25Q32FW and W25Q32JW...Q
Change-Id: Id259c27dfa6c681bbadc73b3bd7559ad6a5865f4
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66214
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Split chips:
* EN25QH32 -> EN25QH32 and EN25QH32B
* EN25QH64 -> EN25QH64 and EN25QH64A
Unlike older revisions both newly added EN25QH32B and EN25QH64A support
half block (32KiB) erase operation via 0x52 opcode.
Change-Id: I759f0119346235ce0bddc78cde9c461495990c25
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66213
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not all chips follow the same pattern. There are differences in how CMP
bit is treated or in block size used.
Change-Id: Ied7b27be2ee2426af8f473432e2b01a290de2365
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66212
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One more variation of registers.
This one is read via a separate RDCR command, but written as if it's
SR2 using WRSR_EXT2.
Change-Id: I45f9afcc31f1928ef6263a749596380082963de4
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/66211
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not to be confused with "secure registers" of OTP.
Security register is a dedicated status register for security-related
bits. You don't write its value directly, issuing special write commands
with no data set separate OTP bits to 1 automatically (WRSCUR, WPSEL
commands). No WREN is necessary, but at least some datasheets indicate
BUSY state after those write commands.
Unlike cases where OTP bit is part of SR and can only be written while
in OTP mode, security register can only be written outside of the mode.
The register is found in at least these chips by Macronix:
* MX25L6436E
* MX25L6445E
* MX25L6465E
* MX25L6473E
Change-Id: Iae1753ca4cb051127a5bcbeba7f064053adb8dae
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59709
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`stlinkv3_handle` is declared without an initial value. The variable
is initialized in a branch which can only be accessed if
`devs_stlinkv3_spi[0].vendor_id != 0`. Otherwise, the variable contains
a garbage value. We can consider this case as a false positive because
`devs_stlinkv3_spi` holds as a minimum one device entry (otherwise we
wouldn't need a driver).
This issue was found by setting compiler flag `-Og`, which optimizes
debugging experience, and running scan-build. So, we have to work
around it to allow the compiler to use the flag and remove the warning
from the scan-build list.
Change-Id: Ibaf25f67186724d9045ade849026782c3eac4952
Signed-off-by: Alexander Goncharov <chat@joursoir.net>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/67700
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: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
|