Firmware update for auxiliary components

[Derek Mantey]

Excellent, those changes look like they would solve most of the concerns I have.

Are you saying that the team at HCL is working on updating the ImageManager and ItemUpdater in the phosphor-bmc-code-mgmt repo?  Or is there a new implementation of the ImageManger and Item Updater?  Is there a contact for them so I can maybe get a preview of the changes?

Thanks,
	Derek

-----Original Message-----
From: openbmc <openbmc-bounces+derekma=microsoft.com at lists.ozlabs.org> On Behalf Of Patrick Williams
Sent: Monday, January 10, 2022 6:42 AM
To: Derek Mantey <derekma at microsoft.com>
Cc: openbmc at lists.ozlabs.org
Subject: [EXTERNAL] Re: Firmware update for auxiliary components

On Sat, Jan 08, 2022 at 12:44:17AM +0000, Derek Mantey wrote:
> 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?
> 

I think you want to see the documents changed by these two commits:
- https://github.com/openbmc/phosphor-dbus-interfaces/commit/f05e2050dbba80d130fa87875448cf48e97ce7f6
- https://github.com/openbmc/phosphor-dbus-interfaces/commit/ac7adcb5471eed5eaa9474a697dc1db254fa9187

These are intended to take care of exactly the usage pattern you are asking about.

> 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.  

You are correct that the "VersionPurpose" { "BMC", "Host", "PSU", ... } is rather limiting and with these changes it is effectively deprecated.  I added the following wording:

        This property is deprecated in favor of Compatible strings and inventory
        associations.  The enumeration should not be expanded further.

> What are people doing for components like this?  

Since this is a new change you won't see any code reflecting this yet though.
There is a team at HCL that is working on some implementations of this for devices on the Yosemite-V2 system.

--
Patrick Williams