FRU device entityId and entityInstance

Patrick Venture venture at google.com
Thu Oct 17 16:57:17 AEDT 2019


Because there's no association between an entity-manager board and the
fru device entry, I added a new interface to the entity-manager
hardware profile:

"xyz.openbmc_project.Inventory.Decorator.FruDevice": {
    "Bus": "$bus",
    "Address": "$address"
}

I'm making the properties uppercase like they are with the FruDevice
interface so that they match  -- BUS == BUS, but they are different
types.  I haven't dug into the code, but interestingly these are
uint64_t while the FruDevice Interface's BUS is 32-bit.

This lets me, in intel-ipmi-oem go from a FruDevice entry to an
EntityManager board entry.  From there, I added another interface:

"xyz.openbmc_project.Inventory.Decorator.Ipmi": {
    "EntityId": "0x07",
    "EntityInstance": 1
}

If this interface is present, and those properties set, they are used
in intel-ipmi-oem.  I have a patch for this that has been tested and
works.  I haven't updated the schema yet, as I wanted to get a second
opinion on it.

The sensors also need the Ipmi Decorators, but I just added the
EntityId property to the "Exposes" entries that need it, and then it's
in the Configuration interface.  However, I haven't yet pushed that
into a sensor.  I see there's an association interface on a Sensor and
that points back to the parent board, but it isn't immediately clear
to me how to then travel to the sensor from there -- by first thought
was path swapping, but that won't work in cases like tmp441 where one
sensor configuration feeds two sensors.  Anyways, I was thinking, what
if the Sensor creation added another interface for decoration (if
configured), so that intel-ipmi-oem can get the entityId and so on by
just grabbing the sensor object -- it'd be yet another decoration
interface?

Patrick


More information about the openbmc mailing list