Redfish implementation does not supply SoftwareId

[Richard Hughes]

On Wed, 17 Nov 2021 at 21:50, Ed Tanous <ed at tanous.net> wrote:
> > 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
>
> This seems like a reasonable thing to do.  We probably want to
> namespace SoftwareId with OpenBMC-<machine name>

Yes, a good idea. Perhaps as a first step we could just hardcode
"OpenBMC-{machine-name}" in the SoftwareId? It gets a bit icky as
there appears to only be one component exposed on Redfish, when in
reality you probably want multiple components for things like ro,
kernel etc.

> If the above is something you're interested in tackling, you might
> consider hopping on discord in the bmcweb-and-redfish channel

I'm not sure how many cycles I have for this personally, but I'd be
amazed if that big vendor didn't want to get things moving. :)

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

It would seem that way indeed.

> In my dream world (where software is easy):

Dude, software is easy. It's the "making people work together" bit
that's hard :)

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

Yes, there are a huge number of configure options and we've just added
a few more for the next release to shave the binary distribution size
down. e.g. https://github.com/fwupd/fwupd/pull/3981 and a few more.
I'm not completely sure how to measure the effect of adding fwupd (and
the couple of additional deps) other than looking at the size of the
compressed image. I did two builds, and included a ton of protocols
into fwupd (and we could disable a lot more) and the rootfs went up
4MB so there's probably a lot more needed to trim down. If there's any
clever way to debug size increases (.e. a specific library increased
the size x MB) please let me know.

> 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

Ohh, we've already got a dbus interface. e.g.

gdbus call --system --dest org.freedesktop.fwupd --object-path /
--method org.freedesktop.fwupd.GetDevices

gives you the aasv array-of-dictionaries where all the data lives.

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

Yes, I think that makes total sense.

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

Sure, Ross has been awesome in getting all this upstream:
https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-bsp/fwupd

...in the next few days I'll do a new upstream release which includes
the patches listed there, and will also include the ~300kb reduction
in installed size. Perhaps give it a few days to pick up the new
release and the new options before trying it yourself. If you really
can't wait there's
https://people.freedesktop.org/~hughsient/temp/fwupd_1.7.1.bb

In the meantime, I (perhaps incorrectly) added it in the OpenBMC image using:

BBFILES += "../meta-openembedded/meta-oe/recipes-bsp/fwupd/*.bb"
CORE_IMAGE_EXTRA_INSTALL += "fwupd"
PACKAGECONFIG:remove = " vala gpg bluez polkit tests consolekit
firmware-packager manpages lzma plugin_altos plugin_dell
plugin_logitech_bulkcontroller plugin_modem_manager
plugin_parade_lspcon plugin_platform_integrity plugin_realtek_mst
plugin_synaptics_mst plugin_synaptics_rmi plugin_tpm"

We did ponder putting the .bb file into fwupd upstream and building it
as part of the CI, but building OpenBMC for each PR would really chew
through our CI minutes.

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

So let's do that. Could someone from the OpenBSD team who could sign
some "legal paperwork" apply for an LVFS account, and then we can set
up a robot user with a token that can automatically upload to the
LVFS. If nothing else it's some really good publicity, and lets me
keep the evb I have here up to date without a SPI programmer. See
https://lvfs.readthedocs.io/en/latest/apply.html and we can create a
test account and do some tests.

> and give OpenBMC users a "check for updates" button/api that could
> automatically invoke fwupd locally to check for updates.

Well, "fwupdmgr update" would basically do the right thing and ask the
user what needs to be updated. Of course, wiring it into OpenBMD would
be even more awesome, and there are tons of DBus APIs to make it all
magic.

Richard.