From: Patrick Williams <patrick@stwcx.xyz>
To: Derek Mantey <derekma@microsoft.com>
Cc: "openbmc@lists.ozlabs.org" <openbmc@lists.ozlabs.org>
Subject: Re: Firmware update for auxiliary components
Date: Mon, 10 Jan 2022 08:42:21 -0600 [thread overview]
Message-ID: <YdxFza4Nd1us8BSy@heinlein> (raw)
In-Reply-To: <MW4PR21MB1922F2806870EBC2A7BDBAE9B04E9@MW4PR21MB1922.namprd21.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 2241 bytes --]
On Sat, Jan 08, 2022 at 12:44:17AM +0000, Derek Mantey 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. I'm trying to understand if there is a pattern I am missing, what other people are doing, and the possibility of changing the design.
>
> Right now it looks like the path forward would be to extend the "Version.interface.yaml" in the "phosphor-dbus-interfaces" repo (https://github.com/openbmc/phosphor-dbus-interfaces/blob/6f69ae5b33ee224358cb4c2061f4ad44c6b36d70/xyz/openbmc_project/Software/Version.interface.yaml) and add new VersionPurpose for each component. Then update the Image Manager, Item Updater, BMCWeb, etc to handle the new component types. This seems like this would be touching components up and down the stack just to extend. Is there some other pattern or way of extending the software manager to handle new components?
>
I think you want to see the documents changed by these two commits:
- https://github.com/openbmc/phosphor-dbus-interfaces/commit/f05e2050dbba80d130fa87875448cf48e97ce7f6
- https://github.com/openbmc/phosphor-dbus-interfaces/commit/ac7adcb5471eed5eaa9474a697dc1db254fa9187
These are intended to take care of exactly the usage pattern you are asking
about.
> When I look at the design, it seems like using an enum for the "VersionPurpose" is a little too restrictive. It doesn't allow for other components to be added, other than the "Other" enum entry. But there isn't an extended purpose string to allow specifying what that "Other" value actually means.
You are correct that the "VersionPurpose" { "BMC", "Host", "PSU", ... } is
rather limiting and with these changes it is effectively deprecated. I added
the following wording:
This property is deprecated in favor of Compatible strings and inventory
associations. The enumeration should not be expanded further.
> What are people doing for components like this?
Since this is a new change you won't see any code reflecting this yet though.
There is a team at HCL that is working on some implementations of this for
devices on the Yosemite-V2 system.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-01-10 14:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 0:44 Firmware update for auxiliary components Derek Mantey
2022-01-10 9:52 ` Richard Hughes
2022-01-10 14:42 ` Patrick Williams [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-01-11 1:08 Derek Mantey
2022-01-11 1:31 Derek Mantey
2022-01-11 8:55 ` Richard Hughes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YdxFza4Nd1us8BSy@heinlein \
--to=patrick@stwcx.xyz \
--cc=derekma@microsoft.com \
--cc=openbmc@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.