In-Band Firmware Update

[Andrew Jeffery]

> I'd be interested in separating out the "file like" nature from the 
> interface, and keep it as just a "block level" update, that may be a 
> file, or may be something else.
> 

A slight tangent, but I think it's worth talking about here:

On OpenPOWER systems we developed a control protocol for the
host to manipulate the LPC FW mapping. v3 of the protocol included
support for mapping "arbitrary" stuff into the FW space with a
command to list what devices were available. It seems very similar to
what Patrick has outlined, though operates at the block level as Ed
mused about above.

Typically this mechanism is used for the host to access its firmware
which - again on OpenPOWER designs - sits on a flash device owned
by the BMC.

The control protocol was run over the LPC mailbox available on
ASPEED BMCs. However, I am currently developing a PoC IPMI
replacement for the mailbox interface, and intended to use much
the same command-set and argument layout as we have with the
mailbox. As mentioned above it aligns pretty well with what Patrick
is proposing.

So our use-case has less of an update focus, but at the end of the
day if you can perform arbitrary writes it roughly amounts to the
same thing. Should we expand the scope to cover my use-case here?
I'm fine if the answer is "no", but with the similarities it seemed
necessary to bring up.

Cheers,

Andrew

PS: The bits -
Repository: https://github.com/openbmc/mboxbridge
Protocol documentation: https://github.com/openbmc/mboxbridge/blob/master/Documentation/mbox_protocol.md
Implementation notes: https://github.com/openbmc/mboxbridge/blob/master/Documentation/mboxd.md