Refactoring skeleton flash control

[Patrick Williams]

On Wed, Nov 16, 2016 at 05:06:27PM -0800, Abhishek Pandit wrote:
> I think the flash interface will need to be updated to be able to identify
> exactly what software on the flash (i.e. Active). I don't know if a single
> version for the entire flash (i.e. bmc_v0.1.0) is appropriate or a version
> for each individual piece of the bmc image (i.e. uboot_v1.1.0,
> kernel_v4.7.11, rofs_v1.2.3). Providing this would probably require some
> compile time specialization on the host flash for different architectures.

Certainly, agree.  I expect different applications for different Host
flash layout schemes.  In fact, for Power, we are strongly considering
not even having the Host-NOR flash actually be laid out in "Power NOR"
format because we are going to use 'memboot' mode.

> For the other states (persisted, available, backup, etc), those just seem
> like policies and the actual flash interface shouldn't really care about it
> (unless the intent is to write the "backup" image to the flash itself).

Persisted vs Available is an indication of on-flash or in-tmpfs.
Backup vs Primary may be an indication of dual-sided flash scheme.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161116/1fce4aa1/attachment-0001.sig>