commit | 5629fbc005e4329acf56bc61be7feba85ccb9f5e | [log] [tgz] |
---|---|---|
author | Priyanga Ramasamy <priyanga24@in.ibm.com> | Wed Mar 01 08:17:19 2023 -0600 |
committer | Priyanga Ramasamy <priyanga24@in.ibm.com> | Fri May 05 06:43:26 2023 -0500 |
tree | ef860be0029ddfa571b941801bf2cf3fc138ffe8 | |
parent | b498cd3c64a5ae088e9eebbe809bd638352c22c2 [diff] |
vpd-tool #kw support This commit is to enable vpd-tool read and write support for pound keywords starting with # and for numeric keywords. This commit enables a way to read and write keyword values using --file option, where --file takes a file with absolute path. when --file option used with --readKeyword flag - vpd-tool saves the output in the given file. and when the file option used with --writeKeyword flag - the vpd-tool takes the value from file and performs write operation. Test: ----------------------------------------------- Case 1: Read from hardware and save in text file ----------------------------------------------- vpd-tool -r -H -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" --file /tmp/output.txt Value read is saved in the file /tmp/output.txt ----------------------------------------------- Case 2: Write to hardware by taking input from a text file ----------------------------------------------- :~# cat /tmp/write.txt 00102030405060607020304050601020304050606040302010 :~# vpd-tool -w -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" --file /tmp/write.txt -H Data updated successfully :~# vpd-tool -r -H -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" { "/sys/bus/i2c/drivers/at24/8-0050/eeprom": { "#D": "0x0010203040506060702030405060102030405060604030201000000000 ...0000" } } ----------------------------------------------- Case 3: Read from cache and pipe to text file ----------------------------------------------- :~# vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" --file /tmp/read-motherboard-#D.txt Value read is saved in the file /tmp/read-motherboard-#D.txt ----------------------------------------------- Case 4: Write to cache by taking input from text file ----------------------------------------------- :~# cat /tmp/write.txt 00102030405060607020304050601020304050606040302010 :~# vpd-tool -w -O /system/chassis/motherboard -R PSPD -K "#D" --file /tmp/write.txt Data updated successfully :~# vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" { "/system/chassis/motherboard": { "#D": "0x0010203040506060702030405060102030405060604030201000000000000000000....." } } ----------------------------------------------- Case 5: Write to cache by taking hex input from console ----------------------------------------------- :~# vpd-tool -w -O /system/chassis/motherboard -R PSPD -K "#D" -V 0x65 Data updated successfully :~# vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" { "/system/chassis/motherboard": { "#D": "0x65100c0c000000000000000 ... } } Case 5.1: Write to cache by providing ascii values as input from console vpd-tool -w -O /system/chassis/motherboard -R PSPD -K "#D" -V abcd Data updated successfully vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" { "/system/chassis/motherboard": { "#D": "0x6162636440506060702030405060102030405060604030201000000 .." } } ----------------------------------------------- Case 6: Read from cache and display on console ----------------------------------------------- :~# vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" { "/system/chassis/motherboard": { "#D": "0x00100c0c00000000000000000000000000000000000000 ..... } } ----------------------------------------------- Case 7: Read from hardware and display on console ----------------------------------------------- vpd-tool -r -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" -H { "/sys/bus/i2c/drivers/at24/8-0050/eeprom": { "#D": "0x651020304050606070203040506010203040506060403020100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ......... 000000000000000000000000000000000000000" } } ----------------------------------------------- Case 8: Write to hardware via console ----------------------------------------------- vpd-tool -w -H -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" -V 0x00100c0c000000000000000000000000000000000000 Data updated successfully vpd-tool -r -O /sys/bus/i2c/drivers/at24/8-0050/eeprom -R PSPD -K "#D" -H { "/sys/bus/i2c/drivers/at24/8-0050/eeprom": { "#D": "0x00100c0c00000000000000000000000000000000000030201000000000000000000000000 ... } } ----------------------------------------------- Case 9: Write 10240 bytes on dbus ----------------------------------------------- time vpd-tool -w -O /system/chassis/motherboard -R PSPD -K "#D" --file /tmp/output.txt Data updated successfully real 0m49.564s user 0m0.047s sys 0m0.009s time vpd-tool -r -O /system/chassis/motherboard -R PSPD -K "#D" { "/system/chassis/motherboard": { "#D": "0x01100c0c0000.....0000123456782746002" } } real 0m0.072s user 0m0.057s sys 0m0.001s ------------------------------------------------ Signed-off-by: Priyanga Ramasamy <priyanga24@in.ibm.com> Change-Id: I3977a7778b28ebcada7788f619b18bbca6ed0c8c
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.