* Redfish implementation does not supply SoftwareId @ 2021-11-11 14:16 Richard Hughes 2021-11-17 19:36 ` Joseph Reynolds 2021-11-17 21:49 ` Ed Tanous 0 siblings, 2 replies; 6+ messages in thread From: Richard Hughes @ 2021-11-11 14:16 UTC (permalink / raw) To: openbmc 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. Sorry if all these are newbie questions, and I appreciate any pointers; I'm happy to send patches. Thanks. Richard. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redfish implementation does not supply SoftwareId 2021-11-11 14:16 Redfish implementation does not supply SoftwareId Richard Hughes @ 2021-11-17 19:36 ` Joseph Reynolds 2021-11-17 21:25 ` Richard Hughes 2021-11-17 21:49 ` Ed Tanous 1 sibling, 1 reply; 6+ messages in thread From: Joseph Reynolds @ 2021-11-17 19:36 UTC (permalink / raw) To: Richard Hughes, openbmc, Adriana Kobylak On 11/11/21 8:16 AM, Richard Hughes 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 :) Richard, Thanks for your email! I don't have any answers, and my intention for this email is to stir up some discussion. There was some previous work in this area described here: https://lists.ozlabs.org/pipermail/openbmc/2020-May/021573.html Where can we learn more about the interest in getting `fwupd` to run on the BMC? Links to chat room, email archive, etc? Background: OpenBMC's current documented [features][] for [firmware update][] is given here: [features]: https://github.com/openbmc/docs/blob/master/features.md [firmware update]: https://github.com/openbmc/docs/blob/master/architecture/code-update/code-update.md 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. And please note I am not familiar with [fwupd][]. [fwupd]: https://github.com/fwupd/fwupd > 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. Do I infer correctly that you got `fwupd` running on the BMC, for example having a working `fwupdmgr` command? > 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. Use cases: 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.) I understand the other systems (mentioned above) support updating the firmware for various individual host components. > 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. 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. [BMCWeb]: https://github.com/openbmc/bmcweb [SoftwareInventory schema]: https://github.com/openbmc/bmcweb/blob/master/static/redfish/v1/JsonSchemas/SoftwareInventory/SoftwareInventory.json [update service implementation]: https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/update_service.hpp 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 hope this helps. Joseph > > Sorry if all these are newbie questions, and I appreciate any > pointers; I'm happy to send patches. Thanks. > > Richard. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redfish implementation does not supply SoftwareId 2021-11-17 19:36 ` Joseph Reynolds @ 2021-11-17 21:25 ` Richard Hughes 2021-11-17 22:01 ` Ed Tanous 0 siblings, 1 reply; 6+ messages in thread From: Richard Hughes @ 2021-11-17 21:25 UTC (permalink / raw) To: Joseph Reynolds; +Cc: openbmc On Wed, 17 Nov 2021 at 19:36, Joseph Reynolds <jrey@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. > [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". 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. > 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. 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redfish implementation does not supply SoftwareId 2021-11-17 21:25 ` Richard Hughes @ 2021-11-17 22:01 ` Ed Tanous 2021-11-18 16:49 ` Richard Hughes 0 siblings, 1 reply; 6+ messages in thread From: Ed Tanous @ 2021-11-17 22:01 UTC (permalink / raw) To: hughsient; +Cc: openbmc, Joseph Reynolds On Wed, Nov 17, 2021 at 1:26 PM Richard Hughes <hughsient@gmail.com> wrote: > > On Wed, 17 Nov 2021 at 19:36, Joseph Reynolds <jrey@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redfish implementation does not supply SoftwareId 2021-11-17 22:01 ` Ed Tanous @ 2021-11-18 16:49 ` Richard Hughes 0 siblings, 0 replies; 6+ messages in thread From: Richard Hughes @ 2021-11-18 16:49 UTC (permalink / raw) To: Ed Tanous; +Cc: openbmc, Joseph Reynolds On Wed, 17 Nov 2021 at 21:50, Ed Tanous <ed@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Redfish implementation does not supply SoftwareId 2021-11-11 14:16 Redfish implementation does not supply SoftwareId Richard Hughes 2021-11-17 19:36 ` Joseph Reynolds @ 2021-11-17 21:49 ` Ed Tanous 1 sibling, 0 replies; 6+ messages in thread From: Ed Tanous @ 2021-11-17 21:49 UTC (permalink / raw) To: hughsient; +Cc: openbmc On Thu, Nov 11, 2021 at 6:18 AM Richard Hughes <hughsient@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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-11-18 16:50 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-11 14:16 Redfish implementation does not supply SoftwareId Richard Hughes 2021-11-17 19:36 ` Joseph Reynolds 2021-11-17 21:25 ` Richard Hughes 2021-11-17 22:01 ` Ed Tanous 2021-11-18 16:49 ` Richard Hughes 2021-11-17 21:49 ` Ed Tanous
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).