commit | 37c6bef9e3ad2ab80a5fb7ac9f76eedd1cd37ec8 | [log] [tgz] |
---|---|---|
author | Souvik Roy <souvikroyofficial10@gmail.com> | Thu Jul 17 00:55:59 2025 -0500 |
committer | SunnySrivastava <sunnsr25@in.ibm.com> | Fri Jul 25 04:32:57 2025 +0000 |
tree | aac43f049c4e3f4683fd17c39ef2171ffce293f6 | |
parent | d966f27f27359500f1dbd04470764e432facb430 [diff] |
Fix exception type loss while parsing VPD This commit includes changes to prevent loss of exception type while parsing VPD. In case of Data/ECC exception while parsing IPZ VPD, the exception type was lost. This commit also handles setting PEL severity in case of Data/ECC exception. In case of Data/ECC exception while parsing VPD, predictive PEL must be logged. Test: ``` - On rainier 2s2u simics system, corrupt VHDR data of base op panel - On rainier 2s2u simics system, corrupt VHDR ECC of op LCD panel - Restart vpd-manager - Check PELs using peltool - Observe 2 predictive PELs logged with Data Exception and ECC Exception respectively ``` Change-Id: I21e5b668aa70cc13916475792e38e5822c00117e Signed-off-by: Souvik Roy <souvikroyofficial10@gmail.com>
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 at a broken link.
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.