* OpenBMC - FRU inventory with Entity Manager
@ 2020-08-27 0:47 Jiandi An
2020-08-27 4:53 ` Andrei Kartashev
2020-08-27 5:32 ` Vijay Khemka
0 siblings, 2 replies; 12+ messages in thread
From: Jiandi An @ 2020-08-27 0:47 UTC (permalink / raw)
To: openbmc
Hi,
Have a question related how IPMI fru command is handled when having FRU inventory handled by Entity Manager.
I've enabled Entity Manager and through the config JSONs, got the entity manager to probe FRU config information off of EEPROM and getting the FruDevice inventory D-Bus object added.
For example I I have /xyz/openbmc_project/FruDevice/My_FRU show up under xyz.openbmc_project.FruDevice. And I can introspect it. But I can't get that FRU to be handled and displayed when I ran "ipmitool fru"
root@bmc:~# busctl tree --no-pager xyz.openbmc_project.FruDevice
└/xyz
└/xyz/openbmc_project
└/xyz/openbmc_project/FruDevice
└/xyz/openbmc_project/FruDevice/My_FRU
root@bmc:~# busctl introspect --no-pager xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.FruDevice interface - - -
.ADDRESS property u 84 emits-change
.BOARD_INFO_AM1 property s "\001" emits-change
.BOARD_LANGUAGE_CODE property s "25" emits-change
.BOARD_MANUFACTURER property s "XYZ COMPANY" emits-change
.BOARD_MANUFACTURE_DATE property s "2020-01-01 - 12:00:00" emits-change
.BOARD_PART_NUMBER property s "123.ABCD.1234" emits-change
.BOARD_PRODUCT_NAME property s "My FRU" emits-change
.BOARD_SERIAL_NUMBER property s "123ABC" emits-change
.BUS property u 2 emits-change
.CHASSIS_PART_NUMBER property s "123-12345-1234-000" emits-change
.CHASSIS_SERIAL_NUMBER property s "1234567890123" emits-change
.CHASSIS_TYPE property s "23" emits-change
.Common_Format_Version property s "1" emits-change
.PRODUCT_ASSET_TAG property s "0000000000000" emits-change
.PRODUCT_FRU_VERSION_ID property s "v0.5" emits-change
.PRODUCT_LANGUAGE_CODE property s "25" emits-change
.PRODUCT_MANUFACTURER property s "XYZ COMPANY" emits-change
.PRODUCT_PART_NUMBER property s "123-12345-1234-000" emits-change
.PRODUCT_PRODUCT_NAME property s "TBD" emits-change
.PRODUCT_SERIAL_NUMBER property s "1234567890123" emits-change
.PRODUCT_VERSION property s "v1.0" emits-change
When I ran the standard IPMI fru command, it always defaults to getting Builtin FRU Device, and dimm0, dimm1, cpu0, cpu1 FRUs and of course they are not there so it fails. Is there anything that I'm missing to get the standard IPMI fru command to map to the DBUS object xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU under Entity Manger?
root@dev-system:~# ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Unspecified error)
FRU Device Description : dimm0 (ID 1)
Device not present (Unspecified error)
FRU Device Description : dimm1 (ID 2)
Device not present (Unspecified error)
FRU Device Description : cpu0 (ID 3)
Device not present (Unspecified error)
FRU Device Description : cpu1 (ID 4)
Device not present (Unspecified error)
Thanks
- Jiandi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-27 0:47 OpenBMC - FRU inventory with Entity Manager Jiandi An
@ 2020-08-27 4:53 ` Andrei Kartashev
2020-08-27 5:32 ` Vijay Khemka
1 sibling, 0 replies; 12+ messages in thread
From: Andrei Kartashev @ 2020-08-27 4:53 UTC (permalink / raw)
To: openbmc
Hi,
That is actually depend on which platform you are. E.g. we are derived
from intel-platforms and there are "intel-ipmi-oem" package which
handles ipmi fru commands. This case just everything found by FruDevice
would appear in "ipmitool fru list".
Otherwise I believe you need to add your device found by FruDevice to
inventory which can be done with EntityManager probe rule. Note that
FruDevice and EntityManager are different application and they are not
connected by default. Please check "xyz.openbmc_project.FruDevice"
~# busctl tree --no-pager xyz.openbmc_project.FruDevice
`-/xyz
`-/xyz/openbmc_project
`-/xyz/openbmc_project/FruDevice
|-/xyz/openbmc_project/FruDevice/DPS_2000AB_2_E
`-/xyz/openbmc_project/FruDevice/Motherboard
~# busctl tree --no-pager xyz.openbmc_project.EntityManager
`-/xyz
`-/xyz/openbmc_project
|-/xyz/openbmc_project/EntityManager
`-/xyz/openbmc_project/inventory
`-/xyz/openbmc_project/inventory/system
|-/xyz/openbmc_project/inventory/system/board
| |-/xyz/openbmc_project/inventory/system/board/PCIE_Device_3
| |-/xyz/openbmc_project/inventory/system/board/PCIE_Device_4
| |-/xyz/openbmc_project/inventory/system/board/PCIE_Device_5
| `-/xyz/openbmc_project/inventory/system/board/Baseboard
[.....]
On Thu, 2020-08-27 at 00:47 +0000, Jiandi An wrote:
> Hi,
>
> Have a question related how IPMI fru command is handled when having
> FRU inventory handled by Entity Manager.
> I've enabled Entity Manager and through the config JSONs, got the
> entity manager to probe FRU config information off of EEPROM and
> getting the FruDevice inventory D-Bus object added.
> For example I I have /xyz/openbmc_project/FruDevice/My_FRU show up
> under xyz.openbmc_project.FruDevice. And I can introspect it. But I
> can't get that FRU to be handled and displayed when I ran "ipmitool
> fru"
>
> root@bmc:~# busctl tree --no-pager xyz.openbmc_project.FruDevice
> └/xyz
> └/xyz/openbmc_project
> └/xyz/openbmc_project/FruDevice
> └/xyz/openbmc_project/FruDevice/My_FRU
>
> root@bmc:~# busctl introspect --no-pager
> xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU
> NAME TYPE
> SIGNATURE RESULT/VALUE FLAGS
> org.freedesktop.DBus.Introspectable interface -
> - -
> .Introspect method
> - s
> -
> org.freedesktop.DBus.Peer interface -
> -
> -
> .GetMachineId method
> - s
> -
> .Ping met
> hod - -
> -
> org.freedesktop.DBus.Properties interface -
> - -
> .Get met
> hod ss v
> -
> .GetAll meth
> od s a{sv}
> -
> .Set me
> thod ssv -
> -
> .PropertiesChanged signal
> sa{sv}as -
> -
> xyz.openbmc_project.FruDevice interface -
> - -
> .ADDRESS property
> u 84
> emits-change
> .BOARD_INFO_AM1 property
> s "\001" e
> mits-change
> .BOARD_LANGUAGE_CODE property s
> "25" emits-
> change
> .BOARD_MANUFACTURER property s
> "XYZ COMPANY" emits-change
> .BOARD_MANUFACTURE_DATE property s
> "2020-01-01 - 12:00:00" emits-change
> .BOARD_PART_NUMBER property s
> "123.ABCD.1234" emits-change
> .BOARD_PRODUCT_NAME property s
> "My FRU" emits-change
> .BOARD_SERIAL_NUMBER property s
> "123ABC" emits-
> change
> .BUS pro
> perty u 2
> emits-change
> .CHASSIS_PART_NUMBER property s
> "123-12345-1234-000" emits-change
> .CHASSIS_SERIAL_NUMBER property s
> "1234567890123" emits-change
> .CHASSIS_TYPE property
> s "23"
> emits-change
> .Common_Format_Version property s
> "1" em
> its-change
> .PRODUCT_ASSET_TAG property
> s "0000000000000" emits-change
> .PRODUCT_FRU_VERSION_ID property s
> "v0.5" emits-
> change
> .PRODUCT_LANGUAGE_CODE property s
> "25" emits-
> change
> .PRODUCT_MANUFACTURER property s
> "XYZ COMPANY" emits-change
> .PRODUCT_PART_NUMBER property s
> "123-12345-1234-000" emits-change
> .PRODUCT_PRODUCT_NAME property s
> "TBD" emits-
> change
> .PRODUCT_SERIAL_NUMBER property s
> "1234567890123" emits-change
> .PRODUCT_VERSION property
> s "v1.0"
> emits-change
>
> When I ran the standard IPMI fru command, it always defaults to
> getting Builtin FRU Device, and dimm0, dimm1, cpu0, cpu1 FRUs and of
> course they are not there so it fails. Is there anything that I'm
> missing to get the standard IPMI fru command to map to the DBUS
> object xyz.openbmc_project.FruDevice
> /xyz/openbmc_project/FruDevice/My_FRU under Entity Manger?
>
> root@dev-system:~# ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc
> -C 17 fru
> FRU Device Description : Builtin FRU Device (ID 0)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm0 (ID 1)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm1 (ID 2)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu0 (ID 3)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu1 (ID 4)
> Device not present (Unspecified error)
>
> Thanks
> - Jiandi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-27 0:47 OpenBMC - FRU inventory with Entity Manager Jiandi An
2020-08-27 4:53 ` Andrei Kartashev
@ 2020-08-27 5:32 ` Vijay Khemka
2020-08-27 5:43 ` Deepak Kodihalli
1 sibling, 1 reply; 12+ messages in thread
From: Vijay Khemka @ 2020-08-27 5:32 UTC (permalink / raw)
To: Jiandi An, openbmc
I don't think ipmi fru command is pointing to the right dbus object of FruDevice. We may have to fix or add this support in ipmid for standard fru command. Currently this command has been overridden by intel-ipmi-oem and fb-ipmi-oem for their respective target. If you add intel-ipmi-oem to your image then it should work.
Regards
-Vijay
On 8/26/20, 5:54 PM, "openbmc on behalf of Jiandi An" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jan@nvidia.com> wrote:
Hi,
Have a question related how IPMI fru command is handled when having FRU inventory handled by Entity Manager.
I've enabled Entity Manager and through the config JSONs, got the entity manager to probe FRU config information off of EEPROM and getting the FruDevice inventory D-Bus object added.
For example I I have /xyz/openbmc_project/FruDevice/My_FRU show up under xyz.openbmc_project.FruDevice. And I can introspect it. But I can't get that FRU to be handled and displayed when I ran "ipmitool fru"
root@bmc:~# busctl tree --no-pager xyz.openbmc_project.FruDevice
└/xyz
└/xyz/openbmc_project
└/xyz/openbmc_project/FruDevice
└/xyz/openbmc_project/FruDevice/My_FRU
root@bmc:~# busctl introspect --no-pager xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
xyz.openbmc_project.FruDevice interface - - -
.ADDRESS property u 84 emits-change
.BOARD_INFO_AM1 property s "\001" emits-change
.BOARD_LANGUAGE_CODE property s "25" emits-change
.BOARD_MANUFACTURER property s "XYZ COMPANY" emits-change
.BOARD_MANUFACTURE_DATE property s "2020-01-01 - 12:00:00" emits-change
.BOARD_PART_NUMBER property s "123.ABCD.1234" emits-change
.BOARD_PRODUCT_NAME property s "My FRU" emits-change
.BOARD_SERIAL_NUMBER property s "123ABC" emits-change
.BUS property u 2 emits-change
.CHASSIS_PART_NUMBER property s "123-12345-1234-000" emits-change
.CHASSIS_SERIAL_NUMBER property s "1234567890123" emits-change
.CHASSIS_TYPE property s "23" emits-change
.Common_Format_Version property s "1" emits-change
.PRODUCT_ASSET_TAG property s "0000000000000" emits-change
.PRODUCT_FRU_VERSION_ID property s "v0.5" emits-change
.PRODUCT_LANGUAGE_CODE property s "25" emits-change
.PRODUCT_MANUFACTURER property s "XYZ COMPANY" emits-change
.PRODUCT_PART_NUMBER property s "123-12345-1234-000" emits-change
.PRODUCT_PRODUCT_NAME property s "TBD" emits-change
.PRODUCT_SERIAL_NUMBER property s "1234567890123" emits-change
.PRODUCT_VERSION property s "v1.0" emits-change
When I ran the standard IPMI fru command, it always defaults to getting Builtin FRU Device, and dimm0, dimm1, cpu0, cpu1 FRUs and of course they are not there so it fails. Is there anything that I'm missing to get the standard IPMI fru command to map to the DBUS object xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU under Entity Manger?
root@dev-system:~# ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Unspecified error)
FRU Device Description : dimm0 (ID 1)
Device not present (Unspecified error)
FRU Device Description : dimm1 (ID 2)
Device not present (Unspecified error)
FRU Device Description : cpu0 (ID 3)
Device not present (Unspecified error)
FRU Device Description : cpu1 (ID 4)
Device not present (Unspecified error)
Thanks
- Jiandi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-27 5:32 ` Vijay Khemka
@ 2020-08-27 5:43 ` Deepak Kodihalli
2020-08-27 6:10 ` Andrei Kartashev
0 siblings, 1 reply; 12+ messages in thread
From: Deepak Kodihalli @ 2020-08-27 5:43 UTC (permalink / raw)
To: Vijay Khemka, Jiandi An, openbmc, Tom Joseph, vernon.mauery
On 27/08/20 11:02 am, Vijay Khemka wrote:
> I don't think ipmi fru command is pointing to the right dbus object of FruDevice. We may have to fix or add this support in ipmid for standard fru command. Currently this command has been overridden by intel-ipmi-oem and fb-ipmi-oem for their respective target. If you add intel-ipmi-oem to your image then it should work.
It seems like several ipmi-oem implementations (intel, fb and likely
several others) rely on the FruDevice to prepare IPMI FRU information,
so this code is likely getting duplicated across the ipmi-oem repos.
Should this be the other way around, i.e house the FruDevice based
implementation in phosphor-host-ipmid and the current
phosphor-host-ipmid implementation, which expects YAML config files,
should be in an ibm-ipmi-oem repo?
Regards,
Deepak
> Regards
> -Vijay
>
> On 8/26/20, 5:54 PM, "openbmc on behalf of Jiandi An" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of jan@nvidia.com> wrote:
>
> Hi,
>
> Have a question related how IPMI fru command is handled when having FRU inventory handled by Entity Manager.
> I've enabled Entity Manager and through the config JSONs, got the entity manager to probe FRU config information off of EEPROM and getting the FruDevice inventory D-Bus object added.
> For example I I have /xyz/openbmc_project/FruDevice/My_FRU show up under xyz.openbmc_project.FruDevice. And I can introspect it. But I can't get that FRU to be handled and displayed when I ran "ipmitool fru"
>
> root@bmc:~# busctl tree --no-pager xyz.openbmc_project.FruDevice
> └/xyz
> └/xyz/openbmc_project
> └/xyz/openbmc_project/FruDevice
> └/xyz/openbmc_project/FruDevice/My_FRU
>
> root@bmc:~# busctl introspect --no-pager xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU
> NAME TYPE SIGNATURE RESULT/VALUE FLAGS
> org.freedesktop.DBus.Introspectable interface - - -
> .Introspect method - s -
> org.freedesktop.DBus.Peer interface - - -
> .GetMachineId method - s -
> .Ping method - - -
> org.freedesktop.DBus.Properties interface - - -
> .Get method ss v -
> .GetAll method s a{sv} -
> .Set method ssv - -
> .PropertiesChanged signal sa{sv}as - -
> xyz.openbmc_project.FruDevice interface - - -
> .ADDRESS property u 84 emits-change
> .BOARD_INFO_AM1 property s "\001" emits-change
> .BOARD_LANGUAGE_CODE property s "25" emits-change
> .BOARD_MANUFACTURER property s "XYZ COMPANY" emits-change
> .BOARD_MANUFACTURE_DATE property s "2020-01-01 - 12:00:00" emits-change
> .BOARD_PART_NUMBER property s "123.ABCD.1234" emits-change
> .BOARD_PRODUCT_NAME property s "My FRU" emits-change
> .BOARD_SERIAL_NUMBER property s "123ABC" emits-change
> .BUS property u 2 emits-change
> .CHASSIS_PART_NUMBER property s "123-12345-1234-000" emits-change
> .CHASSIS_SERIAL_NUMBER property s "1234567890123" emits-change
> .CHASSIS_TYPE property s "23" emits-change
> .Common_Format_Version property s "1" emits-change
> .PRODUCT_ASSET_TAG property s "0000000000000" emits-change
> .PRODUCT_FRU_VERSION_ID property s "v0.5" emits-change
> .PRODUCT_LANGUAGE_CODE property s "25" emits-change
> .PRODUCT_MANUFACTURER property s "XYZ COMPANY" emits-change
> .PRODUCT_PART_NUMBER property s "123-12345-1234-000" emits-change
> .PRODUCT_PRODUCT_NAME property s "TBD" emits-change
> .PRODUCT_SERIAL_NUMBER property s "1234567890123" emits-change
> .PRODUCT_VERSION property s "v1.0" emits-change
>
> When I ran the standard IPMI fru command, it always defaults to getting Builtin FRU Device, and dimm0, dimm1, cpu0, cpu1 FRUs and of course they are not there so it fails. Is there anything that I'm missing to get the standard IPMI fru command to map to the DBUS object xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU under Entity Manger?
>
> root@dev-system:~# ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
> FRU Device Description : Builtin FRU Device (ID 0)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm0 (ID 1)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm1 (ID 2)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu0 (ID 3)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu1 (ID 4)
> Device not present (Unspecified error)
>
> Thanks
> - Jiandi
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-27 5:43 ` Deepak Kodihalli
@ 2020-08-27 6:10 ` Andrei Kartashev
2020-08-31 17:14 ` Ed Tanous
0 siblings, 1 reply; 12+ messages in thread
From: Andrei Kartashev @ 2020-08-27 6:10 UTC (permalink / raw)
To: Deepak Kodihalli, Vijay Khemka, Jiandi An, openbmc, Tom Joseph,
vernon.mauery
Since there is a plan to move to EM for inventory, I believe it is
really good idea to also have support for FruDevice in phosphor-host-
ipmid. Then we can have a common way on how to handle it.
Same for SDR BTW.
But there is other thing: there is catastrophically not enough
documentation for EntityManager/dbus-sensors. Looks like common way
just to adjust existing config and hope that it still will work.
<sorry, was all the day trying to get adcsensors work yesterday>
On Thu, 2020-08-27 at 11:13 +0530, Deepak Kodihalli wrote:
> On 27/08/20 11:02 am, Vijay Khemka wrote:
> > I don't think ipmi fru command is pointing to the right dbus object
> > of FruDevice. We may have to fix or add this support in ipmid for
> > standard fru command. Currently this command has been overridden by
> > intel-ipmi-oem and fb-ipmi-oem for their respective target. If you
> > add intel-ipmi-oem to your image then it should work.
>
> It seems like several ipmi-oem implementations (intel, fb and likely
> several others) rely on the FruDevice to prepare IPMI FRU
> information,
> so this code is likely getting duplicated across the ipmi-oem repos.
> Should this be the other way around, i.e house the FruDevice based
> implementation in phosphor-host-ipmid and the current
> phosphor-host-ipmid implementation, which expects YAML config files,
> should be in an ibm-ipmi-oem repo?
>
> Regards,
> Deepak
>
> > Regards
> > -Vijay
> >
> > On 8/26/20, 5:54 PM, "openbmc on behalf of Jiandi An" <
> > openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of
> > jan@nvidia.com> wrote:
> >
> > Hi,
> >
> > Have a question related how IPMI fru command is handled when
> > having FRU inventory handled by Entity Manager.
> > I've enabled Entity Manager and through the config JSONs, got
> > the entity manager to probe FRU config information off of EEPROM
> > and getting the FruDevice inventory D-Bus object added.
> > For example I I have /xyz/openbmc_project/FruDevice/My_FRU
> > show up under xyz.openbmc_project.FruDevice. And I can introspect
> > it. But I can't get that FRU to be handled and displayed when I
> > ran "ipmitool fru"
> >
> > root@bmc:~# busctl tree --no-pager
> > xyz.openbmc_project.FruDevice
> > └/xyz
> > └/xyz/openbmc_project
> > └/xyz/openbmc_project/FruDevice
> > └/xyz/openbmc_project/FruDevice/My_FRU
> >
> > root@bmc:~# busctl introspect --no-pager
> > xyz.openbmc_project.FruDevice /xyz/openbmc_project/FruDevice/My_FRU
> > NAME
> > TYPE SIGNATURE RESULT/VALUE
> > FLAGS
> > org.freedesktop.DBus.Introspectable interface -
> > -
> > -
> > .Introspect m
> > ethod - s
> > -
> > org.freedesktop.DBus.Peer interface
> > - -
> > -
> > .GetMachineId method
> > - s
> > -
> > .Ping
> > method - -
> > -
> > org.freedesktop.DBus.Properties interface
> > - -
> > -
> > .Get
> > method ss v
> > -
> > .GetAll
> > method s a{sv}
> > -
> > .Set
> > method ssv -
> > -
> > .PropertiesChanged signal
> > sa{sv}as -
> > -
> > xyz.openbmc_project.FruDevice interface
> > - -
> > -
> > .ADDRESS pr
> > operty u 84
> > emits-change
> > .BOARD_INFO_AM1 property
> > s "\001"
> > emits-change
> > .BOARD_LANGUAGE_CODE property
> > s "25"
> > emits-change
> > .BOARD_MANUFACTURER property
> > s "XYZ COMPANY" emits-
> > change
> > .BOARD_MANUFACTURE_DATE property s
> > "2020-01-01 - 12:00:00" emits-change
> > .BOARD_PART_NUMBER property
> > s "123.ABCD.1234" emits-
> > change
> > .BOARD_PRODUCT_NAME property
> > s "My
> > FRU" emits-change
> > .BOARD_SERIAL_NUMBER property
> > s "123ABC" e
> > mits-change
> > .BUS
> > property u 2
> > emits-change
> > .CHASSIS_PART_NUMBER property
> > s "123-12345-1234-000" emits-
> > change
> > .CHASSIS_SERIAL_NUMBER property
> > s "1234567890123" emits-
> > change
> > .CHASSIS_TYPE proper
> > ty s "23"
> > emits-change
> > .Common_Format_Version property
> > s "1"
> > emits-change
> > .PRODUCT_ASSET_TAG property
> > s "0000000000000" emits
> > -change
> > .PRODUCT_FRU_VERSION_ID property
> > s "v0.5"
> > emits-change
> > .PRODUCT_LANGUAGE_CODE property s
> > "25"
> > emits-change
> > .PRODUCT_MANUFACTURER property
> > s "XYZ COMPANY" emits-
> > change
> > .PRODUCT_PART_NUMBER property
> > s "123-12345-1234-000" emits-change
> > .PRODUCT_PRODUCT_NAME property
> > s "TBD"
> > emits-change
> > .PRODUCT_SERIAL_NUMBER property
> > s "1234567890123" emits-
> > change
> > .PRODUCT_VERSION property
> > s "v1.0"
> > emits-change
> >
> > When I ran the standard IPMI fru command, it always defaults
> > to getting Builtin FRU Device, and dimm0, dimm1, cpu0, cpu1 FRUs
> > and of course they are not there so it fails. Is there anything
> > that I'm missing to get the standard IPMI fru command to map to the
> > DBUS object xyz.openbmc_project.FruDevice
> > /xyz/openbmc_project/FruDevice/My_FRU under Entity Manger?
> >
> > root@dev-system:~# ipmitool -I lanplus -H $BMC_IP -U root -P
> > 0penBmc -C 17 fru
> > FRU Device Description : Builtin FRU Device (ID 0)
> > Device not present (Unspecified error)
> >
> > FRU Device Description : dimm0 (ID 1)
> > Device not present (Unspecified error)
> >
> > FRU Device Description : dimm1 (ID 2)
> > Device not present (Unspecified error)
> >
> > FRU Device Description : cpu0 (ID 3)
> > Device not present (Unspecified error)
> >
> > FRU Device Description : cpu1 (ID 4)
> > Device not present (Unspecified error)
> >
> > Thanks
> > - Jiandi
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-27 6:10 ` Andrei Kartashev
@ 2020-08-31 17:14 ` Ed Tanous
2020-09-02 22:27 ` Andrei Kartashev
0 siblings, 1 reply; 12+ messages in thread
From: Ed Tanous @ 2020-08-31 17:14 UTC (permalink / raw)
To: Andrei Kartashev
Cc: Deepak Kodihalli, Vijay Khemka, Jiandi An, openbmc, Tom Joseph,
vernon.mauery
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
On Wed, Aug 26, 2020 at 11:11 PM Andrei Kartashev <a.kartashev@yadro.com>
wrote:
> Since there is a plan to move to EM for inventory, I believe it is
> really good idea to also have support for FruDevice in phosphor-host-
> ipmid. Then we can have a common way on how to handle it.
> Same for SDR BTW.
>
+1. This was attempted a long time ago, but nobody was able to come up
with a design that kept the "old" way working for those that needed it, and
at the time there were some missing features. Given where entity manager
has gotten, it's probably time to start that discussion up again. Do you
think you could put together a patch that does what you describe?
>
> But there is other thing: there is catastrophically not enough
> documentation for EntityManager/dbus-sensors. Looks like common way
> just to adjust existing config and hope that it still will work.
> <sorry, was all the day trying to get adcsensors work yesterday>
>
That being the case, would you mind taking a look at the docs changes I
just put up. It's trying to improve the EM documentation a bit, although I
realize it doesn't get all the way to where it needs to be.
https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/36110
Also, it'd be great if you can come up with some concrete examples of what
else we can improve in this regard. Unfortunately the "copy an existing
config and modify" approach was the best way we found to make platform
ports easy. A lot of systems tend to look pretty similar, based on similar
reference platforms, so usually there's something to use as a starting
point. Building a config from scratch using first principals and
documentation is kind of daunting, and became a non-starter for most
people, given that the config files tend to be large.
What were the biggest roadblocks you hit trying to get ADCSensor working?
[-- Attachment #2: Type: text/html, Size: 2585 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-08-31 17:14 ` Ed Tanous
@ 2020-09-02 22:27 ` Andrei Kartashev
2020-09-03 1:15 ` Ed Tanous
0 siblings, 1 reply; 12+ messages in thread
From: Andrei Kartashev @ 2020-09-02 22:27 UTC (permalink / raw)
To: Ed Tanous; +Cc: OpenBMC Maillist
On Mon, 2020-08-31 at 10:14 -0700, Ed Tanous wrote:
>
> On Wed, Aug 26, 2020 at 11:11 PM Andrei Kartashev <
> a.kartashev@yadro.com> wrote:
> > Since there is a plan to move to EM for inventory, I believe it is
> > really good idea to also have support for FruDevice in phosphor-
> > host-
> > ipmid. Then we can have a common way on how to handle it.
> > Same for SDR BTW.
>
> +1. This was attempted a long time ago, but nobody was able to come
> up with a design that kept the "old" way working for those that
> needed it, and at the time there were some missing features. Given
> where entity manager has gotten, it's probably time to start that
> discussion up again. Do you think you could put together a patch
> that does what you describe?
>
Well, I currently have number of more critical tasks for platform
bring-up, but I can take a look.
> > But there is other thing: there is catastrophically not enough
> > documentation for EntityManager/dbus-sensors. Looks like common way
> > just to adjust existing config and hope that it still will work.
> > <sorry, was all the day trying to get adcsensors work yesterday>
>
> That being the case, would you mind taking a look at the docs changes
> I just put up. It's trying to improve the EM documentation a bit,
> although I realize it doesn't get all the way to where it needs to
> be.
> https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/36110
Great doc! I wish I had it month ago )
> Also, it'd be great if you can come up with some concrete examples of
> what else we can improve in this regard. Unfortunately the "copy an
> existing config and modify" approach was the best way we found to
> make platform ports easy. A lot of systems tend to look pretty
> similar, based on similar reference platforms, so usually there's
> something to use as a starting point. Building a config from scratch
> using first principals and documentation is kind of daunting, and
> became a non-starter for most people, given that the config files
> tend to be large.
Yes, everyone likes "copy-paste" and this is working approach. Unless
you understand what exactly you pasting. E.g. Fan/PID configuration
looks like a hell and it doesn't match one that described in phosphor-
pid-manager ).
So, now we have brilliant top-level overview, next step is to describe
how to use and extend it. That is mostly on reactor side, of course,
but on EM side we should clearly describe how config is translated to
dbus objects. Another thing I would like to have is even more high-
level document describing the common architecture of EM-based
inventory.
I can start with some drafts of what I dig, to make it more clear.
> What were the biggest roadblocks you hit trying to get ADCSensor
> working?
>
ADC is king of easiest sensor you can have, I thought ). But still I
face stones. For example, if you remove "PowerState": "On" from all
channels, you will get crash with "Power Match Not Created". Or this
configuration entry in Wolfpass config:
"BridgeGpio": [
{
"Name": "P3VBAT_BRIDGE_EN",
"Polarity": "High"
}
],
which seems to be copy-pasted from somewhere else, since it present in
all other configs, but not in board schematics ) That is, of cause, not
a problem of EM or dbus-sensor, but this is example for copy-pasting
issues.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-09-02 22:27 ` Andrei Kartashev
@ 2020-09-03 1:15 ` Ed Tanous
2020-09-07 9:09 ` Andrei Kartashev
2020-09-08 6:01 ` Jiandi An
0 siblings, 2 replies; 12+ messages in thread
From: Ed Tanous @ 2020-09-03 1:15 UTC (permalink / raw)
To: Andrei Kartashev; +Cc: OpenBMC Maillist
On Wed, Sep 2, 2020 at 3:27 PM Andrei Kartashev <a.kartashev@yadro.com> wrote:
>
> On Mon, 2020-08-31 at 10:14 -0700, Ed Tanous wrote:
> >
> > On Wed, Aug 26, 2020 at 11:11 PM Andrei Kartashev <
> > a.kartashev@yadro.com> wrote:
> > > Since there is a plan to move to EM for inventory, I believe it is
> > > really good idea to also have support for FruDevice in phosphor-
> > > host-
> > > ipmid. Then we can have a common way on how to handle it.
> > > Same for SDR BTW.
> >
> > +1. This was attempted a long time ago, but nobody was able to come
> > up with a design that kept the "old" way working for those that
> > needed it, and at the time there were some missing features. Given
> > where entity manager has gotten, it's probably time to start that
> > discussion up again. Do you think you could put together a patch
> > that does what you describe?
> >
> Well, I currently have number of more critical tasks for platform
> bring-up, but I can take a look.
If you get the time, I'd appreciate it. If not, I still appreciate
your input sofar.
>
> > > But there is other thing: there is catastrophically not enough
> > > documentation for EntityManager/dbus-sensors. Looks like common way
> > > just to adjust existing config and hope that it still will work.
> > > <sorry, was all the day trying to get adcsensors work yesterday>
> >
> > That being the case, would you mind taking a look at the docs changes
> > I just put up. It's trying to improve the EM documentation a bit,
> > although I realize it doesn't get all the way to where it needs to
> > be.
> > https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/36110
>
> Great doc! I wish I had it month ago )
At least it'll be there for the next person.
>
> > Also, it'd be great if you can come up with some concrete examples of
> > what else we can improve in this regard. Unfortunately the "copy an
> > existing config and modify" approach was the best way we found to
> > make platform ports easy. A lot of systems tend to look pretty
> > similar, based on similar reference platforms, so usually there's
> > something to use as a starting point. Building a config from scratch
> > using first principals and documentation is kind of daunting, and
> > became a non-starter for most people, given that the config files
> > tend to be large.
>
> Yes, everyone likes "copy-paste" and this is working approach. Unless
> you understand what exactly you pasting. E.g. Fan/PID configuration
> looks like a hell and it doesn't match one that described in phosphor-
> pid-manager ).
That's definitely a low effort/high reward place where we should do a
better job documenting each parameter and their constraints.
> So, now we have brilliant top-level overview, next step is to describe
> how to use and extend it. That is mostly on reactor side, of course,
> but on EM side we should clearly describe how config is translated to
> dbus objects.
This has evolved quite a bit over the life of Entity Manager, but
again, this is great feedback, and something that it's probably time
to document better including documenting the places that are "wrong",
but hacked around a problem.
> Another thing I would like to have is even more high-
> level document describing the common architecture of EM-based
> inventory.
> I can start with some drafts of what I dig, to make it more clear.
Great!
>
> > What were the biggest roadblocks you hit trying to get ADCSensor
> > working?
> >
>
> ADC is king of easiest sensor you can have, I thought ).
I think LM75 beats it :)
> But still I
> face stones. For example, if you remove "PowerState": "On" from all
> channels, you will get crash with "Power Match Not Created". Or this
> configuration entry in Wolfpass config:
That's a bug for sure. What host power state management system are you using?
> "BridgeGpio": [
> {
> "Name": "P3VBAT_BRIDGE_EN",
> "Polarity": "High"
> }
> ],
> which seems to be copy-pasted from somewhere else, since it present in
> all other configs, but not in board schematics )
> That is, of cause, not
> a problem of EM or dbus-sensor, but this is example for copy-pasting
> issues.
>
I just looked, and there's 2 platforms that have a bridgeGpio
definition, and Wolf Pass for sure has it on the schematic, not sure
about FBTP. Which platform were you looking at that didn't have it?
ADCs have a very high parasitic drain on the cmos battery, to the
point where it affects their longevity. This is an implementation of
a FET that explicitly enables the circuit when the battery is being
read. Most modern Aspeed platforms should have this circuit.
Point made, copy-paste is not a substitute for documenting what things
do so when you copy paste, you can know what needs modified.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-09-03 1:15 ` Ed Tanous
@ 2020-09-07 9:09 ` Andrei Kartashev
2020-09-08 6:01 ` Jiandi An
1 sibling, 0 replies; 12+ messages in thread
From: Andrei Kartashev @ 2020-09-07 9:09 UTC (permalink / raw)
To: Ed Tanous, openbmc
> I just looked, and there's 2 platforms that have a bridgeGpio
> definition, and Wolf Pass for sure has it on the schematic, not sure
> about FBTP. Which platform were you looking at that didn't have it?
> ADCs have a very high parasitic drain on the cmos battery, to the
> point where it affects their longevity. This is an implementation of
> a FET that explicitly enables the circuit when the battery is being
> read. Most modern Aspeed platforms should have this circuit.
>
Strange, then I probably have wrong schematics for Wolf Pass, since I
can't find any gates for P3V_BAT line.
Saying "all other configs" I meant those from meta-openbmc-mods repo:
$ grep -r "BridgeGpio" entity-manager
entity-manager/configurations/FBTP.json: "BridgeGpio": [
entity-manager/configurations/WFT Baseboard.json: "BridgeGpio": [
entity-manager/schemas/legacy.json: "BridgeGpio": {
entity-manager/schemas/legacy.json: "$ref": "#/definitions/Types/BridgeGpio"
entity-manager/schemas/legacy.json: "BridgeGpio": {
entity-manager/oe-local-files/WC-Baseboard.json: "BridgeGpio": [
entity-manager/oe-local-files/WP-Baseboard.json: "BridgeGpio": [
entity-manager/oe-local-files/TNP-baseboard.json: "BridgeGpio": [
entity-manager/oe-local-files/CYP-baseboard.json: "BridgeGpio": [
entity-manager/oe-local-files/CPC-Baseboard.json: "BridgeGpio": [
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: OpenBMC - FRU inventory with Entity Manager
2020-09-03 1:15 ` Ed Tanous
2020-09-07 9:09 ` Andrei Kartashev
@ 2020-09-08 6:01 ` Jiandi An
2020-09-09 8:31 ` Andrei Kartashev
1 sibling, 1 reply; 12+ messages in thread
From: Jiandi An @ 2020-09-08 6:01 UTC (permalink / raw)
To: Ed Tanous, Andrei Kartashev; +Cc: OpenBMC Maillist
> On Wed, Sep 2, 2020 at 3:27 PM Andrei Kartashev <a.kartashev@yadro.com> wrote:
> >
> > On Mon, 2020-08-31 at 10:14 -0700, Ed Tanous wrote:
> > >
> > > On Wed, Aug 26, 2020 at 11:11 PM Andrei Kartashev <
> > > a.kartashev@yadro.com> wrote:
> > > > Since there is a plan to move to EM for inventory, I believe it is
> > > > really good idea to also have support for FruDevice in phosphor-
> > > > host-
> > > > ipmid. Then we can have a common way on how to handle it.
> > > > Same for SDR BTW.
> > >
> > > +1. This was attempted a long time ago, but nobody was able to come
> > > up with a design that kept the "old" way working for those that
> > > needed it, and at the time there were some missing features. Given
> > > where entity manager has gotten, it's probably time to start that
> > > discussion up again. Do you think you could put together a patch
> > > that does what you describe?
> > >
> > Well, I currently have number of more critical tasks for platform
> > bring-up, but I can take a look.
>
> If you get the time, I'd appreciate it. If not, I still appreciate your input sofar.
>
> >
> > > > But there is other thing: there is catastrophically not enough
> > > > documentation for EntityManager/dbus-sensors. Looks like common
> > > > way just to adjust existing config and hope that it still will work.
> > > > <sorry, was all the day trying to get adcsensors work yesterday>
> > >
> > > That being the case, would you mind taking a look at the docs
> > > changes I just put up. It's trying to improve the EM documentation
> > > a bit, although I realize it doesn't get all the way to where it
> > > needs to be.
> > > https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/36110
> >
> > Great doc! I wish I had it month ago )
>
> At least it'll be there for the next person.
Line 72 of the doc says the 3rd component to entity-manager is the reactor.
It mentions one example is dbus-sensors, which contains a suite of application that
input the Exposes records for sensor devices, then connect to the filesystem to create
the sensors and scan loops to scan sensors for those devices.
Could someone point a sample code that a platform is doing the flow described above?
For example after enable entity-manager and put in the device tree for temp sensors
and FRU EEPROM devices, and the Exposes, probe config blocks in the json file, still
struggling to get ipmitool sensor list and ipmitool fru to work. "ipmitool fru" issue is
clear based on the feedback in this thread. But really want to have a tutorial or code
example to walk through to understand the reactor side of things.
>
> >
> > > Also, it'd be great if you can come up with some concrete examples
> > > of what else we can improve in this regard. Unfortunately the "copy
> > > an existing config and modify" approach was the best way we found to
> > > make platform ports easy. A lot of systems tend to look pretty
> > > similar, based on similar reference platforms, so usually there's
> > > something to use as a starting point. Building a config from
> > > scratch using first principals and documentation is kind of
> > > daunting, and became a non-starter for most people, given that the
> > > config files tend to be large.
> >
> > Yes, everyone likes "copy-paste" and this is working approach. Unless
> > you understand what exactly you pasting. E.g. Fan/PID configuration
> > looks like a hell and it doesn't match one that described in phosphor-
> > pid-manager ).
>
> That's definitely a low effort/high reward place where we should do a better job documenting each parameter and their constraints.
>
> > So, now we have brilliant top-level overview, next step is to describe
> > how to use and extend it. That is mostly on reactor side, of course,
> > but on EM side we should clearly describe how config is translated to
> > dbus objects.
>
> This has evolved quite a bit over the life of Entity Manager, but again, this is great feedback, and something that it's probably time to document better including documenting the places that are "wrong", but hacked around a problem.
>
> > Another thing I would like to have is even more high- level document
> > describing the common architecture of EM-based inventory.
> > I can start with some drafts of what I dig, to make it more clear.
Really appreciate for this type of document if they are available. We are adopting
entity-manager in our proof-of-concept project but really struggling to find detailed
documentation and end up just copying and pasting existing entity manager json
config files and tweaking them.
The two links we follow kind of as bibles for entity manager doesn't provide a detail guide
for example in the json config file, what each field means and how that field is being
consumed, causes what to be created on the d-bus side, and being consumed by what reactor.
https://github.com/openbmc/entity-manager/blob/master/docs/my_first_sensors.md
https://github.com/openbmc/entity-manager/blob/master/README.md
For example for sensors with entity manager do we still need the IPMI YAML
configuration file described here?
https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#defining-sensors-in-an-ipmi-yaml-configuration-file
https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml
For FRUs, for example do we still need https://github.com/ibm-openbmc/openbmc/blob/OP940/meta-ibm/meta-romulus/recipes-phosphor/configuration/romulus-yaml-config/romulus-ipmi-fru.yaml
Because I found out when doing "ipmitool fru" it always goes off of the default Builtin FRU Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3, and cpu1 ID 4.
$ ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
FRU Device Description : Builtin FRU Device (ID 0)
Device not present (Unspecified error)
FRU Device Description : dimm0 (ID 1)
Device not present (Unspecified error)
FRU Device Description : dimm1 (ID 2)
Device not present (Unspecified error)
FRU Device Description : cpu0 (ID 3)
Device not present (Unspecified error)
FRU Device Description : cpu1 (ID 4)
Device not present (Unspecified error)
And that's because https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru_gen.py always
taking https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru-read-example.yaml
from the as the default fru inventory yaml config.
unless custom fru yaml like the above is specified.
Even after porting over intel-ipmi-oem or fb-ipmi-oem's oem command fru handler for entity manager,
still has the above behavior when doing "ipmitool fru". Just really trying to look for a high level flow
of the reactor side under entity manager, sensor and fru to begin with.
In porting intel-ipmi-oem's fru command handler for entity-manager, first phosphor-ipmid-host.service
would coredump. Debugged it to be the startMatch() in registerStorageFunctions() where it's calling
boost::asio::spawn with replaceCacheFru()
https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L1311
https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L361
So switched to fb-ipmi-oem's implementation which doesn't do the replaceCacheFru with
the async handler.
https://github.com/openbmc/fb-ipmi-oem/blob/master/src/storagecommands.cpp#L185
But still "ipmi fru" would still display the default Builtin FRU Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3, and cpu1 ID 4.
So I guess need to go back and really understand the reactor side under entity-manager
and how the d-bus objects are created by the entity-manager and how they are consumed
by the reactors for each components (sensors, fru, etc.) Any documentation on that will be so
helpful as a new adopter of entity-manager trying to dig in on what different pieces need to line
up when switching to entity-manager.
>
> Great!
>
>
> > > What were the biggest roadblocks you hit trying to get ADCSensor
> > > working?
> > >
> >
> > ADC is king of easiest sensor you can have, I thought ).
>
> I think LM75 beats it :)
>
> > But still I
> > face stones. For example, if you remove "PowerState": "On" from all
> > channels, you will get crash with "Power Match Not Created". Or this
> > configuration entry in Wolfpass config:
>
> That's a bug for sure. What host power state management system are you using?
>
> > "BridgeGpio": [
> > {
> > "Name": "P3VBAT_BRIDGE_EN",
> > "Polarity": "High"
> > }
> > ],
> > which seems to be copy-pasted from somewhere else, since it present in
> > all other configs, but not in board schematics ) That is, of cause,
> > not a problem of EM or dbus-sensor, but this is example for
> > copy-pasting issues.
> >
>
> I just looked, and there's 2 platforms that have a bridgeGpio definition, and Wolf Pass for sure has it on the schematic, not sure about FBTP. Which platform were you looking at that didn't have it?
> ADCs have a very high parasitic drain on the cmos battery, to the point where it affects their longevity. This is an implementation of a FET that explicitly enables the circuit when the battery is being read. Most modern Aspeed platforms should have this circuit.
>
> Point made, copy-paste is not a substitute for documenting what things do so when you copy paste, you can know what needs modified.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-09-08 6:01 ` Jiandi An
@ 2020-09-09 8:31 ` Andrei Kartashev
2023-08-05 13:08 ` Zheng Bao
0 siblings, 1 reply; 12+ messages in thread
From: Andrei Kartashev @ 2020-09-09 8:31 UTC (permalink / raw)
To: Jiandi An; +Cc: OpenBMC Maillist
> >
> > At least it'll be there for the next person.
>
> Line 72 of the doc says the 3rd component to entity-manager is the
> reactor.
> It mentions one example is dbus-sensors, which contains a suite of
> application that
> input the Exposes records for sensor devices, then connect to the
> filesystem to create
> the sensors and scan loops to scan sensors for those devices.
>
> Could someone point a sample code that a platform is doing the flow
> described above?
>
> For example after enable entity-manager and put in the device tree
> for temp sensors
> and FRU EEPROM devices, and the Exposes, probe config blocks in the
> json file, still
> struggling to get ipmitool sensor list and ipmitool fru to
> work. "ipmitool fru" issue is
> clear based on the feedback in this thread. But really want to have
> a tutorial or code
> example to walk through to understand the reactor side of things.
>
This reactors are just a services that are expected to read their
configuration from dbus. EM expose something to dbus and then these
services are read what they need.
> > > Another thing I would like to have is even more high- level
> > > document
> > > describing the common architecture of EM-based inventory.
> > > I can start with some drafts of what I dig, to make it more
> > > clear.
>
> Really appreciate for this type of document if they are
> available. We are adopting
> entity-manager in our proof-of-concept project but really struggling
> to find detailed
> documentation and end up just copying and pasting existing entity
> manager json
> config files and tweaking them.
> The two links we follow kind of as bibles for entity manager doesn't
> provide a detail guide
> for example in the json config file, what each field means and how
> that field is being
> consumed, causes what to be created on the d-bus side, and being
> consumed by what reactor.
>
> https://github.com/openbmc/entity-manager/blob/master/docs/my_first_sensors.md
> https://github.com/openbmc/entity-manager/blob/master/README.md
>
> For example for sensors with entity manager do we still need the IPMI
> YAML
> configuration file described here?
> https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#defining-sensors-in-an-ipmi-yaml-configuration-file
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml
>
> For FRUs, for example do we still need
> https://github.com/ibm-openbmc/openbmc/blob/OP940/meta-ibm/meta-romulus/recipes-phosphor/configuration/romulus-yaml-config/romulus-ipmi-fru.yaml
>
> Because I found out when doing "ipmitool fru" it always goes off of
> the default Builtin FRU Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3,
> and cpu1 ID 4.
> $ ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
> FRU Device Description : Builtin FRU Device (ID 0)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm0 (ID 1)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm1 (ID 2)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu0 (ID 3)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu1 (ID 4)
> Device not present (Unspecified error)
>
> And that's because
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru_gen.py
> always
> taking
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru-read-example.yaml
> from the as the default fru inventory yaml config.
> unless custom fru yaml like the above is specified.
>
> Even after porting over intel-ipmi-oem or fb-ipmi-oem's oem command
> fru handler for entity manager,
> still has the above behavior when doing "ipmitool fru". Just really
> trying to look for a high level flow
> of the reactor side under entity manager, sensor and fru to begin
> with.
>
> In porting intel-ipmi-oem's fru command handler for entity-manager,
> first phosphor-ipmid-host.service
> would coredump. Debugged it to be the startMatch() in
> registerStorageFunctions() where it's calling
> boost::asio::spawn with replaceCacheFru()
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L1311
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L361
>
> So switched to fb-ipmi-oem's implementation which doesn't do the
> replaceCacheFru with
> the async handler.
> https://github.com/openbmc/fb-ipmi-oem/blob/master/src/storagecommands.cpp#L185
> But still "ipmi fru" would still display the default Builtin FRU
> Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3, and cpu1 ID 4.
>
> So I guess need to go back and really understand the reactor side
> under entity-manager
> and how the d-bus objects are created by the entity-manager and how
> they are consumed
> by the reactors for each components (sensors, fru, etc.) Any
> documentation on that will be so
> helpful as a new adopter of entity-manager trying to dig in on what
> different pieces need to line
> up when switching to entity-manager.
You don't need any YAML files when you use EM. However to get ipmitool
fru list to work you need to replace ipmi command handlers by that from
intel-ipmi-oem. If you have output like you show, then you probably
make something wrong and you still have default handlers from phosphor-
ipmid-host.
Reactors are not related to what you see in fru list. They will
construct sensors list, setup some parts of the system and so on, but
fru list in the new model is only defined by FruDevice service: you
will get there only devices that actually have I2C EEPROMs with FRU
data written.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: OpenBMC - FRU inventory with Entity Manager
2020-09-09 8:31 ` Andrei Kartashev
@ 2023-08-05 13:08 ` Zheng Bao
0 siblings, 0 replies; 12+ messages in thread
From: Zheng Bao @ 2023-08-05 13:08 UTC (permalink / raw)
To: Andrei Kartashev, Jiandi An; +Cc: OpenBMC Maillist
[-- Attachment #1: Type: text/plain, Size: 6619 bytes --]
"you will get there only devices that actually have I2C EEPROMs with FRU
data written."
Hi, Andrei,
I tried to port ethanolx to my board. It uses YAML to set the FRU information. But I can not see the list, either in dbus entity manager, or ipmitool fru list. I traced back the mail list and get an old thread.
My question:
1. Do I need to add information to the EEPROM to make dbus contain Fru? If yes, how is the fru.bin generated?
2. Do I need to porting ipmi-intel-oem to make "ipmitool fru list" contain fru?
Thanks.
Zheng
________________________________
From: openbmc <openbmc-bounces+fishbaoz=hotmail.com@lists.ozlabs.org> on behalf of Andrei Kartashev <a.kartashev@yadro.com>
Sent: Wednesday, September 9, 2020 8:31 AM
To: Jiandi An <jan@nvidia.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: OpenBMC - FRU inventory with Entity Manager
> >
> > At least it'll be there for the next person.
>
> Line 72 of the doc says the 3rd component to entity-manager is the
> reactor.
> It mentions one example is dbus-sensors, which contains a suite of
> application that
> input the Exposes records for sensor devices, then connect to the
> filesystem to create
> the sensors and scan loops to scan sensors for those devices.
>
> Could someone point a sample code that a platform is doing the flow
> described above?
>
> For example after enable entity-manager and put in the device tree
> for temp sensors
> and FRU EEPROM devices, and the Exposes, probe config blocks in the
> json file, still
> struggling to get ipmitool sensor list and ipmitool fru to
> work. "ipmitool fru" issue is
> clear based on the feedback in this thread. But really want to have
> a tutorial or code
> example to walk through to understand the reactor side of things.
>
This reactors are just a services that are expected to read their
configuration from dbus. EM expose something to dbus and then these
services are read what they need.
> > > Another thing I would like to have is even more high- level
> > > document
> > > describing the common architecture of EM-based inventory.
> > > I can start with some drafts of what I dig, to make it more
> > > clear.
>
> Really appreciate for this type of document if they are
> available. We are adopting
> entity-manager in our proof-of-concept project but really struggling
> to find detailed
> documentation and end up just copying and pasting existing entity
> manager json
> config files and tweaking them.
> The two links we follow kind of as bibles for entity manager doesn't
> provide a detail guide
> for example in the json config file, what each field means and how
> that field is being
> consumed, causes what to be created on the d-bus side, and being
> consumed by what reactor.
>
> https://github.com/openbmc/entity-manager/blob/master/docs/my_first_sensors.md
> https://github.com/openbmc/entity-manager/blob/master/README.md
>
> For example for sensors with entity manager do we still need the IPMI
> YAML
> configuration file described here?
> https://github.com/openbmc/docs/blob/master/architecture/sensor-architecture.md#defining-sensors-in-an-ipmi-yaml-configuration-file
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/sensor-example.yaml
>
> For FRUs, for example do we still need
> https://github.com/ibm-openbmc/openbmc/blob/OP940/meta-ibm/meta-romulus/recipes-phosphor/configuration/romulus-yaml-config/romulus-ipmi-fru.yaml
>
> Because I found out when doing "ipmitool fru" it always goes off of
> the default Builtin FRU Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3,
> and cpu1 ID 4.
> $ ipmitool -I lanplus -H $BMC_IP -U root -P 0penBmc -C 17 fru
> FRU Device Description : Builtin FRU Device (ID 0)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm0 (ID 1)
> Device not present (Unspecified error)
>
> FRU Device Description : dimm1 (ID 2)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu0 (ID 3)
> Device not present (Unspecified error)
>
> FRU Device Description : cpu1 (ID 4)
> Device not present (Unspecified error)
>
> And that's because
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru_gen.py
> always
> taking
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/scripts/fru-read-example.yaml
> from the as the default fru inventory yaml config.
> unless custom fru yaml like the above is specified.
>
> Even after porting over intel-ipmi-oem or fb-ipmi-oem's oem command
> fru handler for entity manager,
> still has the above behavior when doing "ipmitool fru". Just really
> trying to look for a high level flow
> of the reactor side under entity manager, sensor and fru to begin
> with.
>
> In porting intel-ipmi-oem's fru command handler for entity-manager,
> first phosphor-ipmid-host.service
> would coredump. Debugged it to be the startMatch() in
> registerStorageFunctions() where it's calling
> boost::asio::spawn with replaceCacheFru()
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L1311
> https://github.com/openbmc/intel-ipmi-oem/blob/master/src/storagecommands.cpp#L361
>
> So switched to fb-ipmi-oem's implementation which doesn't do the
> replaceCacheFru with
> the async handler.
> https://github.com/openbmc/fb-ipmi-oem/blob/master/src/storagecommands.cpp#L185
> But still "ipmi fru" would still display the default Builtin FRU
> Device ID 0, dimm0 ID1, dimm1 ID2, cpu0 ID 3, and cpu1 ID 4.
>
> So I guess need to go back and really understand the reactor side
> under entity-manager
> and how the d-bus objects are created by the entity-manager and how
> they are consumed
> by the reactors for each components (sensors, fru, etc.) Any
> documentation on that will be so
> helpful as a new adopter of entity-manager trying to dig in on what
> different pieces need to line
> up when switching to entity-manager.
You don't need any YAML files when you use EM. However to get ipmitool
fru list to work you need to replace ipmi command handlers by that from
intel-ipmi-oem. If you have output like you show, then you probably
make something wrong and you still have default handlers from phosphor-
ipmid-host.
Reactors are not related to what you see in fru list. They will
construct sensors list, setup some parts of the system and so on, but
fru list in the new model is only defined by FruDevice service: you
will get there only devices that actually have I2C EEPROMs with FRU
data written.
[-- Attachment #2: Type: text/html, Size: 14480 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-08-05 13:09 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-27 0:47 OpenBMC - FRU inventory with Entity Manager Jiandi An
2020-08-27 4:53 ` Andrei Kartashev
2020-08-27 5:32 ` Vijay Khemka
2020-08-27 5:43 ` Deepak Kodihalli
2020-08-27 6:10 ` Andrei Kartashev
2020-08-31 17:14 ` Ed Tanous
2020-09-02 22:27 ` Andrei Kartashev
2020-09-03 1:15 ` Ed Tanous
2020-09-07 9:09 ` Andrei Kartashev
2020-09-08 6:01 ` Jiandi An
2020-09-09 8:31 ` Andrei Kartashev
2023-08-05 13:08 ` Zheng Bao
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.