Redfish implementation does not supply SoftwareId

[Ed Tanous]

On Wed, Nov 17, 2021 at 1:26 PM Richard Hughes <hughsient at gmail.com> wrote:
>
> On Wed, 17 Nov 2021 at 19:36, Joseph Reynolds <jrey at linux.ibm.com> wrote:
> > Where can we learn more about the interest in getting `fwupd` to run on
> > the BMC?  Links to chat room, email archive, etc?
>
> I don't have much public information I'm afraid. It's a very big
> company using OpenBMC that suggested this just a few weeks ago. I'm
> still not sure if it's a genius or insane idea to be honest. I
> initially thought the latter, but people cleverer than me say the
> former.

The line between insane and genius is more of a venn diagram rather
than a hard line.

>
> > [firmware update]:
> > https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md
>
> Super useful, thanks.
>
> > In this context, I understand you are interested in either (A) adding
> > support for a new fwupd method or (B) creating a new OpenBMC function to
> > update the firmware for various host components, or (C) both.  That
> > seems to me like a good fit with OpenBMC.
>
> I think the idea is that fwupd already knows how to install updates on
> an insane number of devices (~32 different update protocols supported,
> everything from DFU, to NVME, to UEFI capsule, Redfish, ATA, Logitech
> HID++, and even MTD) and those could be *used* by OpenBMC saying
> "install *this* on *that*" or even plumbing in OpenBMC to query fwupd
> to say "what updatable devices can you tell me about".

In my dream world (where software is easy):
1. fwupd would compile small enough to be put on every BMC, with
compile options to compile out the modes (and therefore binary size)
that doesn't make sense in a BMC context.
2. We'd write a dbus service (or extend fwupd), and make its data
available to dbus, such that we can hook it up directly to Redfish
FirmwareInventory schemas
3. When we start tackling in-system update use cases (power supplies,
CPLDs, BIOS, ect) fwupd would be the "default" go to, such that we
could share the bmc-specific and in-band update mechanisms in the same
application.  For example, updating a VR or NVMe drive should be
similar whether you're updating from a host-based OS, or from the BMC.

> For both
> actions there's a DBus interface or a JSON data dump available, either
> as an in-process query or just by running the daemon in the
> background. e.g. "fwupdmgr get-devices" is a thin wrapper around the
> GetUpdates DBus call that returns a 'aasv' array of dictionaries blob.
>
> > Do I infer correctly that you got `fwupd` running on the BMC, for
> > example having a working `fwupdmgr` command?
>
> Yes, actually more crazy than that, I got fwupd downloading and
> deploying updates from the LVFS... https://fwupd.org/
>
> See https://twitter.com/hughsient/status/1458922790690635780 for the
> obligatory screenshot. I think the idea is that vendors can use the
> same code in fwupd to deploy firmware onto COTS hardware without
> OpenBMC and onto custom hardware with OpenBMC. i.e. they teach one
> thing how to update the hardware and get to use it in both places.

Any chance you posted the recipe file somewhere for others to hack on
this along with you?

>
> > I understand OpenPOWER system firmware has two firmware packages which
> > are typically packaged together: (1) the BMC firmware image and (2) the
> > host firmware image.  The host image itself contains multiple parts but
> > the BMC does not handle them separately.  Given this, firmware updates
> > are monoliotic and are not done to individual components.  (But note my
> > understanding is limited.)
>
> In some cases the host UEFI firmware is behind some kind of MUX so
> that fwupd needs to know the GPIO to poke to make the MTD device
> appear to the BMC, and then the other GPIO to poke to return control
> back to the host. We have a plugin for that now. I didn't plan to
> update the BMC firmware using fwupd, but I guess if the BMC partitions
> are exposed as MTD devices there's nothing stopping you actually doing
> that. Intererstingly that would also mean that you could ship OpenBMC
> kernel or ro updates via the LVFS, for instance.

YES! ! ! ! !  In a perfect world, we could also have OpenBMC CI
automatically post to LVFS when we cut major/minor firmware revisions,
and give OpenBMC users a "check for updates" button/api that could
automatically invoke fwupd locally to check for updates.

>
> I saw some of the code deploying OpenPOWER firmware updates; I could
> totally see that being a fwupd plugin. Being somewhat biased of course
> :)
>
> > I don't understand enough background in this area.  OpenBMC's [BMCWeb][]
> > has pulled in the Redfish [SoftwareInventory schema][] and has an
> > [update service implementation][] but has not yet implemented the
> > `SoftwareId` property.  I think you want that.  But I don't know if that
> > will give you what you need.
>
> Yes, SoftwareId is what fwupd uses to say "use this firmware for that
> hardware" i.e. the firmware declares "I'll install on the SoftwareId
> that matches" and then other requirements (like tool+OS version, CHIDs
> etc) get layered on top.
>
> > One more thing I don't know... :-) Where is the right place (via
> > Yocto/bitbake recipes) to set the SoftwareId?  Somewhere around here?:
> > - Base OpenBMC support:
> > https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/images/obmc-phosphor-image.bb
> > - Customization for IBM machines:
> > https://github.com/openbmc/openbmc/blob/master/meta-ibm/recipes-phosphor/images/obmc-phosphor-image.bbappend
> > - In the class for the above:
> > https://github.com/openbmc/openbmc/blob/master/meta-phosphor/classes/image_types_phosphor.bbclass
>
> I'm not sure, to be honest. In my naive example where fwupd was
> running on the host and talking to the BMC using Redfish I just used
> the board name, eg. evb-ast2500 -- but obviously any vendor
> customization would want to override that. So maybe the answer to your
> question is "both"?
>
> In the case where fwupd is running on the BMC, I just used the MTD
> name (as you can see on the screenshot) and then you'd layer on some
> other requirement like "DMI must match this HWID"
>
> Many thanks for your help.
>
> Richard.