lib/boot_device: add RW boot device construct

The current boot device usage assumes read-only semantics to
the boot device. Any time someone wants to write to the
boot device a device-specific API is invoked such as SPI flash.
Instead, provide a mechanism to retrieve an object that can
be used to perform writes to the boot device. On systems where
the implementations are symmetric these devices can be treated
one-in-the-same. However, for x86 systems with memory mapped SPI
the read-only boot device provides different operations.

BUG=chrome-os-partner:55932

Change-Id: I0af324824f9e1a8e897c2453c36e865b59c4e004
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16194
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This commit is contained in:
Aaron Durbin
2016-08-10 11:42:42 -05:00
committed by Martin Roth
parent e8e118dd32
commit dcbccd6a1e
2 changed files with 36 additions and 8 deletions

View File

@ -18,9 +18,18 @@
#include <commonlib/region.h>
/*
* Please note that the read-only boot device may not be coherent with
* the read-write boot device. Thus, mixing mmap() and writeat() is
* most likely not to work so don't rely on such semantics.
*/
/* Return the region_device for the read-only boot device. */
const struct region_device *boot_device_ro(void);
/* Return the region_device for the read-write boot device. */
const struct region_device *boot_device_rw(void);
/*
* Create a sub-region of the read-only boot device.
* Returns 0 on success, < 0 on error.
@ -28,6 +37,13 @@ const struct region_device *boot_device_ro(void);
int boot_device_ro_subregion(const struct region *sub,
struct region_device *subrd);
/*
* Create a sub-region of the read-write boot device.
* Returns 0 on success, < 0 on error.
*/
int boot_device_rw_subregion(const struct region *sub,
struct region_device *subrd);
/*
* Initialize the boot device. This may be called multiple times within
* a stage so boot device implementations should account for this behavior.