Fwd: libflash questions mostly relating to P9 bringup

[Brendan Higgins]

---------- Forwarded message ---------
From: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Date: Thu, Oct 20, 2016 at 2:06 PM
Subject: Re: libflash questions mostly relating to P9 bringup
To: Brendan Higgins <brendanhiggins at google.com>, Cyril Bur <
cyrilbur at gmail.com>, Joel Stanley <joel at jms.id.au>, Xo Wang <xow at google.com>,
Abhishek Pandit <abhishekpandit at google.com>


On Thu, 2016-10-20 at 11:41 -0700, Brendan Higgins wrote:
> > The main one is probably speed. IPMI is fairly slow and we don't
> > really want
> >  to transport the actual flash data over it.
>
> I do not dispute that; I think we accept that as a consequence,
> again, as LPC does not exist on many platforms.

Ok.

> I only mentioned the most simple method that we wanted to
> implement, RawFlashRequest, which would provide direct flash access,
> but we were interested in supporting other methods as well, so if you
> would be willing to support other access methods, I see this as being
> totally compatible with what we want to do.

Yes, it would work fine to support multiple methods.

> That sounds reasonable to me. As long as we have a common way to do
> flash access on all systems we are happy; if we happen to support
> some other faster access methods (as long as they share a common
> API), I think that would be even better :-)

So the API ... The plan for us is to plumb this behind the existing
OPAL flash APIs which are themselves plumbed into Linux MTD layer.

It's fairly easy inside OPAL to implement different backends for a
given API.

> Yep, that is what we are trying to address with our OEM/Group
> extension; it provides an interface that sends arbitrary data over
> IPMI. Admittedly, it will make all other IPMI traffic slower;
> however, this is unavoidable on platforms that only have one hardware
> interface between the BMC and the host CPU.

Right.

> Also true, but still unavoidable if we only have a single hardware
> interface.
>
> Sounds to me like we do not have any incompatible goals; although it
> is true that on our side we are more concerned about a common
> implementation that will work on any platform and you guys seem to be
> more concerned about performance, I think that just means that we
> should provide both transport layers: IPMI and LPC mailbox. I imagine
> that a good deal of the actual flash access logic will be the same
> for the both of us.

Yup, I think both work. At some point we might want to look at the
implementation details a bit more closely, it would be good to merge
the Zaius support into the main OPAL repo sooner rather than later.

We are still working on the implementation of our mbox based flash
protocol, but once we are done it should be easy for you guys to pick
it up as well if you wish to for your Aspeed based machine(s).

Cheers,
Ben.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161025/958e508f/attachment-0001.html>