HPM firmware update

[Vernon Mauery]

On 17-Nov-2017 02:02 PM, Xo Wang wrote:
...
>>>
>>> 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)?

Our current implementation uses a proprietary, single-use USB stack that 
we are planning on replacing with a USB-UCD + USB gadget driver. But it 
works about the same way. When the host makes a request for the USB 
device, it creates a tmpfs-backed file, formats it with FAT, and 'plugs' 
in to begin enumeration. The hardware does have a direct route to the 
host USB, which allows us to reach pretty good transfer rates over 
USB2.0. In my ideal world, using gadget, we could offer this USB mass 
storage device as well as an in-band USB ethernet device that could 
provide another hi-speed transport to the BMC.

--Vernon