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>
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>
This change introduces a new option to extract all layout regions to
files with the name of each region (or with the provided filename via
-i region:file). It is implemented by mutating the flash layout to
include all regions and backfilling the entry->file with entry->name
(replacing spaces with underscores)
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I8c69223fa92cf5b50abe070f1ab9f19d3b42f6ff
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52450
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Allows - as filename for -w/-v options. It is sometimes useful to
script flashrom and allowing it to work with pipes allows for more
flexibility in this specific use-case.
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I97889cfdf7ba9a257e182c4ee2b20075cfa58d4d
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52383
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Allows drivers to register a callback function to reset the
chip state once programming has finished. This is used by
the s25f driver added in a later patch, which needs to change
the chip's sector layout to be able to write to the entire flash.
Adapted from cros flashrom at
`9c4c9a56b6a0370b383df9c75d71b3bd469e672d`.
BUG=b:153800073
BRANCH=none
TEST=builds
Change-Id: I2a522dc1fd3952793fbcad70afc6dd43850fbbc5
Signed-off-by: Nikolai Artemiev <nartemiev@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/47276
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Unfortunately raiden_debug was upstreamed with a slightly
incorrect name of "raiden_debug" whereas in ChromiumOS
it is known as "raiden_debug_spi" and so correct this to
align. This avoids confusion and divergence for a unified
future.
Change-Id: I0eca35863403c5d4adbe19b31801e8dfa072006f
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48106
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Unfortantly raiden_debug was upstreamed with a misnaming
of the CONFIG_ make param that introduces unnecessary divergence.
Rename to 'CONFIG_RAIDEN_DEBUG_SPI' as-is downstream.
Change-Id: I07c03647c329286bb223e4dae4665704e508db2c
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/48105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
This reverts commit a3519561bd.
Breaks support for most SPI flash chips. It's too big and too
invasive to be reviewed as a single commit.
The changes to `spi_poll_wip():spi25.c` were not noticed in the
original review that were from the similarly named function and
file `s25f_poll_status():s25f.c` in the downstream Chromium fork.
V.2: Rebase and rephrase commit msg to reflect how the issue
slipped in.
Change-Id: Id2a4593bdb654f8a26957d69d52189ce61621d93
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/40626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shiyu Sun <sshiyu@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This may seem too big just to support yet another flash chip, but in
reality it brings support for whole new family of S25FS
Spansion/Cypress flash chips. These chips require handling of some
special status registers for erasing or writing, with very specific
timing checks in place.
For example, WIP status bit will remain being set to 1 if erase or
programming errors occur, and in that case chip 'software reset' has
to be performed otherwise the chip will remain unresponsive to all
further commands. Also, special CR3NV register (Configuration Register
3 Nonvolatile) status bits needs to be read and set by using RDAR
(ReaD Any Register) and WRAR (WRite Any Register) OP commands, and
these states are needed to determine which type of reset feature is
enabled at the time (legacy or S25FS type) in the first place,
determine whether Uniform or Hybrid sector architecture is used
at the time, or set programming buffer address wrap point (256 or 512
bytes). Furthermore, S25FS chip status register has to be restored to
its original state (hence that ugly CHIP_RESTORE_CALLBACK) following
erasing or writing, failing to do so may result in host being unable
to access data on the chip at all.
Finally, although this brings support for the whole family of chips,
I only have one such chip to do the actual testing, S25FS128S (Small
Sectors), which I had fully tested on ch341a and FT4232H programmers,
with confirmed working probe, read, erase and write.
Full summary of changes are here:
flashchips:
add new flashchip sctructure property:
.reset
add chip definitions:
S25FS128S Large Sectors
S25FS128S Small Sectors
flash:
add macro (chip_restore_func_data call-back):
CHIP_RESTORE_CALLBACK
flashrom:
add struct:
chip_restore_func_data
add call-back function:
register_chip_restore
spi:
add OP codes:
CMD_RDAR, CMD_WRAR, CMD_WRAR_LEN, CMD_RSTEN, CMD_RST
add register bit function definitions:
CR3NV_ADDR, CR3NV_20H_NV
add timers:
T_W, T_RPH, T_SE
spi25:
refactor (based on chromiumos implementation) function:
spi_poll_wip
port these functions from chromiumos:
probe_spi_big_spansion
s25fs_software_reset
s25f_legacy_software_reset
s25fs_block_erase_d8
spi25_statusreg:
port these functions from chromiumos:
spi_restore_status
s25fs_read_cr
s25fs_write_cr
s25fs_restore_cr3nv
Most of the ported functions are originally from s25f.c found at
https://chromium.googlesource.com/chromiumos/third_party/flashrom
with exception of spi_restore_status which is defined in
spi25_statusreg.c. The rest of macros and OP codes are defined in
same files as in this commit.
Change-Id: If659290874a4b9db6e71256bdef382d31b288e72
Signed-off-by: Samir Ibradzic <sibradzic@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39822
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This adds support for the Parade lspcon usb-c to HDMI protocol
translater part that is i2c-controlled. The support allows the
host to reach the SPI ROM that hangs off the part where it
stores its firmware.
Usage is as follows:
flashrom -p lspcon_i2c_spi:bus=X
where X is the bus number.
BUG=b:148746232
BRANCH=none
TEST=tested with following commands, read/write/erase works good.
flashrom -p lspcon_i2c_spi:bus=7 -r /tmp/foo;
flashrom -p lspcon_i2c_spi:bus=7 -E;
flashrom -p lspcon_i2c_spi:bus=7 -w /tmp/foo;
Change-Id: I039e683252cfaf1ffef8694a3e8081b1b6b944f7
Signed-off-by: Shiyu Sun <sshiyu@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39687
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
The raiden_debug programmer is of type USB. However, it does not set the
field `devs.dev`, which will result in a segfault when trying to print
the devices of the non-existing table.
Fix that by replacing `devs.note` with `devs.dev` and adding an empty
device table. Since Device IDs are not used to match programmers,
nothing could be added to the table.
TEST=Running `flashrom -L` no longer segfaults and returns normally.
Change-Id: Ie4171a11384c34abb102d1aadf86aa1b8829fc04
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/39826
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These functions are no longer used, or were never used in the first place.
generate_testpattern() - Introduced in commit eaac68bf8b, never used
list_programmers() - Introduced in commit 552420b0d6, never used
pci_dev_find_filter() - Prototype removed in commit 5c316f9549
erase_chip_jedec() - Usage and prototype removed in commit f52f784bb3
printlock_regspace2_blocks() - Introduced in commit ef3ac8ac17, never used
spi_write_status_enable() - Usage dropped in commit fcbdbbc0d4
Change-Id: I742164670521fea65ffa3808446594848ce63cec
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The full verification step was not accounting for sparse layouts.
Instead of the old contents, combine_image_by_layout() implicitly
assumed the new contents for unspecified regions.
Change-Id: I44e0cea621f2a3d4dc70fa7e93c52ed95e54014a
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
The erase (-E) feature is somehow a brute force method, but still, if we
are given a region to erase, we should make sure to restore surrounding
data if the erase block expands beyond the region.
It shares a lot of code with the write path. Though, experiments with
common functions have shown that it would make the whole function even
harder to read. Maybe we could add some abstraction if we ever need
similar code on a third path.
Change-Id: I5fc35310f0b090f218cd1d660e27fb39dd05c3c5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/c/31068
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The 96Boards Developerbox (a.k.a. Synquacer E-series) provides a CP2102
debug UART with its GPIO pins hooked up to the SPI NOR FLASH. The
circuit is intended to provide emergency recovery functions without
requiring any additional tools (such as a JTAG or SPI programmer). This
was expected to be very slow (and it is) but CP2102 is much cheaper than
a full dual channel USB comms chip.
Read performance is roughly on par with a 2400 baud modem (between 60
and 70 minutes per megabyte if you prefer) and write performance is 50%
slower still. The full recovery process, with backup and verification of
4MB data written takes between 14 and 15 hours. Thus it is only really
practical as an emergency recovery tool, firmware developers will need
to use an alternative programmer.
Change-Id: I2547a96c1a2259ad0d52cd4b6ef42261b37cccf3
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is driver that supports the Lattice iCE40 evaluation kits. On the
board is a SPI flash memory chip labeled ST 25P10VP.
Tested to work read/write/erase with "-p digilent_spi -c M25P10" or
with a patch that resets the part beforehands (in which case it gets
detected as a M25P10-A and is way faster due to paged writes).
Change-Id: I7ffcd9a2db4395816f0e8b6ce6c3b0d8e930c9e6
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-on: https://review.coreboot.org/23338
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
