OpenBMC Image Management

[Adriana Kobylak]

> On Jan 26, 2017, at 4:43 AM, Anton D. Kachalov <mouse at yandex-team.ru> wrote:
> 
> Hello.
> 
> 26.01.2017, 01:32, "Adriana Kobylak" <anoo at linux.vnet.ibm.com <mailto:anoo at linux.vnet.ibm.com>>:
>> General:
>> * Use CRAMFS for read-only partitions, and UBIFS for read-write partitions.
> 
> Why CRAMFS? It's small, but supports only zlib compression, has a 16MB file size limitation and marked as obsolete in kernel tree. Why not SquashFS? It's better for larger projects, has a number of modern compression algos.

You’re right Anton, typo mistake, it should be SquashFS, not CRAMFS.

> 
>> PNOR:
>> * Ability to ‘patch’ by copying a Hostboot image *.bin into a designated directory (/usr/local/ for example).
> 
> Would it be good to add support for opkg-based packaging to incrementally (hotfix) system's update? I use it in OpenWRT.

It is a good point, for this we’d need a read-write filesystem to contain the code, and be more formal in updating the revision number in bitbake for the images (currently is set to 0). But since our current use case is about applying temporary (development) patches, not permanent fixes, these changes wouldn’t be a priority at the moment. Also for PNOR images, we don’t own the packaging process (it’s done by the hostboot build).

As additional information, I’ll be sending a more detailed flow of the PNOR update, including how the dbus objects in Patrick’s Software.Version yaml specification would fit, and how to create the virtual PNOR for the host (memory piece) that the mboxd will be interacting with.

> 
>> * 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.
>> 
>> Thanks,
>> 
>> Adriana
>> _______________________________________________
>> openbmc mailing list
>> openbmc at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/openbmc
> 
> -- 
> Anton D. Kachalov

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