| commit | b37be3135a88feebca16972139f5b9ae288f14f2 | [log] [tgz] |
|---|---|---|
| author | Sampa Misra <sampmisr@in.ibm.com> | Wed Jul 03 02:26:41 2019 -0500 |
| committer | Deepak Kodihalli <dkodihal@in.ibm.com> | Wed Jul 24 10:21:28 2019 +0000 |
| tree | 7b0d75ae18428a2d6df649b82f50b9cd5d5d8bae | |
| parent | 52552ef3f2f6f8b18f177fa992ca39c7c9400b7b [diff] |
GetBIOSTable responder implementation This commit implements the GetBIOSTable responder handler for the BIOS Enumeration type. One of the tables among String table, Attribute table and Attribute Value Table are created/fetched and sent to PLDM requester as response to the command. Tested: Following are the tables constructed from the sample json file present at "test/bios_jsons/enum_attrs.json" -bash-4.2$ hexdump -C /tmp/AllBiosTables/stringTable 00000000 00 00 07 00 41 6c 6c 6f 77 65 64 01 00 10 00 43 |....Allowed....C| 00000010 6f 64 65 55 70 64 61 74 65 50 6f 6c 69 63 79 02 |odeUpdatePolicy.| 00000020 00 0a 00 43 6f 6e 63 75 72 72 65 6e 74 03 00 0a |...Concurrent...| 00000030 00 44 69 73 72 75 70 74 69 76 65 04 00 0a 00 46 |.Disruptive....F| 00000040 57 42 6f 6f 74 53 69 64 65 05 00 0f 00 48 4d 43 |WBootSide....HMC| 00000050 4d 61 6e 61 67 65 64 53 74 61 74 65 06 00 10 00 |ManagedState....| 00000060 49 6e 62 61 6e 64 43 6f 64 65 55 70 64 61 74 65 |InbandCodeUpdate| 00000070 07 00 0a 00 4e 6f 74 41 6c 6c 6f 77 65 64 08 00 |....NotAllowed..| 00000080 03 00 4f 66 66 09 00 02 00 4f 6e 0a 00 04 00 50 |..Off....On....P| 00000090 65 72 6d 0b 00 04 00 54 65 6d 70 00 37 90 c0 da |erm....Temp.7...| 000000a0 -bash-4.2$ hexdump -C /tmp/AllBiosTables/attributeTable 00000000 00 00 00 01 00 02 02 00 03 00 01 00 01 00 00 04 |................| 00000010 00 02 0a 00 0b 00 01 00 02 00 00 05 00 02 08 00 |................| 00000020 09 00 01 01 03 00 00 06 00 02 00 00 07 00 01 00 |................| 00000030 3b 85 69 a7 |;.i.| 00000034 -bash-4.2$ hexdump -C /tmp/AllBiosTables/attributeValueTable 00000000 00 00 00 01 00 00 00 00 d9 f6 42 58 |..........BX| 0000000c Change-Id: I06aebcc2c2deea66e867fb775afa76a1e5d18dca Signed-off-by: Sampa Misra <sampmisr@in.ibm.com>
At a high-level, code in this repository belongs to one of the following three components.
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:
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.
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.
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.
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.
This section documents important code flow paths.
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.
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.
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.