HPM firmware update

[Vernon Mauery]

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