HPM firmware update

[Xo Wang]

On Thu, Nov 16, 2017 at 3:28 PM, Patrick Venture <venture at google.com> wrote:
> 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

To add to Patrick V's comment, our concern with IPMI-only transfers
was also with performance. We tested using a spec implementation (a
POWER8 sample machine running AMI BMC) as well as a toy version of
Brendan Higgins's proposed in-band transfer mechanism and both took
way too long to transfer images.

Vernon:
The USB mechanism sounds interesting. Could you elaborate on what the
BMC-side hardware and software looks like? I'm picturing one of the
BMC's USB PHYs hanging off of a host hub? Is it on the board or an
external cable? What's the backing storage for the mass storage gadget
(assuming you are using gadget)?

thanks
xo