IPMI implementation of Get Device ID command
tomjose at linux.vnet.ibm.com
Mon Aug 24 21:57:55 AEST 2020
Thanks for the response on this. Every company seems to have a different
version scheme and the parsing might not fit into upstream
implementation of the Get Device ID command.
My proposal is to add major and minor version to the dev_id.json and
this can be populated in the meta-xxx layer (something like this
If the format of the VERSION_ID does not match the master tag format,
then major and minor version will be picked from the dev_id.json. With
this approach every company can share the upstream implementation of the
On 15-08-2020 04:41, Mauery, Vernon wrote:
> On 14-Aug-2020 11:04 PM, TOM JOSEPH wrote:
>> We have an implementation of this command
>> . The current version of the code derives the major and minor
>> firmware revision from the VERSION_ID field, and the auxiliary
>> firmware revision is picked from dev_id.json. The auxiliary firmware
>> revision is populated at build time
>> The implementation of the code is obsolete, as it was based on an
>> earlier format. The current format of VERSION_ID for example is,
>> 2.9.0-dev-609-g56f86d23c. There is already a WIP patch to fix this
>> for the master tag format
>> IBM tagging format is different from the tag format of master builds.
>> One choice is to have the major and minor version added to the
>> dev_id.json and if the format of VERSION_ID does not match the master
>> tag format, pick from the json.
>> How are other companies converting their arbitrary tag formats to
>> IPMI firmware revision fields? Does every company maintain their own
>> downstream implementation of this command?
> We have a two-hash version scheme (one for openbmc, the other for the
> downstream meta-intel layer) that looks something like
> wht-0.2-3-gab3500-38384ac. We override the Get Device ID command
> to expose part of both of those hashes in the aux bytes. But to get
> the full version string, we use redfish.
>> Is a common code possible for converting arbitrary tag formats to
>> IPMI firmware revision fields?
> Not that I am aware of. I think this leads to lots of string parsing.
More information about the openbmc