Seems to be dead code with no call sites.
BUG=none
BRANCH=none
TEST=builds
Change-Id: Ic9f33415b8a357916891cb2006612cbf5e6aa559
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46546
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
This reverts commit a3519561bd0fb44153bb376322b799000657576f.
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>
Mostly by changing to `unsigned` types where applicable, sometimes
`signed` types, and casting as a last resort.
Change-Id: I08895543ffb7a48058bcf91ef6500ca113f2d305
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30409
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jacob Garber <jgarber1@ualberta.ca>
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>
None of these functions are used outside of the files they are defined
in, so make them all static.
Change-Id: Ie9cbe12d289bcedacf2f1bf483ae64ef8039ccc1
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33667
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This should provide more flexibility while we don't have to allocate
256B extra per layout entry.
Change-Id: Ibb903113550ec13f43cbbd0a412c8f35fe1cf454
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/33515
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This is an interim solution. We'll have to enable 4BA step-by-step for
each dediprog protocol version.
Change-Id: I08efcbb09ab3499ef6902a698e9ce3d6232237c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/30386
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
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>
4BA mode is entered by setting bit 7 for the extended address register.
Change-Id: I807bf55d65763a9f48a6a3377f14f4e5288a7a4c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Michael Fuckner <michael@fuckner.net>
Reviewed-on: https://review.coreboot.org/25133
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.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>
This imports a series of patches from chromiumos for MTD support.
The patches are squashed to ease review and original Change-Ids have
been removed to avoid confusing Gerrit.
There are a few changes to integrate the code:
- Conflict resolution
- Makefile changes
- Remove file library usage from linux_mtd. We may revisit this and use
it for other Linux interfaces later on.
- Switch to using file stream functions for reads and writes.
This consolidated patch is
Signed-off-by: David Hendricks <dhendricks@fb.com>
The first commit's message is:
Initial MTD support
This adds MTD support to flashrom so that we can read, erase, and
write content on a NOR flash chip via MTD.
BUG=chrome-os-partner:40208
BRANCH=none
TEST=read, write, and erase works on Oak
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/272983
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 2nd commit message:
linux_mtd: Fix compilation errors
This fixes compilation errors from the initial import patch.
Signed-off-by: David Hendricks <dhendricks@fb.com>
This is the 3rd commit message:
linux_mtd: Suppress message if NOR device not found
This just suppresses a message that might cause confusion for
unsuspecting users.
BUG=none
BRANCH=none
TEST=ran on veyron_mickey, "NOR type device not found" message
no longer appears under normal circumstances.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/302145
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is the 4th commit message:
linux_mtd: Support for NO_ERASE type devices
Some mtd devices have the MTD_NO_ERASE flag set. This means
these devices don't require an erase to write and might not have
implemented an erase function. We should be conservative and skip
erasing altogether, falling back to performing writes over the whole
flash.
BUG=b:35104688
TESTED=Zaius flash is now written correctly for the 0xff regions.
Signed-off-by: William A. Kennington III <wak@google.com>
Reviewed-on: https://chromium-review.googlesource.com/472128
Commit-Ready: William Kennington <wak@google.com>
Tested-by: William Kennington <wak@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
This is the 5th commit message:
linux_mtd: do reads in eraseblock-sized chunks
It's probably not the best idea to try to do an 8MB read in one syscall.
Theoretically, this should work; but MTD just relies on the SPI driver
to deliver the whole read in one transfer, and many SPI drivers haven't
been tested well with large transfer sizes.
I'd consider this a workaround, but it's still good to have IMO.
BUG=chrome-os-partner:53215
TEST=boot kevin; `flashrom --read ...`
TEST=check for performance regression on oak
BRANCH=none
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344006
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is the 6th commit message:
linux_mtd: make read/write loop chunks consistent, and documented
Theoretically, there should be no maximum size for the read() and
write() syscalls on an MTD (well, except for the size of the entire
device). But practical concerns (i.e., bugs) have meant we don't quite
do this.
For reads:
Bug https://b/35573113 shows that some SPI-based MTD drivers don't yet
handle very large transactions. So we artificially limit this to
block-sized chunks.
For writes:
It's not clear there is a hard limit. Some drivers will already split
large writes into smaller chunks automatically. Others don't do any
splitting. At any rate, using *small* chunks can actually be a problem
for some devices (b:35104688), as they get worse performance (doing an
internal read/modify/write). This could be fixed in other ways by
advertizing their true "write chunk size" to user space somehow, but
this isn't so easy.
As a simpler fix, we can just increase the loop increment to match the
read loop. Per David, the original implementation (looping over page
chunks) was just being paranoid.
So this patch:
* clarifies comments in linux_mtd_read(), to note that the chunking is
somewhat of a hack that ideally can be fixed (with bug reference)
* simplifies the linux_mtd_write() looping to match the structure in
linux_mtd_read(), including dropping several unnecessary seeks, and
correcting the error messages (they referred to "reads" and had the
wrong parameters)
* change linux_mtd_write() to align its chunks to eraseblocks, not page
sizes
Note that the "->page_size" parameter is still somewhat ill-defined, and
only set by the upper layers for "opaque" flash. And it's not actually
used in this driver now. If we could figure out what we really want to
use it for, then we could try to set it appropriately.
BRANCH=none
BUG=b:35104688
TEST=various flashrom tests on Kevin
TEST=Reading and writing to flash works on our zaius machines over mtd
Change-Id: I3d6bb282863a5cf69909e28a1fc752b35f1b9599
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/505409
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: William Kennington <wak@google.com>
Reviewed-on: https://review.coreboot.org/25706
Tested-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
When developing software that has to be flashed to a flash chip to be
executed, it often takes a long time to read the current flash contents
(for flashrom to know what pages to erase and reprogram) each time
when writing the new image. However, when the flash was just reprogrammed,
its current state is known to be the previous image that was flashed
(assuming it was verified).
Thus, it makes sense to provide that image as a file for the flash contents
instead of wasting valuable time read the whole flash each time.
Change-Id: Idf153b6955f37779ae9bfb228a434ed10c304947
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23263
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Most flash chips are erased to ones and programmed to zeros. However, some
other chips, such as the ENE KB9012 internal flash, work the opposite way.
Change-Id: Ia7b0de8568e31f9bf263ba0ad6b051e837477b6b
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23258
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
By default, we want to probe for SPI25 chips only. Other SPI use cases,
like the ENE/EDI protocol, might use commands that can confuse these
common chips.
Now, flashrom will probe for a chip only if one of these conditions is
true:
1) no chip has been specified AND the chip uses the SPI25 commands
2) this chip has been specified by -c | --chip <chipname>
The CLI can later be extended to probe for a specific class of chips.
Change-Id: I89a53ccaef2791a2ac32904d7ab813da7478a6f0
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/23262
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
Instead of arbitrarily deciding whether to enter 4BA mode in the flash
chip's declaration, advertise that entering 4BA mode is supported and
only enter it if the SPI master supports 4-byte addresses. If not, exit
4BA mode (the chip might be in 4BA mode after reset). If we can't assure
the state of 4BA mode, we bail out to simplify the code (we'd have to
ensure that we don't run any instructions that can usually be switched
to 4BA mode otherwise).
Two new feature flags are introduced:
* FEATURE_4BA_ENTER:
Can enter/exit 4BA mode with instructions 0xb7/0xe9 w/o WREN.
* FEATURE_4BA_ENTER_WREN
Can enter/exit 4BA mode with instructions 0xb7/0xe9 after WREN.
FEATURE_4BA_SUPPORT is dropped, it's completely implicit now.
Also, draw the with/without WREN distinction into the enter/exit
functions to reduce code redundancy.
Change-Id: I877fe817f801fc54bd0ee2ce4e3ead324cbb3673
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Allow 4-byte addresses for instructions usually used with 3-byte
addresses. Decide in which way the 4th byte will be communicated
based on the state of the chip (i.e. have we enabled 4BA mode)
and a new feature bit for an extended address register. If we
are not in 4BA mode and no extended address register is available
or the write to it fails, bail out.
We cache the state of 4BA mode and the extended address register
in the flashctx.
Change-Id: I644600beaab9a571b97b67f7516abe571d3460c1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22384
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Instead, continue probing the next chip.
This fixes the problem that flashrom aborts probing for
flashchips if one big flashchip (e.g. 32M/64M) can't be mapped
because of activated CONFIG_STRICT_DEVMEM kernel option.
Change-Id: Iaecfb6d30a5152c8c4b5d2804efacac85fc615f9
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reviewed-on: https://review.coreboot.org/22685
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This allows us to support flash chips in any of the following
configurations, regardless of whether the chip powers up in 3-byte or
4-byte address mode.
- standard commands with extended address register (*_4ba_ereg) or
direct commands (*_4ba_direct) in 3-byte address mode (.set_4ba =
spi_exit_4ba_*)
- standard commands (*_4ba) or direct commands (*_4ba_direct) in
4-byte address mode (.set_4ba = spi_enter_4ba_*)
- direct commands (*_4ba_direct) in either address mode (.set_4ba =
NULL)
Change-Id: I0b25309d731426940fc50956b744b681ab599e87
Signed-off-by: Ed Swierk <eswierk@skyportsystems.com>
Reviewed-on: https://review.coreboot.org/20510
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Large flash chips usually support special instructions to work with
4-bytes address directly from 3-bytes addressing mode and without
do switching to 4-bytes mode. There are 13h (4BA Read), 12h (4BA Program)
and 21h,5Ch,DCh (4BA Erase), correspondingly. However not all these
instructions are supported by all large flash chips. Some chips
support 13h only, some 13h,12h,21h and DCh, but not 5Ch. This depends
on the manufacturer of the chip.
This patch provides code to use direct 4-bytes addressing instructions.
This code should work but it tested partially only. My W25Q256FV has
support for 4BA_Read (13h), but doesn't have support 4BA_Program (12h)
and 4BA_Erase instructions. So, direct 4BA program and erase
should be tested after.
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
flashchips.c
+ modified definition of Winbond W25Q256BV/W25Q256FV chips
flashrom.c
+ modified switch to 4-bytes addressing for direct-4BA instructions
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for read/write/erase directly with 4-bytes address (from any mode)
Change-Id: Ib51bcc5de7826b30ad697fcbb9a5152bde2c2ac9
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013198.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20508
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
On some flash chips data with addresses more than 24-bit field
can address may be accessed by using Extended Address Register.
The register has 1-byte size and stores high byte of 32-bit address.
Then flash can be read from 3-bytes addressing mode with writing
high byte of address to this Register. By using this way we have
access to full memory of a chip. Some chips may support this method
only.
This patch provides code use Extended Address Register.
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
flashrom.c
+ modified switch to 4-bytes addressing to support extended address register
spi4ba.h
+ definitions for 4-bytes addressing JEDEC commands
+ functions declarations from spi4ba.c (same as in chipdrivers.h, just to see)
spi4ba.c
+ functions for write Extended Address Register
+ functions for read/write/erase with Extended Address Register
Change-Id: I09a8aa11de2ca14901f142c67c83c4fa0def4e27
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013200.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20507
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This patch integrates code of the previous patch into Flashrom's code.
All the integrations is around 3 functions spi_nbyte_read, spi_nbyte_program
and spi_byte_program. After this patch then are not static and can be called
by their pointers saved in flashchips array. Also I added to flashrom.c some
code to switch a chip to 4-bytes addressing mode. And one error message is
corrected in spi.c because it's not suitable for 32-bit addresses.
Patched files
-------------
flash.h
+ added set of 4-bytes address functions to flashchip structure definition
flashrom.c
+ added switch to 4-bytes addressing more for chips which support it
serprog.c
+ added 4-bytes addressing spi_nbyte_read call to serprog_spi_read
spi.c
+ fixed flash chip size check in spi_chip_read
spi25.c
+ added 4-bytes addressing spi_nbyte_read call to spi_read_chunked
+ added 4-bytes addressing spi_nbyte_program call to spi_write_chunked
+ added 4-bytes addressing spi_byte_program call to spi_chip_write_1
Conflicts:
serprog.c
Change-Id: Ib051cfc93bd4aa7580519e0e6206d025f3ca8049
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013205.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20505
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Drop support for Subversion in the getrevision script and Makefile.
- Add .gitignore and .gitattributes file (the latter to limit exports).
- Restore modification dates of the exported files from the SCM.
- Stop exporting SCM log dumps to CHANGELOG. This makes no sense.
- Do not export the pre-"compiled" manpage. It can be generated like
anything else from the code dump when we export the respective
variable.
The latter is added with this change.
- Add some initial client-side git hooks
* When committing check for obvious stuff you never want anyway:
- white space errors
* When pushing to the upstream repository check mandatory rules:
- existing signoffs and acks in all new commits
- no deletions or creation of branches
- do not rewrite history of the precious branches, even if forced
NOTE: This patch is adapted from Stefan Tauner's original commit:
https://mail.coreboot.org/pipermail/flashrom/2016-November/014877.html
There are a few major differences:
- This uses coreboot's commit-msg hook which includes support for
generating and appending Change-Id.
- djgpp-dos target removal is moved to a follow-up patch.
- Version string changes are moved to a follow-up patch.
Change-Id: I64eef21982cac0a0a7419bcd2c8a936672ae9cb2
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/19206
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
o Move flashbuses_to_text() to flashrom.c, it's not a cli function.
o Guard `!defined(HAVE_STRNLEN)`. This guard was introduced in
23e10b87 (Add a bunch of new/tested stuff and various small
changes 24) to support older BSDs. It's probably completely
broken because HAVE_STRNLEN is presumably a GNU autotools
thing. But we can't fix it without retesting these older BSDs.
Change-Id: I561135209b819361d125eeaeef9ff886d6bae987
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/18738
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The buffer passed to flashrom_image_write() isn't `const`. It might be
altered for full verification (with mixed contents if a layout is being
used).
Change-Id: Ibd8a9579e5dd859ae03b0deb3042b7035719e5de
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20266
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Add an option --ifd to read the ROM layout from an Intel Firmware
Descriptor (IFD). Works the same as the -l option, if given, -i
specifies the images to update.
v2: o Rebased on libflashrom, use libflashrom interface.
o Use functions from ich_descriptors.c.
v3: o Move ich_descriptors.o to LIB_OBJS, thus build it independent
of arch and programmers.
o Bail out if we aren't compiled for little endian.
o Update flashrom.8.tmpl.
v4: o Incorporated David's comments.
o Removed single-character `-d` option.
v5: Changed region names to match the output of `ifdtool --layout ...`
Change-Id: Ifafff2bf6d5c5e62283416b3269723f81fdc0fa3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17953
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a minimal libflashrom interface based on the draft in the
wiki. While the glue code in libflashrom.c is build on top of the
existing code instead on overhauling it, the interface in libflashrom.h
is supposed to be stable. So we can keep the interface and adapt
internals later if favoured, without breaking clients.
A new make target, libinstall, is also added. It installs libflashrom.a
and libflashrom.h in lib/ and include/ dirs respectively.
Hooking this into the build would break linking of the CLI and is post-
poned until that got fixed.
v2: Rebase and fixes by Anton Kochkov.
v3: o fl_image_*() rewritten with layout support (touch only included regions).
o Moved read/erase/write/verify operations to flashrom.c.
o Added layout pointer and flags to the flash context.
v4: Removed libflashrom.o from LIB_OBJS until CLI is adapted.
v5: o Incorporated David's comments.
o Added `fl_flashprog_t` as dummy parameter to hide the fact that
we have global state all around, and for future-proofness ofc.
v6: o Change namespace prefix to flashrom_.
o Remove typedefs.
Change-Id: I00f169990830aa17b7dfae5eb74010d40c476181
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17946
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Inspired by Lynxis' related work, this implements a foundation for
layout based flash access.
All operations iterate over the given layout regions. Erase and write
then walk, per region, over all erase blocks in an inner loop (which
might not be what we want, see note on optimization below). Special care
has been taken that flash content is merged properly, in case an erase
block is only partially covered by a layout region or even affects mul-
tiple regions.
A note on performance: In the case an erase block affects multiple
regions, it will probably be read, erased and written for each region.
Another approach would be to walk all erase blocks once and check for
each erase block which regions it touches (i.e. for each erase block,
merge data pontentially from the flash and all layout regions, then
flash the combined data). That might result in cleaner code. I haven't
tried it yet, though.
Change-Id: Ic6194cea4c4c430e0cf9d586052508a865b09c86
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17945
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Even though there is currently only one USB device ID in the wild using our
standard way to define the devices creates nicer output for -L and -z.
Corresponding to flashrom svn r1942.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Even though there is currently only one USB device ID in the wild using our
standard way to define the devices creates nicer output for -L and -z.
Corresponding to flashrom svn r1941.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
