Firmware update for auxiliary components

[Derek Mantey]

I am looking at enabling firmware updates for some auxiliary components in our servers that don't fall into the "BMC", "Host" or "PSU" bucket.  I'm trying to understand if there is a pattern I am missing, what other people are doing, and the possibility of changing the design.

Right now it looks like the path forward would be to extend the "Version.interface.yaml" in the "phosphor-dbus-interfaces" repo (https://github.com/openbmc/phosphor-dbus-interfaces/blob/6f69ae5b33ee224358cb4c2061f4ad44c6b36d70/xyz/openbmc_project/Software/Version.interface.yaml) and add new VersionPurpose for each component.  Then update the Image Manager, Item Updater, BMCWeb, etc to handle the new component types.  This seems like this would be touching components up and down the stack just to extend.  Is there some other pattern or way of extending the software manager to handle new components?

What are people doing for components like this?  Are they just updating them offline, e.g. you have command line tools to update the firmware for a component that are executed from a terminal/ssh session?  Are all of these components just included in the BMC image tar and then either based on the files in there update sub-components (similar to the image-bmc vs image-kernel + image-rofs)?  Are the components just included in the BMC image itself so it updates all components to the current on boot?  Something else?

When I look at the design, it seems like using an enum for the "VersionPurpose" is a little too restrictive.  It doesn't allow for other components to be added, other than the "Other" enum entry.  But there isn't an extended purpose string to allow specifying what that "Other" value actually means.  I couldn't find an easy way to search through the archive for design discussions around the phosphor software management, are there any reasons why this isn't a generic string?  Or important discussions around the current design that I can look through?

Thanks,
               Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220108/b906e32c/attachment.htm>