Leveraging and extending smbios-mdr

Leveraging and extending smbios-mdr

[Garrett, Mike (HPE Server Firmware)]

Hello Artem and all,

We are integrating smbios-mdr into our build.  Our SMBIOS info is downloaded and built as a file in the filesystem using proprietary means (our CHIF - channel interface).  Our hope is that we can simply point the smbios-mdr service at it and light up new information about the platform in dbus, Redfish, and the GUI.

However, I can't find much in the way of documentation about smbios-mdr.  I'm especially interested in how to extend the functionality past just CPUs and DIMMs into things like OEM records supplied by the BIOS.  Seems like the possibilities are:

1. Smbios-mdr has a generic dbus API and we write an independent service to query it for this info and publish to dbus
2. We create a generic extension mechanism for smbios-mdr for vendors to add OEM support and push to dbus directly from smbios-mdr (like w/ CPUs/DIMMs)
3. We fork smbios-mdr and extend it (not preferred).

I'd like to hear how best to leverage this recipe.

Thanks,

Mike

Re: Leveraging and extending smbios-mdr

[Artem Senichev]

On Tue, Jul 27, 2021 at 03:47:04PM +0000, Garrett, Mike (HPE Server Firmware) wrote:
> Hello Artem and all,
> 
> We are integrating smbios-mdr into our build.  Our SMBIOS info is downloaded and built as a file in the filesystem using proprietary means (our CHIF - channel interface).  Our hope is that we can simply point the smbios-mdr service at it and light up new information about the platform in dbus, Redfish, and the GUI.
> 
> However, I can't find much in the way of documentation about smbios-mdr.

