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 at gmail.com> 
Sent: Monday, January 10, 2022 1:53 AM
To: Derek Mantey <derekma at microsoft.com>
Cc: openbmc at lists.ozlabs.org
Subject: Re: Firmware update for auxiliary components

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

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