From f9a30554803a670f9b95a7794be00f03929d6ecd Mon Sep 17 00:00:00 2001 From: David Hendricks Date: Sat, 23 May 2015 20:30:30 -0700 Subject: 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 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 Reviewed-on: https://chromium-review.googlesource.com/272983 Reviewed-by: Shawn N 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 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 Reviewed-on: https://chromium-review.googlesource.com/302145 Commit-Ready: David Hendricks Tested-by: David Hendricks Reviewed-by: Shawn N 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 Reviewed-on: https://chromium-review.googlesource.com/472128 Commit-Ready: William Kennington Tested-by: William Kennington Reviewed-by: Brian Norris 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 Reviewed-on: https://chromium-review.googlesource.com/344006 Reviewed-by: David Hendricks 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 Reviewed-on: https://chromium-review.googlesource.com/505409 Reviewed-by: David Hendricks Reviewed-by: Martin Roth Reviewed-by: William Kennington Reviewed-on: https://review.coreboot.org/25706 Tested-by: David Hendricks Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber Reviewed-by: Philipp Deppenwiese --- Makefile | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) (limited to 'Makefile') diff --git a/Makefile b/Makefile index d150dcb0..943d88d7 100644 --- a/Makefile +++ b/Makefile @@ -341,6 +341,11 @@ endif ifneq ($(TARGET_OS), Linux) # Android is handled internally as separate OS, but it supports CONFIG_LINUX_SPI and CONFIG_MSTARDDC_SPI ifneq ($(TARGET_OS), Android) +ifeq ($(CONFIG_LINUX_MTD), yes) +UNSUPPORTED_FEATURES += CONFIG_LINUX_MTD=yes +else +override CONFIG_LINUX_MTD = no +endif ifeq ($(CONFIG_LINUX_SPI), yes) UNSUPPORTED_FEATURES += CONFIG_LINUX_SPI=yes else @@ -624,7 +629,8 @@ CONFIG_DEDIPROG ?= yes # Always enable Marvell SATA controllers for now. CONFIG_SATAMV ?= yes -# Enable Linux spidev interface by default. We disable it on non-Linux targets. +# Enable Linux spidev and MTD interfaces by default. We disable them on non-Linux targets. +CONFIG_LINUX_MTD ?= yes CONFIG_LINUX_SPI ?= yes # Always enable ITE IT8212F PATA controllers for now. @@ -902,6 +908,12 @@ PROGRAMMER_OBJS += satamv.o NEED_LIBPCI += CONFIG_SATAMV endif +ifeq ($(CONFIG_LINUX_MTD), yes) +# This is a totally ugly hack. +FEATURE_CFLAGS += $(call debug_shell,grep -q "LINUX_MTD_SUPPORT := yes" .features && printf "%s" "-D'CONFIG_LINUX_MTD=1'") +PROGRAMMER_OBJS += linux_mtd.o +endif + ifeq ($(CONFIG_LINUX_SPI), yes) # This is a totally ugly hack. FEATURE_CFLAGS += $(call debug_shell,grep -q "LINUX_SPI_SUPPORT := yes" .features && printf "%s" "-D'CONFIG_LINUX_SPI=1'") @@ -1277,6 +1289,18 @@ int main(int argc, char **argv) endef export UTSNAME_TEST +define LINUX_MTD_TEST +#include + +int main(int argc, char **argv) +{ + (void) argc; + (void) argv; + return 0; +} +endef +export LINUX_MTD_TEST + define LINUX_SPI_TEST #include #include @@ -1333,6 +1357,15 @@ ifneq ($(NEED_LIBFTDI), ) ( echo "not found."; echo "FTDISUPPORT := no" >> .features.tmp ) } \ 2>>$(BUILD_DETAILS_FILE) | tee -a $(BUILD_DETAILS_FILE) endif +ifeq ($(CONFIG_LINUX_MTD), yes) + @printf "Checking if Linux MTD headers are present... " | tee -a $(BUILD_DETAILS_FILE) + @echo "$$LINUX_MTD_TEST" > .featuretest.c + @printf "\nexec: %s\n" "$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX)" >>$(BUILD_DETAILS_FILE) + @ { $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) .featuretest.c -o .featuretest$(EXEC_SUFFIX) >&2 && \ + ( echo "yes."; echo "LINUX_MTD_SUPPORT := yes" >> .features.tmp ) || \ + ( echo "no."; echo "LINUX_MTD_SUPPORT := no" >> .features.tmp ) } \ + 2>>$(BUILD_DETAILS_FILE) | tee -a $(BUILD_DETAILS_FILE) +endif ifeq ($(CONFIG_LINUX_SPI), yes) @printf "Checking if Linux SPI headers are present... " | tee -a $(BUILD_DETAILS_FILE) @echo "$$LINUX_SPI_TEST" > .featuretest.c -- cgit v1.2.3