If we are talking about the MDR2 project (https://github.com/Intel-BMC/mdrv2),
there is no documentation, but I don't think we really need it.
It is just a SMBIOS dump parser for some table types (CPU, DIMM).
The table format is fully documented in the SMBIOS specification:
https://www.dmtf.org/standards/smbios

> I'm especially interested in how to extend the functionality past just CPUs and DIMMs into things like OEM records supplied by the BIOS.

What about phosphor-inventory-manager?

> Seems like the possibilities are:
> 
> 1. Smbios-mdr has a generic dbus API and we write an independent service to query it for this info and publish to dbus
> 2. We create a generic extension mechanism for smbios-mdr for vendors to add OEM support and push to dbus directly from smbios-mdr (like w/ CPUs/DIMMs)
> 3. We fork smbios-mdr and extend it (not preferred).
> 
> I'd like to hear how best to leverage this recipe.

-- 
Regards,
Artem Senichev
Software Engineer, YADRO.

RE: Leveraging and extending smbios-mdr

[Garrett, Mike (HPE Server Firmware)]

Actually I'm talking about https://github.com/openbmc/smbios-mdr

It looks like this daemon tries to take in a data file at startup only (/var/lib/smbios/smbios/smbios2).  I'm wondering if there's a provision in the design to refresh the data file if appears or is updated later.  This file (at least in my experience) has to be created by an interaction with the BIOS during boot.  So it would be very reasonable for the BMC to boot before the host and there to be no file available yet.  Also, if something is updated on the host, a reboot may refresh this file.  So I think there are a couple of reasons why it would be good for this repo to react to data file updates.

If it doesn't exist and folks think it's a good idea, we can look at creating that capability, but I want to make sure it doesn't already exist.

Mike

> -----Original Message-----
> From: Artem Senichev <artemsen@gmail.com>
> Sent: Thursday, July 29, 2021 2:49 AM
> To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
> Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Pedrana, Nick
> <allan.nic.pedrana@hpe.com>
> Subject: Re: Leveraging and extending smbios-mdr
> 
> On Tue, Jul 27, 2021 at 03:47:04PM +0000, Garrett, Mike (HPE Server
> Firmware) wrote:
> > Hello Artem and all,
> >
> > We are integrating smbios-mdr into our build.  Our SMBIOS info is
> downloaded and built as a file in the filesystem using proprietary means (our
> CHIF - channel interface).  Our hope is that we can simply point the smbios-
> mdr service at it and light up new information about the platform in dbus,
> Redfish, and the GUI.
> >
> > However, I can't find much in the way of documentation about smbios-
> mdr.
> 
> If we are talking about the MDR2 project (https://github.com/Intel-
> BMC/mdrv2),
> there is no documentation, but I don't think we really need it.
> It is just a SMBIOS dump parser for some table types (CPU, DIMM).
> The table format is fully documented in the SMBIOS specification:
> https://www.dmtf.org/standards/smbios
> !NpxR!xpRhPV3JWN6U7DS7nROiFT5h3CNwyuFM9FLOZhUK0yNczSR8w5MX7
> iq1WAqwQuc$
> 
> > I'm especially interested in how to extend the functionality past just CPUs
> and DIMMs into things like OEM records supplied by the BIOS.
> 
> What about phosphor-inventory-manager?
> 
> > Seems like the possibilities are:
> >
> > 1. Smbios-mdr has a generic dbus API and we write an independent
> > service to query it for this info and publish to dbus 2. We create a
> > generic extension mechanism for smbios-mdr for vendors to add OEM
> support and push to dbus directly from smbios-mdr (like w/ CPUs/DIMMs) 3.
> We fork smbios-mdr and extend it (not preferred).
> >
> > I'd like to hear how best to leverage this recipe.
> 
> --
> Regards,
> Artem Senichev
> Software Engineer, YADRO.

Re: Leveraging and extending smbios-mdr

[Andrei Kartashev]

You can retrigger read via dbus, using
xyz.openbmc_project.Smbios.MDR_V2->.AgentSynchronizeData call to
smbios-mdrv2.

See example here:
https://github.com/openbmc/intel-ipmi-oem/blob/master/src/smbiosmdrv2handler.cpp#L1240


On Tue, 2021-08-17 at 21:29 +0000, Garrett, Mike (HPE Server Firmware)
wrote:
> Actually I'm talking about https://github.com/openbmc/smbios-mdr
> 
> It looks like this daemon tries to take in a data file at startup only
> (/var/lib/smbios/smbios/smbios2).  I'm wondering if there's a provision
> in the design to refresh the data file if appears or is updated later. 
> This file (at least in my experience) has to be created by an
> interaction with the BIOS during boot.  So it would be very reasonable
> for the BMC to boot before the host and there to be no file available
> yet.  Also, if something is updated on the host, a reboot may refresh
> this file.  So I think there are a couple of reasons why it would be
> good for this repo to react to data file updates.
> 
> If it doesn't exist and folks think it's a good idea, we can look at
> creating that capability, but I want to make sure it doesn't already
> exist.
> 
> Mike
> 
> > -----Original Message-----
> > From: Artem Senichev <artemsen@gmail.com>
> > Sent: Thursday, July 29, 2021 2:49 AM
> > To: Garrett, Mike (HPE Server Firmware) <mike.garrett@hpe.com>
> > Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>; Pedrana, Nick
> > <allan.nic.pedrana@hpe.com>
> > Subject: Re: Leveraging and extending smbios-mdr
> > 
> > On Tue, Jul 27, 2021 at 03:47:04PM +0000, Garrett, Mike (HPE Server
> > Firmware) wrote:
> > > Hello Artem and all,
> > > 
> > > We are integrating smbios-mdr into our build.  Our SMBIOS info is
> > downloaded and built as a file in the filesystem using proprietary
> > means (our
> > CHIF - channel interface).  Our hope is that we can simply point the
> > smbios-
> > mdr service at it and light up new information about the platform in
> > dbus,
> > Redfish, and the GUI.
> > > 
> > > However, I can't find much in the way of documentation about
> > > smbios-
> > mdr.
> > 
> > If we are talking about the MDR2 project (https://github.com/Intel-
> > BMC/mdrv2),
> > there is no documentation, but I don't think we really need it.
> > It is just a SMBIOS dump parser for some table types (CPU, DIMM).
> > The table format is fully documented in the SMBIOS specification:
> > https://www.dmtf.org/standards/smbios
> > !NpxR!xpRhPV3JWN6U7DS7nROiFT5h3CNwyuFM9FLOZhUK0yNczSR8w5MX7
> > iq1WAqwQuc$
> > 
> > > I'm especially interested in how to extend the functionality past
> > > just CPUs
> > and DIMMs into things like OEM records supplied by the BIOS.
> > 
> > What about phosphor-inventory-manager?
> > 
> > > Seems like the possibilities are:
> > > 
> > > 1. Smbios-mdr has a generic dbus API and we write an independent
> > > service to query it for this info and publish to dbus 2. We create
> > > a
> > > generic extension mechanism for smbios-mdr for vendors to add OEM
> > support and push to dbus directly from smbios-mdr (like w/
> > CPUs/DIMMs) 3.
> > We fork smbios-mdr and extend it (not preferred).
> > > 
> > > I'd like to hear how best to leverage this recipe.
> > 
> > --
> > Regards,
> > Artem Senichev
> > Software Engineer, YADRO.

-- 
Best regards,
Andrei Kartashev