edtanous
commented
3 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
bradbishop
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.FruDeviceIt 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.