OpenBMC Image Management

Stewart Smith stewart at
Wed Jul 12 07:47:18 AEST 2017

Adriana Kobylak <anoo at> writes:
>> On Jun 21, 2017, at 12:42 AM, Stewart Smith <stewart at> wrote:
>> Adriana Kobylak <anoo at <mailto:anoo at>> writes:
>>>> On Jun 19, 2017, at 12:44 AM, Stewart Smith <stewart at> wrote:
>>>> Adriana Kobylak <anoo at> 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?

I mean in - the reference

>> 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.

I mean that I don't see any patches changing how we build things in
op-build, so there has to be some unpacking of the content going on

Stewart Smith
OPAL Architect, IBM.

More information about the openbmc mailing list