OpenBMC Image Management

[Adriana Kobylak]

> On Jun 16, 2017, at 5:18 PM, Maxim Sloyko <maxims at google.com> wrote:
> 
> Hi Adriana,
> 
> On Wed, Jan 25, 2017 at 2:15 PM, Adriana Kobylak <anoo at linux.vnet.ibm.com <mailto:anoo at linux.vnet.ibm.com>> wrote:
> Hi,
> 
> Here is a first draft proposal for image management (code update) in OpenBMC for feedback.
> 
> General:
> * Move to UBI volume management (on the BMC and PNOR chips), which provides dynamic partitioning and wear-leveling. In a limited flash space environment there might be the need to re-allocate partition space and resizing in a static partitioning implementation can be very painful.
> * Use CRAMFS for read-only partitions, and UBIFS for read-write partitions.
> 
> PNOR:
> * Implement a new mboxd based on Cyril’s (see Cyril’s email “Mailbox daemon”) that handles dbus objects, generates a virtual PNOR for UBI content, etc.
> * Move to memory-based access instead of the current LPC-to-AHD path.
> * Allocate just enough space in the initial window for Hostboot’s TOC, HBB, and HBI partitions, grow as required.
> * Ability to ‘patch’ by copying a Hostboot image *.bin into a designated directory (/usr/local/ for example).
> * Tool to write from PNOR image to BMC format. Implement UBI initially but it could be extended to support different volume managements on other BMCs.
> 
> BMC:
> *Save multiple firmware versions, starting with 2, to provide the ability to roll-back if needed. If single BMC chip system, save both versions there. If two BMC chip system, save other version in 2nd chip.
> * Implement various levels of ‘persistency’, such as dev, factory, field. Dev persistency would allow for local patches (/usr/local/ for example) that can be cleared before shipping to customers. Factory mode could delete the location where user data such as network settings resides but preserves the mac address and uuid for example. Etc.
> 
> I'm interested in roll-back feature, do you have something working already or is this still under construction?
> 
> Sorry, I could not find anything in the docs or code about it.

For the roll-back feature, the user would use the RedundancyPriority interface (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Software/RedundancyPriority.interface.yaml
), to indicate which version they want to re-activate. For example, the version1 is activated, the priority for it is 0, then version 2 is activated which sets its priority to 0 and version 1 is set to priority 1. The user can set the priority of version 1 to 0 to indicate that version 1 should be activated thus triggering a roll back. This takes effect on power on for pnor version, and on bmc reboots (still been worked) for bmc versions.
> 
> Thanks 
>  
> 
> Thanks,
> 
> Adriana
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org <mailto:openbmc at lists.ozlabs.org>
> https://lists.ozlabs.org/listinfo/openbmc <https://lists.ozlabs.org/listinfo/openbmc>
> 
> 
> 
> -- 
> Maxim Sloyko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170802/78d53f47/attachment-0001.html>