commit	b8baffa32c65ba43dc0c2724f2642d3d668c4c5f	[log] [tgz]
author	Sridevi Ramesh <sridevra@in.ibm.com>	Wed Jul 22 06:44:39 2020 -0500
committer	Deepak Kodihalli <dkodihal@in.ibm.com>	Wed Oct 07 05:38:14 2020 +0000
tree	bab552d50bbeeb11bcabb638498de389b174dbe2
parent	b1fbeec5f8234c21608da867838c7e3820952500 [diff]

pldmtool: Parse OEM IBM FRU records

./pldmtool fru GetFRURecordByOption -i 1 -r 254 -f 0
FRU Record Set Identifier: 1
FRU Record Type: OEM(254)
Number of FRU fields: 15
Encoding Type for FRU fields: ASCII(1)
        FRU Field Type: RT(2)
        FRU Field Length: 4
        FRU Field Value: VSYS
        FRU Field Type: BR(3)
        FRU Field Length: 2
        FRU Field Value: 0x20 0x20
        FRU Field Type: DR(4)
        FRU Field Length: 6
        FRU Field Value: 0x53 0x59 0x53 0x54 0x45 0x4d
        FRU Field Type: FV(5)
        FRU Field Length: 32
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: ID(6)
        FRU Field Length: 2
        FRU Field Value: 0x20 0x20
        FRU Field Type: MN(7)
        FRU Field Length: 7
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: NN(8)
        FRU Field Length: 16
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: RB(9)
        FRU Field Length: 4
        FRU Field Value: 0x20 0x20 0x20 0x20
        FRU Field Type: RG(10)
        FRU Field Length: 4
        FRU Field Value: 0x20 0x20 0x20 0x20
        FRU Field Type: SE(11)
        FRU Field Length: 7
        FRU Field Value: 0x53 0x49 0x4d 0x50 0x31 0x30 0x52
        FRU Field Type: SG(12)
        FRU Field Length: 7
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: SU(13)
        FRU Field Length: 6
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: TM(14)
        FRU Field Length: 8
        FRU Field Value: 0x39 0x31 0x30 0x35 0x2d 0x32 0x32 0x41
        FRU Field Type: TN(15)
        FRU Field Length: 8
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: WN(16)
        FRU Field Length: 12
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
FRU Record Set Identifier: 1
FRU Record Type: OEM(254)
Number of FRU fields: 1
Encoding Type for FRU fields: ASCII(1)
        FRU Field Type: Location Code(254)
        FRU Field Length: 17
        FRU Field Value: U9105.22A.SIMP10R
ecord Set Identifier: 1
FRU Record Type: OEM(254)
Number of FRU fields: 15
Encoding Type for FRU fields: ASCII(1)
        FRU Field Type: RT(2)
        FRU Field Length: 4
        FRU Field Value: VSYS
        FRU Field Type: BR(3)
        FRU Field Length: 2
        FRU Field Value: 0x20 0x20
        FRU Field Type: DR(4)
        FRU Field Length: 6
        FRU Field Value: 0x53 0x59 0x53 0x54 0x45 0x4d
        FRU Field Type: FV(5)
        FRU Field Length: 32
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: ID(6)
        FRU Field Length: 2
        FRU Field Value: 0x20 0x20
        FRU Field Type: MN(7)
        FRU Field Length: 7
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: NN(8)
        FRU Field Length: 16
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: RB(9)
        FRU Field Length: 4
        FRU Field Value: 0x20 0x20 0x20 0x20
        FRU Field Type: RG(10)
        FRU Field Length: 4
        FRU Field Value: 0x20 0x20 0x20 0x20
        FRU Field Type: SE(11)
        FRU Field Length: 7
        FRU Field Value: 0x53 0x49 0x4d 0x50 0x31 0x30 0x52
        FRU Field Type: SG(12)
        FRU Field Length: 7
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20
       FRU Field Length: 7
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: SU(13)
        FRU Field Length: 6
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: TM(14)
        FRU Field Length: 8
        FRU Field Value: 0x39 0x31 0x30 0x35 0x2d 0x32 0x32 0x41
        FRU Field Type: TN(15)
        FRU Field Length: 8
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
        FRU Field Type: WN(16)
        FRU Field Length: 12
        FRU Field Value: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
FRU Record Set Identifier: 1
FRU Record Type: OEM(254)
Number of FRU fields: 1
Encoding Type for FRU fields: ASCII(1)
        FRU Field Type: Location Code(254)
        FRU Field Length: 17
        FRU Field Value: U9105.22A.SIMP10R

./pldmtool fru GetFRURecordByOption -i 2 -r 254 -f 254
FRU Record Set Identifier: 2
FRU Record Type: OEM(254)
Number of FRU fields: 1
Encoding Type for FRU fields: ASCII(1)
        FRU Field Type: Location Code(254)
        FRU Field Length: 17
        FRU Field Value: U78DA.ND1.1234567

