In-band IPMI Update over IPMI Blobs

Patrick Venture venture at google.com
Tue Oct 9 10:23:44 AEDT 2018


On Mon, Oct 8, 2018 at 4:23 PM Patrick Venture <venture at google.com> wrote:
>
> On Mon, Oct 8, 2018 at 7:59 AM Sivas Srr <sivas.srr at in.ibm.com> wrote:
> >
> > Yes Patrick, Would like to have Wiki for each function.
> >
> > And would like to see following in that:
> >
> >
> > Use case scenarios
> > Requirements
> > Design
> > Test Cases - Unit / Functional
>
> So which wiki should I use?
>
> >
> >
> >
> >
> >
> > ----- Original message -----
> > From: Patrick Venture <venture at google.com>
> > To: Sivas Srr <sivas.srr at in.ibm.com>
> > Cc:
> > Subject: Re: In-band IPMI Update over IPMI Blobs
> > Date: Mon, Oct 8, 2018 7:55 PM
> >
> > On Sun, Oct 7, 2018 at 9:31 PM Sivas Srr <sivas.srr at in.ibm.com> wrote:
> > >
> > > Nice Patrick, As discussed in test work group meeting,
> > > Shall we have this feature with identified
> > > Use case Scenarios -> Requirement -> Design -> Test cases
> > >
> > > Because code update is the feature which all end users will do at least once.
> > > We can have a wiki as IPMI Inband code update and then populate design over there.
> > > Once design is baselined, we can move it under presentations / document of github.
> > >
> > > Please let know your thoughts.
> >
> > I don't understand your email.  Are you saying there should be a wiki
> > where the design lives while it's under review?  Or are the test cases
> > going under the wiki?  And isn't it all under github?
> >
> > >
> > >
> > >
> > > ----- Original message -----
> > > From: Patrick Venture <venture at google.com>
> > > Sent by: "openbmc" <openbmc-bounces+sivas.srr=in.ibm.com at lists.ozlabs.org>
> > > To: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> > > Cc:
> > > Subject: In-band IPMI Update over IPMI Blobs
> > > Date: Fri, Oct 5, 2018 8:16 PM
> > >
> > > For those who have been watching, we have been upstreaming how we
> > > currently handle in-band updates over IPMI/LPC/PCI to
> > > phosphor-ipmi-flash.  However, recently we also upstreamed a generic
> > > blob interface, phosphor-ipmi-blobs.  Until
> > > https://gerrit.openbmc-project.xyz/13620 it wasn't a suitable
> > > mechanism for the firmware update due to an inability to do a clean
> > > method mapping between the protocols.
> > >
> > > I've written up a proposal (downstream for now) to port the
> > > phosphor-ipmi-flash implementation into a blob handler that just goes
> > > through phosphor-ipmi-blobs.  The thinking is to have more things
> > > leverage the generic blob handler instead of having a fully separate
> > > OEM IPMI command set for everything (although phosphor-ipmi-flash goes
> > > over the Firmware Netfn).
> > >
> > > It's now a pretty trivial transformation, and once the design has some
> > > age downstream (1-2 days :D), then I'm going to send it here for
> > > review.
> > >
> > > Unless there are obvious objections.
> > >
> > > And as food for thought, other Blob protocol use-cases in the works:
> > > - mechanism for downloading core dumps and crash logs over IPMI (no
> > > network access)
> > > - mechanism for sending commands down for special hardware
> > > - mechanism for reading back configuration files for whitelisted debug
> > > - mechanism for randomly creating large files such that the flash
> > > fills up and the system never boots again.
> > >
> > > Patrick
> > >
> > >
> > >
> >
> >
> >
+OpenBMC Maillist


More information about the openbmc mailing list