commit | e9c575354bb7216ebee6756ceb8b2ef174a3b7cc | [log] [tgz] |
---|---|---|
author | Santosh Puranik <santosh.puranik@in.ibm.com> | Tue Mar 15 16:51:51 2022 +0530 |
committer | Santosh Puranik <santosh.puranik@in.ibm.com> | Wed Apr 20 04:48:50 2022 +0000 |
tree | 4abeab609365dee059f477422f3a05f0f05eaa98 | |
parent | 53b38ed09ab95deacaada1e9b70b766d922ad409 [diff] |
Do not collect VPD unless required This commit adds some checks before we attempt VPD collection on udev events. The following conditions are added: -- Check if the FRU is marked concurrently maintainable or pluggable at standby. If either is true, proceed. -- Check if the BMC is at a NotReady state - if yes, proceeed. -- Check if the FRU has never been colelcted before (Present is false) - if yes, proceed. In all other scenarios, the collection is skipped. This helps eliminate cases where grabbing the SPI mux causes a whole bunch of parsers to run, and an immediate power on leads to I2C arbitration loss errors. Signed-off-by: Santosh Puranik <santosh.puranik@in.ibm.com> Change-Id: I8f92014e1fc0becf5f7c56019a31bb2e46c6ccf0
This repository hosts code for OpenPower and IBM IPZ format VPD parsers. Both OpenPower VPD and IPZ VPD formats are structured binaries that consist of records and keywords. A record is a collection of multiple keywords. More information about the format can be found here.
The repository consists of two distinct applications, which are:
This is a build-time YAML driven application that parses the OpenPower VPD format and uses the YAML configuration (see extra-properties-example.yaml and writefru.yaml) to determine:
The application instance must be passed in the file path to the VPD (this can, for example, be a sysfs path exposed by the EEPROM device driver) and also the D-Bus object path(s) that EEPROM data needs to be published under.
This parser is can be built by passing in the --enable-ibm-parser
configure option. This parser differs from the OpenPower VPD parser in the following ways:
#
and are > 255 bytes in length).Making the application runtime JSON driven allows us to support multiple systems (with different FRU configurations) to be supported in a single code image as well as making the application more flexible for future improvements.