Mailbox daemon

[Patrick Williams]

Cyril,

On Fri, Jan 06, 2017 at 11:47:50AM +1100, Cyril Bur wrote:
> I recently sent patches to linux to be able to use the mailbox drivers
> on the BMC so we can avoid having the host LPC bus mapped directly to
> the pnor.

Thanks for this work so far.

We had an internal discussion with the host firmware team and they
want to go this direction for P9 so that, among other reasons, it
reduces the duplication of the SFC drivers.  Right now we have the BMC
and two different host firmware implementations.  Unfortunately(?) they
would like this in very soon, but I believe you have been working with
them on this.

Knowing the [inefficient] layout of the Power firmware 'ffs'
partitioning scheme and some of the limitations of the host firmware
that uses it, I would also like us to no longer layout the real PNOR in
'ffs' format but instead use files in a BMC mapped file system.  This
allows us to, for example, use cramfs-xz for the read-only portions.  I
need to get someone on a design for this soon.

Considering that, I would also like this to work on P8 systems because
the majority development vehicle we have available are Barreleye and
Palmetto systems.  We can get this working on P9 systems first but we
should get the host-firmware pieces backported to P8 soon after.

> Obviously there needs to be a userspace component. I've been using a
> fairly simple daemon for testing: https://github.com/cyrilbur-ibm/mboxb
> ridge.  It will absolutely do for development. I'm hopeful to grow this
> into something that isn't quite so static. Being able to tell it that
> the flash is actually a file and not /dev/mtd would be great and at the
> moment its quite dumb and is much slower than it could be.
> 
> Is it possible to get an openbmc repo for it?

I see it as very reasonable to have a reference application for the
mailbox protocol implementation.  I do wonder about the longevity of
usefulness and system-agnostic aspects in order to continue develop on
it beyond doing the dumb mapping.

Points to consider:
    *  Adding mapping of a single file is still, likely, system-agnostic
       as long as you either disallow writing or allow writing to the
       whole area.  Anything more requires knowing the layout (ex. ffs)
       which means the mailbox daemon becomes Power-specific.  We have
       been trying to prefix Power-specific implementations [repos] with
       'openpower-*'.  It does seem very worthwhile to have and maintain
       a system-agnostic implementation though that does the simple
       mapping so that other platforms have a smaller reference starting
       place.

    *  We will need errors on the production implementation to be handled
       and reported with the 'phosphor-logging' API, which currently only
       has a C++ implementation.  I suspect we will also want DBus
       objects created for 'xyz.openbmc_project.Software.*' interfaces,
       which we have a C++ library for easy of programming.  See
       https://gerrit.openbmc-project.xyz/#/c/1291/ for DBus APIs.

    *  Would we enhance this to have code for 'ffs' parsing and TOC
       generation, mapping to a real file system, handling code-update
       paths, etc. for the design I alluded to above?  Or is the code
       for the protocol minimal enough that we would start with a new
       daemon at that point?  Is there any aspect of the protocol itself
       that should be abstracted into a library?

Depending on the direction we would like to go after considering these
points, I can make a repository for it.

> I'm happy to look after
> it like I do for btbridge, hopefully we could do code review for it
> through email.

All openbmc-owned repositories, including btbridge, are currently Gerrit
managed.  It has been this way since September/October time-frame.  I
thought we were clear in communicating this around then, but Jeremy and
Joel approved that direction to make them all a common process.  There
has been changes to the btbridge repository since then, so I apologize
if you were suppose to review them and did not; I believe we had someone
from the LTC review every change of significance.

> 
> Thanks,
> 
> Cyril

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