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