OpenBMC Image Management

[Adriana Kobylak]

> On Jun 21, 2017, at 12:42 AM, Stewart Smith <stewart at linux.vnet.ibm.com> wrote:
> 
> Adriana Kobylak <anoo at linux.vnet.ibm.com <mailto:anoo at linux.vnet.ibm.com>> writes:
>>> On Jun 19, 2017, at 12:44 AM, Stewart Smith <stewart at linux.vnet.ibm.com> wrote:
>>> 
>>> Adriana Kobylak <anoo at linux.vnet.ibm.com> writes:
>>>>> Why is there mboxbridge separate from phosphor-mboxd?
>>>> 
>>>> Because the mboxbridge is being used by other companies as a reference
>>>> to be able to implement the mailbox daemon in their own BMC firmware
>>>> stack for other openpower systems, we didn’t want to “pollute” the
>>>> repository with openbmc-specific and c++ implementation that could
>>>> confuse them.
>>> 
>>> Why are there OpenBMC specific things in mboxd?
>>> 
>>> Why can't the reference implementation be used? What's deficient in it?
>> 
>> For OpenBMC, we’re having the PNOR chip with a filesystem, so mboxd
>> would read/write files instead of looking for the data at an offset in
>> the chip. Nothing deficient with it, just a different implementation
>> that needs to be handled.
> 
> Why not have an MBOX protocol that supports partitions/files natively
> then? Why not develop this upstream? Surely this is something others
> could be interested in.
> 
It’d be available in the openbmc/phosphor-mboxd repo for anybody that wants to use it. Or what do you mean by develop it upstream?
 
> It seems really backwards having a bunch of things convert to/from FFS
> for no reason.

We’re not converting back and forth, if the pnor is blank, we’ll attach ubi to it, and if the pnor is formatted as ffs it’ll be reformatted once to ubi.

> 
> The host already has such abstractions as we have it for FSP systems.
> 
> -- 
> Stewart Smith
> OPAL Architect, IBM.

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