./pldmtool fru GetFRURecordByOption -i 0 -r 254 -f 4
terminate called after throwing an instance of 'std::invalid_argument'
  what():  GetFRURecordByOption is not supported for recordType : 254 and fieldType > 2
Aborted (core dumped)

Change-Id: I8fdf60f25b18d0d02319460a0c212028a87f1c4b
Signed-off-by: Sridevi Ramesh <sridevra@in.ibm.com>

2 files changed

tree: bab552d50bbeeb11bcabb638498de389b174dbe2

README.md

To Build

Need meson and ninja. Alternatively, source an OpenBMC ARM/x86 SDK.

meson build && ninja -C build

To run unit tests

Tests can be run in the CI docker container, or with an OpenBMC x86 sdk(see below for x86 steps).

meson -Doe-sdk=enabled -Dtests=enabled build
ninja -C build test

Code Organization

At a high-level, code in this repository belongs to one of the following three components.

libpldm

This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:

keeping it light weight
implementation in C
minimal dynamic memory allocations
endian-safe
no OpenBMC specific dependencies

Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.

Given a PLDM command "foo", the library will provide the following API: For the Requester function:

encode_foo_req() - encode a foo request
decode_foo_resp() - decode a response to foo

For the Responder function:

decode_foo_req() - decode a foo request
encode_foo_resp() - encode a response to foo

The library also provides API to pack and unpack PLDM headers.

libpldmresponder

This library provides handlers for incoming PLDM request messages. It provides for a registration as well as a plug-in mechanism. The library is implemented in modern C++, and handles OpenBMC's platform specifics.

The handlers are of the form

Response handler(Request payload, size_t payloadLen)

Source files are named according to the PLDM Type, for eg base.[hpp/cpp], fru.[hpp/cpp], etc.

OEM/vendor-specific functions

This will support OEM or vendor-specific functions and semantic information. Following directory structure has to be used:

    pldm repo
     |---- oem
            |----<oem_name>
                      |----libpldm
                            |----<oem based encoding and decoding files>
                      |----libpldmresponder
                            |---<oem based handler files>

<oem_name> - This folder must be created with the name of the OEM/vendor in lower case. Folders named libpldm and libpldmresponder must be created under the folder <oem_name>

Files having the oem functionality for the libpldm library should be placed under the folder oem/<oem_name>/libpldm. They must be adhering to the rules mentioned under the libpldm section above.

Files having the oem functionality for the libpldmresponder library should be placed under the folder oem/<oem_name>/libpldmresponder. They must be adhering to the rules mentioned under the libpldmresponder section above.

Once the above is done a conditional flag has to be created in the configure.ac to enable conditional compilation.

For consistency would recommend using "--enable-oem-<oem_name>".

The Makefile.am files in libpldm and libpldmresponder will need to be changed to allow conditional compilation of the code.

TODO

Consider hosting libpldm above in a repo of its own, probably even outside the OpenBMC project? A separate repo would enable something like git submodule.

Flows

This section documents important code flow paths.

BMC as PLDM responder

a) PLDM daemon receives PLDM request message from underlying transport (MCTP).

b) PLDM daemon routes message to message handler, based on the PLDM command.

c) Message handler decodes request payload into various field(s) of the request message. It can make use of a decode_foo_req() API, and doesn't have to perform deserialization of the request payload by itself.

d) Message handler works with the request field(s) and generates response field(s).

e) Message handler prepares a response message. It can make use of an encode_foo_resp() API, and doesn't have to perform the serialization of the response field(s) by itself.

f) The PLDM daemon sends the response message prepared at step e) to the remote PLDM device.

BMC as PLDM requester

a) A BMC PLDM requester app prepares a PLDM request message. There would be several requester apps (based on functionality/PLDM remote device). Each of them needn't bother with the serialization of request field(s), and can instead make use of an encode_foo_req() API.

b) BMC requester app requests PLDM daemon to send the request message to remote PLDM device.

c) Once the PLDM daemon receives a corresponding response message, it notifies the requester app.

d) The requester app has to work with the response field(s). It can make use of a decode_foo_resp() API to deserialize the response message.

PDR Implementation

While PLDM Platform Descriptor Records (PDRs) are mostly static information, they can vary across platforms and systems. For this reason, platform specific PDR information is encoded in platform specific JSON files. JSON files must be named based on the PDR type number. For example a state effecter PDR JSON file will be named 11.json. The JSON files may also include information to enable additional processing (apart from PDR creation) for specific PDR types, for eg mapping an effecter id to a D-Bus object.

The PLDM responder implementation finds and parses PDR JSON files to create the PDR repository. Platform specific PDR modifications would likely just result in JSON updates. New PDR type support would require JSON updates as well as PDR generation code. The PDR generator is a map of PDR Type -> C++ lambda to create PDR entries for that type based on the JSON, and to update the central PDR repo.