In-Band Firmware Update

[Patrick Venture]

+Ed

On Mon, Aug 6, 2018 at 10:26 AM, Patrick Venture <venture at google.com> wrote:
> 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
>>>>
>>>>