In-Band Firmware Update

[Bakshi, Sachit]

> 
> 
> On 7/23/18, 3:19 PM, "openbmc on behalf of Vernon Mauery" <openbmc-bounces+sdasari=fb.com at lists.ozlabs.org on behalf of vernon.mauery at linux.intel.com> wrote:
> 
>     On 23-Jul-2018 11:13 AM, Patrick Venture wrote:
>     >I've started to implement the host-tool outside of google3, and
>     >started splitting up the OEM handler that corresponds with it.
>     >However, firstly, I've submitted the design for the protocol for
>     >review, please let me know if you're interested and I'll add you to
>     >the review.  IIRC, there was at least one interested party outside of
>     >us.
>     
>     I am interested in coming up with a common (OpenBMC OEM level) set of 
>     Firmware NetFn commands that will allow all users of OpenBMC to be able 
>     to use common, open-source utilities to do firmware updates. If they are 
>     IPMI commands, this would include in-band (with KCS/BT for 
>     command/control and USB for transfer) or out-of-band (over RMCP+).

This sounds good. I'd advocate for some agreement around commands we
support. Our BMC updates components besides itself, and we support
multiple transport protocols. Therefore we have commands defined to
initiate an update, transfer the image, check the status, get errors,
start the update, etc.

I'm sure others have similar support in their implementations.

>     
>     Rather than use the OEM NetFn, for firmware updates, we should be using 
>     the Firmware NetFn.  The entire Firmware NetFn is considered to be OEM 
>     per the IPMI spec. I would propose that we simply provide a common 
>     implementation for OpenBMC (as a provider library, of course, so it 
>     could be replaced if a downstream OEM doesn't want it).

Agreed.

> Any thoughts on reusing/leveraging the PICMG's hpm spec @ https://www.picmg.org/openstandards/hardware-platform-management/ . 

Thanks for sharing this, I was not familiar with it. I'll look into it,
but I know we sign our images to secure our system, not sure if HPM
format will work for things like that, just something to consider.

> One of the benefit would be the standard 'ipmitool' has native support for the update and changes are limited to BMC f/w. 
> On a downside, the firmware binary has to be repackaged as .hpm format for this protocol to do some preparation steps as it support multiple f/w components in a single package. 
>     
>     --Vernon
>     
> 

Thanks,
Sachit