In-Band Firmware Update

Sai Dasari sdasari at fb.com
Tue Jul 24 10:13:59 AEST 2018



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+).
    
    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).
Any thoughts on reusing/leveraging the PICMG's hpm spec @ https://www.picmg.org/openstandards/hardware-platform-management/ . 
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
    



More information about the openbmc mailing list