search

openbmc / entity-manager

Run-time JSON driven system configuration manager
Other
26 stars 48 forks source link

Non IPMI-standard format FRU EEPROM support #16

Closed mgarrett33 closed 2 years ago

mgarrett33 commented 2 years ago

I believe EM today supports parsing FRU EEPROMs in the standard format.

HPE servers (meta-hpe) have a FRU attached to the BMC on the baseboard that is not in the standard format but has some of the same types of data. In the HPE case, the manufacturer is assumed, and the EEPROM also contains the MAC addresses for the network controllers. So we are missing some info relative to the standard while adding additional non-standard fields, all in an HPE specific data structure.

Because of this specialized case, we created a customized service (based upon a trivial fork of EM) specifically to surface the HPE FRU EEPROM (https://github.com/HewlettPackard/openbmc-gxp-fru-device) as a dbus xyz.openbmc_project.FruDevice

It was suggested that we not keep a custom service for this, and merge into EM. I'm agreeable to this but would like thoughts on the best path forward. The most expedient path as best I can tell is to create an HPE specific build option that compiles our FRU support in. I'm also content to keep this in our separate service if the fit is not right.

edtanous commented 2 years ago

On Thu, Nov 4, 2021 at 4:39 AM Mike Garrett @.***> wrote:

I believe EM today supports parsing FRU EEPROMs in the standard format.

HPE servers (meta-hpe) have a FRU attached to the BMC on the baseboard that is not in the standard format but has some of the same types of data. In the HPE case, the manufacturer is assumed, and the EEPROM also contains the MAC addresses for the network controllers. So we are missing some info relative to the standard while adding additional non-standard fields, all in an HPE specific data structure.

Because of this specialized case, we created a customized service (based upon a trivial fork of EM) specifically to surface the HPE FRU EEPROM (https://github.com/HewlettPackard/openbmc-gxp-fru-device) as a dbus xyz.openbmc_project.FruDevice

It was suggested that we not keep a custom service for this, and merge into EM. I'm agreeable to this but would like thoughts on the best path forward. The most expedient path as best I can tell is to create an HPE specific build option that compiles our FRU support in.

Getting this into EM and not maintaining a fork is the right path. Is there no way to keep the code the same? https://gerrit.openbmc-project.xyz/c/openbmc/entity-manager/+/47512 recently added support for Tyans custom offset/identifier in a way that doesn't conflict with other systems. Maybe that would be of some use?

I'm also content to keep this in our separate service if the fit is not right.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

mgarrett33 commented 2 years ago

Closed as answered

bradbishop commented 2 years ago

@santoshpuranik fyi