HPM firmware update

[Patrick Venture]

I hate to jump in, but we have a downstream implementation that lets
the platform specify the data channel but uses OEM IPMI commands to
control the transfer, including setting it up and triggering events
related to the update.  We do this to support multiple platforms, such
as uploading the image over PCI or LPC, and also allows us to stage
the file for cryptographic signature verification.

It's very similar to the latest email above.

On Thu, Nov 16, 2017 at 9:14 AM, Vernon Mauery
<vernon.mauery at linux.intel.com> wrote:
> On 16-Nov-2017 11:14 AM, Jeremy Kerr wrote:
>>
>> Hi James,
>>
>>> I’ve started looking at using the PICMG HPM specification that was
>>> recommended as the preferred API for performing firmware updates. This
>>> is not an open specification, and goes against the principles of the
>>> openbmc project.
>>
>>
>> Yes, that's very true. My previous experience is on the client-side of
>> HPM, which is implemented in ipmitool already.
>>
>>> The HPM specification must also be purchased from the PICMG standards
>>> organization, and contains patent liabilities. I think using HPM is a
>>> non-starter.
>>
>>
>> We could always request DMTF to make it more widely available. However,
>> unless that does change, I'd agree with you that we'd want to avoid
>> HPM.1.
>
>
> We don't have to go with HPM though. Our prior version of BMC used a fairly
> straight-forward model that is not too different than the HPM model, though
> it was developed in-house. It is pretty generic and could be used to
> transfer any payload over a variety of transports.
>
> If we can define our own 'standard' for OpenBMC firmware update methods,
> then we can implement that in ipmitool (like the dell oem commands or
> something).
>
> An overview goes something like this:
>
> 1) enter FW transfer mode
> 2) optionally send parameters (no-rollback, deferred reboot, debug, etc.)
> 3) <make a choice for either IPMI streaming or other transport>
>         a) for streaming
>                 i) write data blocks as IPMI FW command
>         b) for usb mass storage
>                 i) send plug-in IPMI command
>                 ii) host-side mount usb mass storage device, writes fw image
>                 iii) send plug-out IPMI command
>                 iv) send 'set uri command' (usb://...)
>         c) for network transport
>             i) send 'set uri command' (http(s)://..., tftp://..., ftp://...)
> 4) send transfer complete IPMI command
> 5) check status
>         status moves from download -> verify -> program -> ready
>         status can move to error from any state
> 6) once status moves to ready, firmware update is finished, ready to
> reboot.
> 7) send exit fw transfer mode IPMI command. This causes the BMC to
> reboot unless a deferred reboot has been selected.
>
>
> This mostly describes what the IPMI control does, which is pretty generic.
> The trickiest bit is offering multiple mechanisms for transport because IPMI
> is not the most efficient method to transport (unless you use 64kB payloads
> during the streaming phase. Even then, the TCP protocols are faster because
> of round-trip timing (only need an ack rather than a full trip through the
> IPMI command lookup and execution process.) USB is pretty fast, but not
> available for every system.
>
> --Vernon