commit | f277d6a748e3697a320c294c05bd5870833ceaac | [log] [tgz] |
---|---|---|
author | Souvik Roy <souvikroyofficial10@gmail.com> | Thu Feb 20 00:08:43 2025 -0600 |
committer | Souvik Roy <souvikroyofficial10@gmail.com> | Fri Feb 21 10:34:10 2025 +0000 |
tree | 064cf82d114f666ec874f2797c4a74a4ac405857 | |
parent | 8fc1252efced598cb4e9ca5e3720a0a7ad117451 [diff] |
Refactor encode keyword API exception handling This commit refactors vpd specific utility API used to encode value of a keyword,in order to handle any exceptions thrown by it locally. All utility methods should handle exceptions locally and log a journal log in case of failure. The caller of the utility APIs should check the return value to detect success/failure. Test: ``` - Install bitbaked image on Everest - Clear persistent PIM data on filesystem, restart PIM and then vpd-manager services - Check MACAddress property is properly populated on PIM for ethernet0 and ethernet1 ``` Change-Id: Idd2ec502081886937ab108fb4b19b9c359ecd000 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 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.