commit | 83ea53fe3717148525475bc8c875e4933f6c8a5e | [log] [tgz] |
---|---|---|
author | PriyangaRamasamy <priyanga24@in.ibm.com> | Thu May 13 05:55:21 2021 -0500 |
committer | priyanga24 <priyanga24@in.ibm.com> | Thu May 13 11:46:12 2021 +0000 |
tree | 322e624b73450d0a4718ea5bd07c2bc992a33dd9 | |
parent | 12e24ff3ee08e12211d735c61974cc579c482c8a [diff] |
Vpd-tool: Hardware option fix The -H hardware flag is given when the user wants to update hardware. When -H flag is given, the user must provide the eeprom path and not the object path in -O/object option. Test: 1. When dbus object path is given with -H Hardware flag - tool throws error. root@rainier:/tmp# ./vpd-tool -u -H -O /system/chassis/motherboard/vdd_vrm1 -R VINI -K CC -V 0x7172 Invalid EEPROM path : /system/chassis/motherboard/vdd_vrm1. The given EEPROM path doesn't exist. Provide valid EEPROM path when -H flag is used. Refer help option. root@rainier:/tmp# 2. To update directly on hardware - ( - this updates the keyword on ONLY hardware for those keywords which are not mentioned in /usr/share/vpd/dbus_properties.json) ( - if the given keyword is present in dbus_properties.json => then both HARDWARE AND DBUS are updated.) ./vpd-tool -u -H -O /sys/devices/platform/ahb/ahb:apb/ahb:apb:bus@1e78a000/1e78a580.i2c-bus/i2c-10/10-0050/10-00500/nvmem -R VINI -K CC -V 0x7172 Tested that both hardware and dbus is updated as the record-keyword VINI-CC is a part of dbus_properties.json. 3. To update on dbus and hardware ( no matter whether or not the record-keyword is present in dbus_properties.json.) ./vpd-tool -u -O /system/chassis/motherboard/vdd_vrm1 -R VINI -K DR -V 0x7172 4. Help option root@rainier:/tmp# ./vpd-tool --help VPD Command line tool to dump the inventory and to read and update the keywords Usage: ./vpd-tool [OPTIONS] Options: -h,--help Print this help message and exit -O,--object TEXT Enter the Object Path -R,--record TEXT Enter the Record Name -K,--keyword TEXT Enter the Keyword -V,--value TEXT Enter the value. The value to be updated should be either in ascii or in hex. ascii eg: 01234; hex eg: 0x30313233 -o,--dumpObject Needs: --object Dump the given object from the inventory. { vpd-tool-exe --dumpObject/-o --object/-O object-name } -i,--dumpInventory Dump all the inventory objects. { vpd-tool-exe --dumpInventory/-i } -r,--readKeyword Needs: --object --record --keyword Read the data of the given keyword. { vpd-tool-exe --readKeyword/-r --object/-O "object-name" --record/-R "record-name" --keyword/-K "keyword-name" } -w,-u,--writeKeyword,--updateKeyword Needs: --object --record --keyword --value Update the value. { vpd-tool-exe --writeKeyword/-w/--updateKeyword/-u --object/-O object-name --record/-R record-name --keyword/-K keyword-name --value/-V value-to-be-updated } -f,-F,--forceReset Force Collect for Hardware. { vpd-tool-exe --forceReset/-f/-F } -H,--Hardware This is a supplementary flag to write directly to hardware. When the -H flag is given, User should provide valid hardware/eeprom path (and not dbus object path) in the -O/--object path. Signed-off-by: PriyangaRamasamy <priyanga24@in.ibm.com> Change-Id: Id6b808422651043c8e7115b5aeb19cb3102bbe85
#Overview 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.