--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>
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>
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>
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>
realtek_mst_i2c_spi is the only programmer which uses hyphens instead of
underscores in its parameter names. Thus, for consistency, rename the
parameters so that they use underscores.
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Change-Id: I5ff6d8d432d875670fcaa2088e9cf9d9f1b83dc2
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65935
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Peter Marheine <pmarheine@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Currently i2c programmers do not have a safe allow listing
mechanism via board_enable to facilitate fully qualified
chip detection.
Since i2c addresses alone can overlap a user may make the mistake
of using the wrong programmer. Although unlikely, it is within the
realm of possibility that a user could accidently somehow program
another chip on their board.
Change-Id: Ifb303989fdb67f7267002bd0425f3d050450ec93
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65545
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The chip targeted by the `lspcon_i2c_spi` programmer is a Parade PS175.
Rename the programmer to match the chips vendor / family instead of the
generic LSPCON protocol. Remove the `_i2c_spi` ending in preparation to
become an opaque master. The chip is visible on an Acer Chromebox CXI4.
https://www.paradetech.com/products/ps175/https://www.acer.com/ac/en/US/content/series/acerchromeboxcxi4
TEST: `make CONFIG_PARADE_LSPCON=yes` and
`meson build -Dconfig_parade_lspcon=true` produces flashrom
binaries with the parade_lspcon programmer included.
Change-Id: I9148be6d9162c1722ff739929ca5e181b628dd57
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/65547
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Projects using libflashrom like fwupd expect the user to wait for the
operation to complete. To avoid the user thinking the process has
"hung" or "got stuck" report back the progress complete of the erase,
write and read operations.
Add a new --progress flag to the CLI to report progress of operations.
Include a test for the dummy spi25 device.
TEST=./test_build.sh; ./flashrom -p lspcon_i2c_spi:bus=7 -r /dev/null --progress
Change-Id: I7197572bb7f19e3bdb2bde855d70a0f50fd3854c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/49643
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Start taking bits related to write protection into account.
Also add "hwwp" parameter for dummy programmer that sets state of WP
pin (not inverted value).
TEST=use command-line interface to run WP-related commands
dummyflasher doesn't store state of the chip between runs and flashrom
allows running only one command, so testing WP in this way is limited.
However, WP options can be combined with other operations and are
executed prior to them, so certain scenarios can be checked.
List possible ranges:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes --wp-list
Set a particular range and check status is correct:
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-enable \
--wp-range=0x00100000,0x00f00000 \
--wp-status
Enable write protection and try erasing/writing (erasing here):
# this fails
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0x00c00000 \
--wp-enable \
--erase
Write protecting empty range has no effect:
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,hwwp=yes \
--wp-range=0,0 \
--wp-enable \
--erase
Disabling WP is possible if hwwp is off:
# this fails
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=yes \
--wp-disable
# this succeeds
flashrom -p dummy:emulate=W25Q128FV,spi_status=0x80,hwwp=no \
--wp-disable
Change-Id: I9fd1417f941186391bd213bd355530143c8f04a0
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59074
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Prepare everything for emulating SR2 and SR3 for chips that have it.
This is needed for accessing SRP1 and WPS bits which are involved in
write protection. The emulated register doesn't affect anything yet
and will be tested by write-protection tests.
TEST=check how input value affects status registers of emulated chip
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x12 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x1234 |
grep 'Initial status register'
flashrom -V -p dummy:emulate=W25Q128FV,spi_status=0x123456 |
grep 'Initial status register'
Mind that at this point there are no chips that emulate more than one
status register.
Change-Id: I177ae3f068f03380f5b3941d9996a07205672e59
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59072
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Just a trivial patch to fix a few errors found by codespell.
Here's the command I used:
codespell -S subprojects,out \
-L fwe,dout,tast,crate,parms,claus,nt,nd,te,truns,trun
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I4e3b277f220fa70dcab21912c30f1d26d9bd8749
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62840
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This programmer operates much the same as realtek_mst_i2c_spi, so the
I2C options are moved to a new section describing both programmers
and a short description is added for this programmer itself.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: I9ccb9694fdea29e68f062cc049efc0204917a139
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
This programmer was undocumented.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Change-Id: Idde5a8de014fe84c4a472f8fbfd3562350997d39
Reviewed-on: https://review.coreboot.org/c/flashrom/+/63103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Nikolai Artemiev <nartemiev@google.com>
This change adds follow up changes to the man page:
- Explain (-) argument for -w/-v operations
- Expand on region name handling of -x operation
Also updates cli_classic.c to match with --help output.
BUG=b:224364316
Change-Id: I0cba593da3926c8587027789f4e1e89a2329ca7f
Signed-off-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/62794
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
It was absent from the list of emulated chips.
Change-Id: I50f6cd6c5d853d6c70921e8027ada52d27982708
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59811
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Anastasia Klimchuk <aklm@chromium.org>
This section is rather outdated and should be dispensed with.
Change-Id: Id7e0ce412901ccb27124a9958d5ef214ab289518
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/59408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This reintroduces a reworked version of the GPIOL pin control first
introduced in commit 3207844 (CB:49637), which was reverted in commit
6518cf3 (CB:55692) due to breakage.
This change introduces a new argument `gpiolX` to allow use of the four
GPIOL pins either as generic gpios or as additional CS# signal(s). `X`
specifies the GPIOL pin (0-3) to be set to one of [HLC] with the
following meaning:
* H - set the pin as output high
* L - set the pin as output low
* C - use the pin as additional CS# signal
The third value, `C`, aims to replace the parameter `csgpiol`, that is
now marked as deprecated and can be removed at some point in the future.
`gpiol` and `csgpiol` are mutually exclusive and use of both results in
an error.
Multiple pins may be set by specifying the parameter multiple times.
Documentation was updated/added accordingly.
Test: All pin levels/modes have been verified to behave correctly with a
logic analyzer.
Change-Id: I3989f0f9596c090de52dca67183b1363dae59d3a
Signed-off-by: Alan Green <avg@google.com>
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57810
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Documentation for `csgpiol` was put into the generic programmer options
section. Move it to its own section.
Change-Id: Ic7379331d36b3068eacde5a983b4ccb3afc56c51
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/57893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The flashrom project no longer uses freenode. To avoid having outdated
man pages in the future, the contact methods are now listed in the wiki.
Change-Id: I75e8f43c50dc4c3feede0250334a877cdaac8103
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/56031
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 adds a 'psus=<on|off>' option, to control the external Vcc
state of the bus pirate, allowing hardware where the SPI flash chip is
powered by the 3V3/5V lines directly.
Change-Id: I8a7d4b40c0f7f04f6976f6757f05b61f2c9958f9
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/54887
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This is a follow up change of CB:52450
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: Icc068f5545b6f30ac390b7b815a31e2d61bf4789
Reviewed-on: https://review.coreboot.org/c/flashrom/+/52892
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Add an optional sub-parameter to the -i parameter to allow building the
image to be written from multiple files. This will also allow regions to
be read from flash and written to separate image files.
This is a rebase of a patch that was ported from chromiumos. A lot of
things have changed, but the idea is the same.
Original patch by Louis Yung-Chieh Lo <yjlou@chromium.org>:
Summary: Support -i partition:file feature for both read and write.
Commit: 9c7525f
Review URL: http://codereview.chromium.org/6611015
Ported version by Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
and Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
Summary: [PATCH 2/6] layout: Add -i <region>[:<file>] support.
Review URL: https://mail.coreboot.org/pipermail/flashrom/2013-October/011729.html
Change-Id: Ic5465659605d8431d931053967b40290195cfd99
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Edward O'Callaghan <quasisec@google.com>
Signed-off-by: Daniel Campello <campello@chromium.org>
Co-Authored-by: Edward O'Callaghan <quasisec@google.com>
Co-Authored-by: Daniel Campello <campello@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/23021
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sam McNally <sammc@google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch fixes a few bugs that two patches ( `3149822cd45cb2e5841e15d648783748ba1b2ec6` && `3b8fe0f8e907c0ba9f7c7935e950f3e1538d427f`) brought:
* Check the presence of 'size' param only if the emulate is VARIABLE_SIZE.
* Initialize 'flash->st->par.data' in dummy_init() so that it can probe the VARIABLE_SIZE emulator correct in probe_variable_size().
* Replace atoi() with strtol().
* Revise man page to describe how to use the VARIABLE_SIZE emulation target.
TEST:
$ flashrom -p dummy:image=dummy.bin,emulate=VARIABLE_SIZE,size=16777216 \
-w ${IMG} -V -f
...
Verifying flash... VERIFIED.
Writing dummy.bin
$ flashrom -p dummy:image=dummy.bin,emulate=VARIABLE_SIZE -w ${IMG} -V -f
...
dummy_init: the size parameter is not given.
Unhandled programmer parameters (possibly due to another failure): image=dummy.bin,
Error: Programmer initialization failed
$ flashrom -p dummy:image=dummy.bin,emulate=SST25VF040.REMS -c SST25LF040A -w ${IMG}
...
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.
$ man flashrom
...
* Dummy vendor VARIABLE_SIZE SPI flash chip (configurable size, page write)
Example: flashrom -p dummy:emulate=SST25VF040.REMS
To use VARIABLE_SIZE chip, size must be specified to configure the size of the flash chip as a power of two.
Example: flashrom -p dummy:emulate=VARIABLE_SIZE,size=16777216,image=dummy.bin
...
Signed-off-by: Namyoon Woo <namyoon@google.com>
Change-Id: Ie6481943a831b946a91b643b4d79e684c27e48b8
Reviewed-on: https://review.coreboot.org/c/flashrom/+/46536
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This fixes a regression with the Fedora package.
Change-Id: I881bd5002a842072ce9dadea033c51a2668f9e7c
Signed-off-by: Richard Hughes <richard@hughsie.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38939
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Added spireadmode for >= Bolton.
Do not override speed or read mode for >= Bolton if parameter not
specified.
Minor cleanup of sb600spi.c code.
TEST=Manual: deploy on tremblye read flash using various parameters
BUG=b:147665085,b:147666328
BRANCH=master
Change-Id: Id7fec7eb87ff811148217dc56a86dca3fef122ff
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/38833
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The Tin Can Tools Flyswatter and Flyswatter 2 have a FT2232H
with a JTAG interface wired to port A. The buffers that drive the
JTAG pins need to be enabled with an nOE signal from the
FT2232H ADBUS6 and ADBUS7 pins.
Flyswatter has an ARM-14 JTAG interface and Flyswatter 2 has
an ARM-20 JTAG interface.
Change-Id: I56b1fb76dcda32bb02980cd54a2853506bfc9dfd
Signed-off-by: Russ Dill <Russ.Dill@gmail.com>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/36896
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We have this in the ChromiumOS fork of flashrom which we rely
on to obtain the current flash chip in use. This ports it for
upstream consumption.
V.2: Constrain number_of_operations to one as per Nico's comment.
V.3: Rename '--get-size' to '--flash-size' however keep old arg as
'undocumented' for back-compat.
V.4: Add missing --help line.
V.5: Add man page entry.
V.6: Use printf() directly.
Change-Id: I8f002f3b2012aec4d26b0e81456697b9a5de28d6
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35592
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We have this in the ChromiumOS fork of flashrom which we rely
on to obtain the current flash chip in use. This ports it for
upstream consumption.
V.2: Constrain number_of_operations to one as per Nico's comment.
V.3: Move two goto's outside inner if-else block.
V.4: Add missing --help line.
V.5: Add man page entry.
v.6: Use printf() directly.
Change-Id: I23d574a2f8eaf809a5c0524490db9e3a560ede56
Signed-off-by: Edward O'Callaghan <quasisec@chromium.org>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/35591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
We used to bail out on any unknown laptop. However, modern systems with
SPI flashes don't suffer from the original problem. Even if a flash chip
is shared with the EC, the latter has to expect the host to send regular
JEDEC SPI commands any time.
So instead of bailing out, we limit the set of buses to probe. If we
suspect to be running on a laptop, we only allow probing of SPI and
opaque programmers. The user can still use the existing force options
to probe all buses.
This will obsolete some board-enables that could be moved to `print.c`
in follow-up commits.
Change-Id: I1dbda8cf0c10d7786106f14f0d18c3dcce35f0a3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/flashrom/+/28716
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Flashmap, or simply fmap, is a binary data format for describing
region offsets, sizes, and certain attributes and is widely used by
coreboot. This patch adds support for the fmap data format version 1.1
and adds --fmap and --fmap-file arguments.
Using --fmap will make flashrom to search the ROM content for fmap
data. Using --fmap-file will make flashrom search a supplied file
for fmap data.
An example of how to update the COREBOOT region of a ROM:
flashrom -p programmer --fmap -w coreboot.rom -i COREBOOT
flashrom -p programmer --fmap-file coreboot.rom -w coreboot.rom -i COREBOOT
The fmap functions are mostly copied from cbfstool.
Currently it is made mutually exclusive with other layout options until
we are more clever about this input.
Change-Id: I0e7fad38ed79a84d41358e1f175c36d255786c12
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/23203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
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>
Replace the `ich_spi_force` logic with more helpful warnings. These can
be hidden later, in case the necessary switches are detected. Also,
demote some warnings about settings that are the default nowadays (e.g.
SPI configuration lock, inaccessible ME region).
Change-Id: I94a5e7074b845c227e43d76d04dd1a71082a1cef
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/26261
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
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>
This patch sets the default baud rate for communication between
the host device and the Bus Pirate for hardware versions 3.0
and greater to 2M baud.
It also introduces the ability to manually set the baud rate via
the added 'serialspeed' programmer parameter.
This is done in two parts. Firstly, the requested serial speed is looked up
in a table to determine the appropriate clock divisor and the divisor is sent
to the bus pirate. Then, the system's baud rate for the selected serial port
is set using serial.c's 'serialport_config'. This function's prototype had to
be added to programmer.h.
In testing, using the 2M baud rate was able to significantly decrease
flash times (down from 20+ minutes to less than 2 minutes for an 8MB flash).
Change-Id: I3706f17a94fdf056063f2ad4a5f0a219665cdcbf
Signed-off-by: Shawn Anastasio <shawnanastasio@yahoo.com>
Reviewed-on: https://review.coreboot.org/23057
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
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 option specifies to verify included regions only after a write.
It also reduces the data read before the write.
v2: o Changed short option name to `-N`.
o Added section in the manual page.
Change-Id: I40b5983f56d62821d17b827b88b73d1d41a30bd7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17950
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested mainboards:
OK:
- ASRock Fatal1ty 970 Performance and P4i65G
Reported by anonymous email message ID:
932677687262b1300eaf14260999d9262c31@guerrillamail.com
The latter actually had a tested board enable already.
Flash chips:
- Eon EN25Q128 to PREW (+PREW)
Reported by Adrian Graham
- GigaDevice GD25VQ41B to PREW (+PREW)
Reported by David Hendricks
- Winbond W39V040FB to PREW (+EW)
Reported by fjed on IRC
Miscellaneous:
- Change PCI IDs of "MS-6577 (Xenon)" board enable.
The previous IDs contained the on-board display adapter which is
disabled when a dedicated graphics card is installed.
- Add a note to the README how to overcome the clang warning if only a
single programmer is enabled.
- Fix some typo and manpage problems found by lintian
- r1920 introduced some explicit calls to pkg-config instead of $(PKG_CONFIG).
This patch corrects that.
- Make MS-7094 (K8T Neo2-F V2.0) board enable less contestable.
Previous PCI IDs were board-specific but ot the other of devices
that could be disabled by the firmware or that vary among
hardware revions. There are no good alternatives available.
However, since we always have a DMI decoder available now, we can
use non-board-specific devices without taking risks. Thanks to
Uwe Hermann for reporting and testing.
- Some other small changes to clean up whitespace and fix some warnings
from Debian's lintian.
Corresponding to flashrom svn r1951.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Apparently, there is at least one board of Russian origin (coined
SPI_TT LPT) that works with SPI Tiny Tools which is a closed-source
Windows GUI program somewhat similar to flashrom.
Corresponding to flashrom svn r1945.
Signed-off-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
Acked-by: Stefan Tauner <stefan.tauner@alumni.tuwien.ac.at>
