linux_mtd: Import driver from ChromiumOS

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>

1 files changed, 1 insertions, 0 deletions

diff --git a/flash.h b/flash.h
index 72d345a4d..fca377506 100644
--- a/flash.h
+++ b/flash.h
@@ -131,6 +131,7 @@ enum write_granularity {
  * other flash chips, such as the ENE KB9012 internal flash, work the opposite way.
  */
 #define FEATURE_ERASED_ZERO	(1 << 16)
+#define FEATURE_NO_ERASE	(1 << 17)
 
 #define ERASED_VALUE(flash)	(((flash)->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff)