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>
The ENE Embedded Debug Interface (EDI) is a SPI-based interface for
accessing the memory of ENE embedded controllers.
The ENE KB9012 EC is an embedded controller found on various laptops
such as the Lenovo G505s. It features a 8051 microcontroller and
has 128 KiB of internal storage for program data.
EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO)
when flash direct access is not in use. Some firmwares disable EDI at runtime
so it might be necessary to ground pin 42 to reset the 8051 microcontroller
before accessing the KB9012 via EDI.
The example of flashing KB9012 at Lenovo G505S laptop could be found here:
http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
Change-Id: Ib8b2eb2feeef5c337d725d15ebf994a299897854
Signed-off-by: Mike Banon <mikebdp2@gmail.com>
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/23259
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
internal_init() explicitly fails on everything but x86 and mipsel.
Instead, we can just never build the internal programmer on other
architectures and drop a lot of #if boilerplate.
Change-Id: I672ddab0415df3baa49ff39a1c9db1b41d8143a4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22671
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Add an `endiantest.c` similar to `archtest.c` to provide the endianness
inside the Makefile. The __FLASHROM_(LITTLE|BIG)_ENDIAN__ definitions
had to move from `hwaccess.h` into `platform.h`, therefor. This will
be used to decide whether to build the internal programmer in a follow-
up.
Change-Id: I55dcf5a88da48f885cda9ad89ab87395d895a891
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/22670
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
Tarballs on download.flashrom.org are generally packaged using bzip2, so
we may as well be internally consistent.
Change-Id: Ib9fb1ea6d5994cd0285ce8db9675640fae992773
Signed-off-by: David Hendricks <dhendricks@fb.com>
Reviewed-on: https://review.coreboot.org/22116
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If flash chip is switched to 4-bytes addressing mode then all
read/erase/program instructions will be switched from 3-bytes mode
to 4-bytes mode. Then well known instructions like 03h (Read),
02h (Program) and 20h,52h,D8h (Erase) will become one byte longer
and accept 4-bytes address instead of 3-bytes.
This patch provides support for well known instructions in 4-bytes
addressing mode. Also here is the code to enter 4-bytes addressing
mode by execute the instruction B7h (Enter 4-bytes mode).
Patched files
-------------
chipdrivers.h
+ added functions declarations for spi4ba.c
flash.h
+ feature definitions added
Makefile
+ added spi4ba.c
Added files
-----------
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 enter 4-bytes addressing mode
+ functions for read/write/erase in 4-bytes addressing mode
Change-Id: Ie72e2a89cd75fb4d09f48e81c4c1d927c317b7a7
Signed-off-by: Boris Baykov <dev@borisbaykov.com>, Russia, Jan 2014
[clg: ported from
https://www.flashrom.org/pipermail/flashrom/2015-January/013199.html ]
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-on: https://review.coreboot.org/20513
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>
- exploit Make's -include statement to simplify execution flow
- expand and refine respective comment to better describe and
match the new behavior
Change-Id: I0c66f2508cc754cf9219211a06d6f305a32c422d
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21830
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Rename getrevision's local_revision function to just revision.
All revisions are local in git and we certainly wont go back to
a non-distributed VCS :)
Change-Id: I6689ac24077b3981b471ed69de7cc3ef79d435b1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21829
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- make version string generation independent of the actual VCS
used by not generating "unknown" in the makefile but letting
getrevision do that
- make hook installation independent of version string generation
since they have nothing to do with each other and there are no
synergies anymore
Change-Id: Iedc9df4c033a70447b8b1b65c83764c769b02c3f
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21827
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fix broken/one-off loop to restore file dates.
Explain what the sed program actually does because it is non-trivial.
Change-Id: Iff4021be49a9fab208b619c555b9f9e81f671ab8
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: https://review.coreboot.org/21825
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
- 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>
Instead of calibrating our busy loop against a coarse clock, check if
a precise clock is available and loop against that. The former is unre-
liable by definition on any modern system that may dynamically reclock
the processor.
v2: Apparently _POSIX_MONOTONIC_CLOCK being defined only means that
the library knows about CLOCK_MONOTONIC. So check for its support
at runtime and fall back to CLOCK_REALTIME if it's missing.
TEST=Manually added a 10s loop and compared to real time. Run
on Linux RPi3, Linux x86 and my original use case Linux in
VirtualBox (Linux host).
Change-Id: I85ad359823875237ada9cd027af3017d62e9a235
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/19391
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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 renames CLI's print() to flashrom_print_cb() and registers it
through the new libflashrom interface.
v2: Add libflashrom.o to LIB_OBJS now that everything can be linked
together.
Change-Id: Idf19978eb8e340d258199193d2978f37409e9983
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17948
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: David Hendricks <david.hendricks@gmail.com>
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>
Lubomir Rintel
Miklós Márton
David Hendricks
Elyes HAOUAS
Paul Kocialkowski
Nico Huber
Urja Rannikko
Boris Baykov
Stefan Tauner
Stefan Tauner
Nico Huber