Redfish implementation does not supply SoftwareId

[Ed Tanous]

On Thu, Nov 11, 2021 at 6:18 AM Richard Hughes <hughsient at gmail.com> wrote:
>
> Hi all,
>
> My name is Richard Hughes and I'm the upstream maintainer of fwupd
> which is a linux program that allows flashing hardware. It's used by a
> few million people already and there's recently been a lot of interest
> about getting fwupd to run on the actual BMC chip, rather than on the
> host OS. That's not really what this email is about, but might explain
> the bigger picture. I'll come back to this in a few weeks time :)
>
> At the moment fwupd runs on the host OS and uses a plugin to
> communicate with various Redfish implementations, for example iDRAC
> for Dell or XClarity for Lenovo. Teddy Reed kindly donated (loaned?)
> me some hardware so I could test the fwupd plugin against the Redfish
> implementation of OpenBMC, more specifically git master on a
> evb-ast2500 board.
>
> With a small patch to fwupd (setting CURLOPT_SSL_VERIFYHOST=0) it
> seems to load and enumerate correctly, but doesn't add any devices.
> The reason I found was that the SoftwareId property is missing from
> the /redfish/v1/UpdateService/FirmwareInventory/7d021ade path. The
> SoftwareId is the "key" that maps the hardware to a specific firmware
> *stream*, so for instance it could be something like
> "USB\VID_17EF&PID_3083" for a peripheral or some other kind of
> vendor-specific string, e.g. "SAMSUNG MZVLB2T0HALB-000L7". The idea is
> that vendors then upload firmware to the LVFS website with a defined
> *stream* and updates get deployed onto matching hardware
> automatically. I'm not so sure that makes a huge amount of sense for
> the OpenBMC BMC image itself. Or maybe it does; getting new official
> OpenBMC images from the LVFS would be way cool, but I don't think we
> want to flash the entire MTD image. Anyway, I digress.
>
> I guess my question is if I could get a SoftwareId set for 7d021ade --
> e.g. "evb-ast2500" -- that at least allows the device to enumerate in
> fwupd and gives me something to test against. I guess my next question
> is how a OpenBMC distributor adds a new device into
> /redfish/v1/UpdateService/FirmwareInventory.Members -- and if there's
> a way to set SoftwareId for that new device too.

This seems like a reasonable thing to do.  We probably want to
namespace SoftwareId with OpenBMC-<machine name> just to make sure we
don't have the possibility of conflicting with the manufacturer
firmwares for these boards.  I'm not sure this information is
available on dbus today, so we'd need to get something that can
publish that to bmcweb, then get bmcweb to consume it to publish the
Redfish property.  Considering that we're very likely to be adding
updates of PSUs/drives/other components in the future, we'll likely
need a SoftwareId interface anyway.

If the above is something you're interested in tackling, you might
consider hopping on discord in the bmcweb-and-redfish channel to
hammer out the details if you're unsure;  These days it tends to get
faster responses to quick-turnaround support stuff.  If this isn't
something you're wanting to tackle, I think it's important enough that
I can add it to my plate, but my cup runneth over these days, so I'm
not sure when I can get there.

>
> Sorry if all these are newbie questions, and I appreciate any
> pointers; I'm happy to send patches. Thanks.
>
> Richard.