Introduce ability to use hardware SPI mapping for read accesses.

On X86 systems the hardware maps the bootprom SPI flash chip into the
top of memory address range. This could be used for accessing all
information in the SPI flash.

The vboot-reference code requires access to FMAP sections containing
cryptographic information, and as of today, u-boot reads the whole
sections, which are 64 KB in size, even though the actual areas
accessed by vboot-reference are much smaller.

A much faster way of accessing this information would be just passing
around pointers to the appropriate memory areas. This would eliminate
one copy, and also would make sure that only the areas actually
accessed get fetched from SPI flash.

This patch provides this ability trying to keep code changes to a
minimum.

New feature is enabled by defining CONFIG_HARDWARE_MAPPED_SPI. The
firmware storage API for file reads changes when the new configuration
option is set: a pointer to pointer to buffer is passed to the
read_spi() function instead of a pointer to buffer. When the new
feature is enabled the read_spi() function sets the pointer value to
point to the requested data instead of copying the data into the
buffer.

A new data type is introduced (read_buf_type), which is set to be a
(void *) if the new feature is not enabled, or (void **) otherwise.
This type is used as the buffer pointer in the spi_read() function.

Code allocating/freeing buffers used to keep data read from SPI flash
is now conditionally compiled.

Call sites for the spi_read() function are modified to adjust the
buffer pointer parameter (pass the address of the parameter instead of
the parameter, when the new feature is enabled).

gbb field access functions can be aliased to gbb_init(), as they all
in fact do the same - read a certain section of the gbb area.

This change does not benefit the ARM implementations, and makes the
code more complicated that it should be. Some u-boot rearchitecture
along with vboot_reference API enhancements could address this. A
tracking issue
(http://code.google.com/p/chromium-os/issues/detail?id=22528) has been
opened for that.

BUG=chrome-os-partner:6585, chromium-os:22528
TEST=manual
  . build a new stumpy firmware image
  . boot the stumpy, observe it start up chromeos.
  . assess the boot timing using the cbmem.py utility (this
    modification shaves in excess of 100ms off the boot time).
  . disable the new feature, build a stumpy image, observe that is
    still boots chromeOs.
  . run emerge-terga2_kaen chromeos-u-boot to confirem that ARM
    version builds cleanly.

Change-Id: I4e6ab530d24f5771b5a86a48d3f3135101b469a6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11152

1 files changed, 2 insertions, 0 deletions

diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
index e76edce6d6..47f4634f3c 100644
--- a/include/configs/coreboot.h
+++ b/include/configs/coreboot.h
@@ -318,6 +318,8 @@
 #undef CONFIG_CMD_NET
 #endif
 
+#define CONFIG_HARDWARE_MAPPED_SPI
+
 /* Board specific late time init */
 #define CONFIG_MISC_INIT_R