In-Band Firmware Update

[Patrick Venture]

We've been working on another interface lately that allows arbitrary
BLOB read and write over IPMI.  We're using it to talk to a driver on
a future software stack that's in the works.  It's a generic approach
to reading and writing bytes that could be tailored to any purpose.
One simply implements a handler in the interface.  It was suggested
that instead of sending the current in-band code upstream (albeit
rewritten for better testing) that I instead send this upstream and
then write the update mechanism into that interface.

The interface defines some primitives:
- BmcBlobGetCount: returns the number of blobs known presently
- BmcBlobEnumerate: returns the blob's name for an index into the
count (index 0 might return "/tmp/bmc-image" or something)
- BmcBlobOpen: opens the blob and returns a session for future actions
- BmcBlobRead: returns bytes
- BmcBlobWrite: writes bytes
- BmcBlocCommit: any action the handler wants that basically means, do thing.
- BmcBlobClose: closes the file
- BmcBlobDelete: deletes the blob, not always possible.
- BmcBlobStat: returns blob metadata
- BmcBlobSessionStat: returns metadata specific to the session

It doesn't immediately define actions such as "abort", however, "close
without commit" might be equivalent.  It also wasn't designed to
support OOB data, so it doesn't have a native packet that indicates
there are bytes for Write() but they live elsewhere, such as in a P2A
64-KiB block or an LPC memory map region.

I could likely find a way to easily handle those cases, possibly by
passing information into the Open command, and reading back from the
Stat() command.  Open takes a path to open, and it asks each handler
if they recognize the path, so one could have
"/tmp/bmc-image/p2a/{addr}" or something similar as an easy method to
configure that session.  OR "/tmp/..tgz" to use the UBI handler...

I've only pushed ~14 patches for the upstream OEM IPMI handler, and I
could port those to route through the blob interface rather
straightforwardly since it's nearly a 1:1 match.

The BMC IPMI Blobs source was written by me following TDD as closely
as possible.  The design has been under review for its use case for a
while, and is stable.

Regardless if we want to use it for this, I'd also be willing to
upstream our ipmi-blobs handler infrastructure.  It has presently one
limitation, and that is that it doesn't support run-time loading of
handlers, how ipmid supports finding IPMI libraries.  It is fully
contained with the handlers, and they're enabled by configuration
flags in the build.  This limitation could be removed if desired.

Patrick


On Mon, Aug 6, 2018 at 9:51 AM, Patrick Venture <venture at google.com> wrote:
> In an effort to do the OEM IPMI firmware update as full open source
> and to enable testing more thoroughly, I'm writing it anew and staging
> the patches upstream.
> https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-ipmi-flash/+/11772/
> is the current top of the stack of patches, but that'll change a bit
> this week as I implement more of the design.
>
> If you're very interested, and not on the patches, please let me know
> and I will add you to future ones.  That said, other than next week,
> when I'll be out-of-office, I'm hoping to keep the patches going in a
> brisk pace, so rapid feedback is appreciated.  Once the block-transfer
> interface portion is finished, I'll push up the host-side tool (which
> I also get to write anew).
>
> Patrick
>
> On Fri, Jul 27, 2018 at 12:01 PM, Patrick Venture <venture at google.com> wrote:
>> Sorry, I haven't been on this email label recently -- accidentally fell behind.
>>
>> In parallel to these efforts, I've started upstreaming a design:
>> https://gerrit.openbmc-project.xyz/11588 -- feel free to make
>> comments.  I'm going to implement the design (it's already
>> implemented, but now I'm expanding it to address incoming comments).
>>
>> Patrick
>>
>> On Tue, Jul 24, 2018 at 1:38 PM, Matt Spinler
>> <mspinler at linux.vnet.ibm.com> wrote:
>>> On 2018-07-23 19:13, Sai Dasari wrote:
>>>
>>>> Any thoughts on reusing/leveraging the PICMG's hpm spec @
>>>> https://www.picmg.org/openstandards/hardware-platform-management/ .
>>>> One of the benefit would be the standard 'ipmitool' has native support
>>>> for the update and changes are limited to BMC f/w.
>>>> On a downside, the firmware binary has to be repackaged as .hpm format
>>>> for this protocol to do some preparation steps as it support multiple
>>>> f/w components in a single package.
>>>
>>>
>>> This was brought up a few months ago and decided against:
>>> https://lists.ozlabs.org/pipermail/openbmc/2017-November/009938.html
>>>
>>> We are going to investigate using the DFU protocol, as that
>>> also has host side tools already available.
>>>
>>>
>>>>
>>>>     --Vernon
>>>
>>>