Platform Inventory for redfish

Ed Tanous ed.tanous at intel.com
Sat Jun 15 04:16:48 AEST 2019


On 6/13/19 8:48 PM, Neeraj Ladkani wrote:
> HI All, 
> 
> How does we manage platform inventory like CPU, memory and PCIe devices since BMC may not always have presence pins for all components.  For IPMI , we have SDRs that can be programmed with correct SKU configurations. I am wondering what is solution for redfish (except BIOS sending inventory on USB ethernet using redfish).
This varies widely dependent on the architecture.  I can answer the
specifics for x86 servers and systems using entity-manager, but in
short, whatever exists in Dbus with the correct interfaces is populated
in Redfish.

> 
> Platform inventory includes 
> 
> 1. Number of host CPUs and type of CPUs

This is managed over a combination of PECI and SMBIOS/MDR tables.  PECI
can interrogate the CPU directly.  SMBIOS has more detailed information.

> 2. Number of memory and types of memory 
Same answer as CPU.  PECI allows us to get inventory counts, presence,
and temperatures.  SMBIOS allows us to get more detailed information on
types, timings, and inventory information.

> 3. IO expander cards 
This is done over Smbus.  On Wolf Pass, we use the FruDevice application
here, which scans all busses for valid FRUs.
https://github.com/openbmc/entity-manager/blob/master/src/FruDevice.cpp

> 4. SMBUS devices on PCI cards 

Same answer as IO expanders.  We check for a valid FRU, once we find it,
we check to see if it's a card we understand the topology of, by
instantiating an instance of a config file like this:
https://github.com/openbmc/entity-manager/blob/master/configurations/AXX1P100HSSI_AIC.json

Most cards key off the product name field in the board section, but
there are ways to key off of other fields as well.

At the end of the day the "probe" statement in entity manager is just a
dbus match, so if your platform has a different way to identifying a
"card is present" just make that data available on dbus, and add an
appropriate match to entity manager.

> 
> Thanks
> Neeraj
> 


More information about the openbmc mailing list