Firmware update for auxiliary components

Firmware update for auxiliary components

[Derek Mantey]

[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4296 bytes --]

Re: Firmware update for auxiliary components

[Richard Hughes]

On Sat, 8 Jan 2022 at 00:45, Derek Mantey <derekma@microsoft.com> 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.

If it helps, I've had quite a lot of success getting fwupd running on
OpenBMC; there are several dozen firmware update protocols supported
there.

> Or important discussions around the current design that I can look through?

What I don't know is how/if fwupd should integrate with OpenBMC;
presumably we want to expose the fwupd devices through the internal
D-Bus and Redfish APIs.

Richard.

Re: Firmware update for auxiliary components

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Firmware update for auxiliary components

[Richard Hughes]

On Tue, 11 Jan 2022 at 01:31, Derek Mantey <derekma@microsoft.com> wrote:
> I tried to pull the changes in but ran into some build issues.

Ohh? If you share them I might be able to help. I know fwpud is quite
aggressive with some of it's deps, but they should be all up to date
in oe-meta.

> could you tell me a little more about the interfaces that the fwupd uses?

No problem; but I suspect the answer is "all of them" :)

>  Is it searching the device tree for devices that it can update?  Is it searching the busses directly?  Or is there a way to give hints for devices to update?

It does all of those things. In general, a "plugin" in fwupd just knows how to:

 * enumerate (discover) the device, e.g. looking at the ESRT, looking
at files in /sys, using udev to find a device, or claiming an
interface on a USB device
 * Install a blob of firmware on that device node
 * (optionally) switch the device into, and out-of bootloader mode

There's quite a lot more, but it's all basically optional -- there's a
little tutorial available here:
https://fwupd.github.io/libfwupdplugin/tutorial.html

In reality, the best way to see how it all works is to look at the
code, for instance,
https://github.com/fwupd/fwupd/blob/main/plugins/nvme/fu-nvme-device.c
is <500 lines on how to properly enumerate and update a NVMe drive.

> For example, we have a CPLD on our board (see the Open Compute DC-SCM spec).  We don't currently have that listed in our device tree as it is just sitting on a generic SPI bus.

The best way is to make it discoverable, as you don't need to add a
quirk file for each of the system boards that you want to support,
e.g. put it in an ACPI table or DT somewhere. If that's not possible,
you can add a "quirk" to fwupd to say "for this hardware do this",
e.g. https://github.com/fwupd/fwupd/blob/main/plugins/superio/superio.quirk#L55
although this isn't awesome as you have to update fwupd every time you
have a new board to support. Ideally you could ask an embedded
controller somewhere "what CPLDs are connected" and get back all the
data you need.

Richard

Re: Firmware update for auxiliary components

[Derek Mantey]

Thanks, when I was looking through some of the history for this list I saw some of your emails about the fwupd.  I tried to pull the changes in but ran into some build issues.  I am guessing we are on the "old" side of a breaking change to Yacto/BitBake and we would need to upgrade first before we could get things build.

I know I should have read up more, but since you replied suggesting it, could you tell me a little more about the interfaces that the fwupd uses?  Is it searching the device tree for devices that it can update?  Is it searching the busses directly?  Or is there a way to give hints for devices to update?

For example, we have a CPLD on our board (see the Open Compute DC-SCM spec).  We don't currently have that listed in our device tree as it is just sitting on a generic SPI bus.  Would the fwupd tool be able to update it and how would we need to specify how it should communicate with it?

Thanks,
	Derek

-----Original Message-----
From: Richard Hughes <hughsient@gmail.com> 
Sent: Monday, January 10, 2022 1:53 AM
To: Derek Mantey <derekma@microsoft.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: Firmware update for auxiliary components

[You don't often get email from hughsient@gmail.com. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.]

On Sat, 8 Jan 2022 at 00:45, Derek Mantey <derekma@microsoft.com> 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.

If it helps, I've had quite a lot of success getting fwupd running on OpenBMC; there are several dozen firmware update protocols supported there.

> Or important discussions around the current design that I can look through?

What I don't know is how/if fwupd should integrate with OpenBMC; presumably we want to expose the fwupd devices through the internal D-Bus and Redfish APIs.

Richard.

Re: 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@lists.ozlabs.org> On Behalf Of Patrick Williams
Sent: Monday, January 10, 2022 6:42 AM
To: Derek Mantey <derekma@microsoft.com>
Cc: openbmc@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