mirror of
https://review.coreboot.org/flashrom.git
synced 2025-04-29 07:53:44 +02:00
f9a3055480
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>
-------------------------------------------------------------------------------
flashrom README
-------------------------------------------------------------------------------
flashrom is a utility for detecting, reading, writing, verifying and erasing
flash chips. It is often used to flash BIOS/EFI/coreboot/firmware images
in-system using a supported mainboard, but it also supports flashing of network
cards (NICs), SATA controller cards, and other external devices which can
program flash chips.
It supports a wide range of flash chips (most commonly found in SOIC8, DIP8,
SOIC16, WSON8, PLCC32, DIP32, TSOP32, and TSOP40 packages), which use various
protocols such as LPC, FWH, parallel flash, or SPI.
Do not use flashrom on laptops (yet)! The embedded controller (EC) present in
many laptops might interact badly with any attempts to communicate with the
flash chip and may brick your laptop.
Please make a backup of your flash chip before writing to it.
Please see the flashrom(8) manpage.
Packaging
---------
To package flashrom and remove dependencies on Git, either use
make export
or
make tarball
'make export' will export all flashrom files from the Git repository at
revision HEAD into a directory named "$EXPORTDIR/flashrom-$RELEASENAME"
and will additionally add a "versioninfo.inc" file in that directory to
contain the Git revision of the exported tree and a date for the manual
page.
'make tarball' will simply tar up the result of make export and compress
it with bzip2.
The snapshot tarballs are the result of 'make tarball' and require no
further processing.
Build Instructions
------------------
To build flashrom you need to install the following software:
* pciutils+libpci (if you want support for mainboard or PCI device flashing)
* libusb (if you want FT2232, Dediprog or USB-Blaster support)
* libftdi (if you want FT2232 or USB-Blaster support)
Linux et al:
* pciutils / libpci
* pciutils-devel / pciutils-dev / libpci-dev
* zlib-devel / zlib1g-dev (needed if libpci was compiled with libz support)
On FreeBSD, you need the following ports:
* devel/gmake
* devel/libpci
On OpenBSD, you need the following ports:
* devel/gmake
* sysutils/pciutils
To compile on Linux, use:
make
To compile on FreeBSD, OpenBSD or DragonFly BSD, use:
gmake
To compile on Nexenta, use:
make
To compile on Solaris, use:
gmake LDFLAGS="-L$pathtolibpci" CC="gcc -I$pathtopciheaders" CFLAGS=-O2
To compile on NetBSD (with pciutils, libftdi, libusb installed in /usr/pkg/), use:
gmake
To compile and run on Darwin/Mac OS X:
Install DirectHW from coresystems GmbH.
DirectHW is available at http://www.coreboot.org/DirectHW .
To cross-compile on Linux for DOS:
Get packages of the DJGPP cross compiler and install them:
djgpp-filesystem djgpp-gcc djgpp-cpp djgpp-runtime djgpp-binutils
As an alternative, the DJGPP web site offers packages for download as well:
djcross-binutils-2.29.1-1ap.x86_64.rpm
djcross-gcc-7.2.0-1ap.x86_64.rpm
djcrx-2.05-5.x86_64.rpm
The cross toolchain packages for your distribution may have slightly different
names (look for packages named *djgpp*).
Alternatively, you could use a script to build it from scratch:
https://github.com/andrewwutw/build-djgpp
You will need the libpci and libgetopt library source trees and
their compiled static libraries and header files installed in some
directory say libpci-libgetopt/, which will be later specified with
LIBS_BASE parameter during flashrom compilation. Easiest way to
handle it is to put pciutils, libgetopt and flashrom directories
in one subdirectory. There will be an extra subdirectory libpci-libgetopt
created, which will contain compiled libpci and libgetopt.
Download pciutils 3.5.6 and apply http://flashrom.org/File:Pciutils-3.5.6.patch.gz
Compile pciutils, using following command line:
make ZLIB=no DNS=no HOST=i386-djgpp-djgpp CROSS_COMPILE=i586-pc-msdosdjgpp- \
PREFIX=/ DESTDIR=$PWD/../libpci-libgetopt \
STRIP="--strip-program=i586-pc-msdosdjgpp-strip -s" install install-lib
Download and compile with 'make' http://flashrom.org/File:Libgetopt.tar.gz
Copy the libgetopt.a to ../libpci-libgetopt/lib and
getopt.h to ../libpci-libgetopt/include
Enter the flashrom directory.
make CC=i586-pc-msdosdjgpp-gcc STRIP=i586-pc-msdosdjgpp-strip LIBS_BASE=../libpci-libgetopt/ strip
If you like, you can compress the resulting executable with UPX:
upx -9 flashrom.exe
To run flashrom.exe, download http://flashrom.org/File:Csdpmi7b.zip and
unpack CWSDPMI.EXE into the current directory or one in PATH.
To cross-compile on Linux for Windows:
Get packages of the MinGW cross compiler and install them:
mingw32-filesystem mingw32-cross-cpp mingw32-cross-binutils mingw32-cross-gcc
mingw32-runtime mingw32-headers
The cross toolchain packages for your distribution may have slightly different
names (look for packages named *mingw*).
PCI-based programmers (internal etc.) are not supported on Windows.
Run (change CC= and STRIP= settings where appropriate)
make CC=i686-w64-mingw32-gcc STRIP=i686-w64-mingw32-strip
Processor architecture dependent features:
On non-x86 architectures a few programmers don't work (yet) because they
use port-based I/O which is not directly available on non-x86. Those
programmers will be disabled automatically if you run "make".
Compiler quirks:
If you are using clang and if you want to enable only one driver, you may hit an
overzealous compiler warning from clang. Compile with "make WARNERROR=no" to
force it to continue and enjoy.
Installation
------------
In order to install flashrom and the manpage into /usr/local, type:
make install
For installation in a different directory use DESTDIR, e.g. like this:
make DESTDIR=/usr install
If you have insufficient permissions for the destination directory, use sudo
by adding sudo in front of the commands above.
Contact
-------
The official flashrom website is:
http://www.flashrom.org/
The IRC channel is
#flashrom at irc.freenode.net
The mailing list address is
flashrom@flashrom.org