{"id":18368632,"url":"https://github.com/openbmc/pldm","last_synced_at":"2025-04-06T22:11:46.235Z","repository":{"id":39816841,"uuid":"168029932","full_name":"openbmc/pldm","owner":"openbmc","description":null,"archived":false,"fork":false,"pushed_at":"2024-10-29T15:21:03.000Z","size":22501,"stargazers_count":32,"open_issues_count":7,"forks_count":39,"subscribers_count":12,"default_branch":"master","last_synced_at":"2024-10-29T16:04:40.949Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openbmc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-01-28T20:15:14.000Z","updated_at":"2024-10-29T15:26:37.000Z","dependencies_parsed_at":"2024-01-22T13:08:36.044Z","dependency_job_id":"67959c68-f44c-4ecf-b038-fe2194fa5a2d","html_url":"https://github.com/openbmc/pldm","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openbmc%2Fpldm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openbmc%2Fpldm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openbmc%2Fpldm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openbmc%2Fpldm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openbmc","download_url":"https://codeload.github.com/openbmc/pldm/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247557767,"owners_count":20958047,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-05T23:26:47.133Z","updated_at":"2025-04-06T22:11:46.216Z","avatar_url":"https://github.com/openbmc.png","language":"C++","funding_links":[],"categories":[],"sub_categories":[],"readme":"# PLDM - Platform Level Data Model\n\n[![License](https://img.shields.io/badge/license-Apache%202.0-blue.svg)](LICENSE)\n\n## Overview\n\nPLDM (Platform Level Data Model) is a key component of the OpenBMC project,\nproviding a standardized data model and message formats for various platform\nmanagement functionalities. It defines a method to manage, monitor, and control\nthe firmware and hardware of a system.\n\nThe OpenBMC PLDM project aims to implement the specifications defined by the\nDistributed Management Task Force (DMTF), allowing for interoperable management\ninterfaces across different hardware and firmware components.\n\n## Features\n\n- **Standardized Messaging:** Adheres to the DMTF's PLDM specifications,\n  enabling consistent and interoperable communication between different\n  components.\n- **Modularity:** Supports multiple PLDM types, including base, FRU,Firmware\n  update, Platform Monitoring and Control, and BIOS Control and Configuration.\n- **Extensibility:** Easily extendable to support new PLDM types and custom OEM\n  commands.\n- **Integration:** Seamlessly integrates with other OpenBMC components for\n  comprehensive system management.\n\n## Getting Started\n\n### Prerequisites\n\nTo build and run PLDM, you need the following dependencies:\n\n- `Meson`\n- `Ninja`\n\nAlternatively, source an OpenBMC ARM/x86 SDK.\n\n### Building\n\nTo build the PLDM project, follow these steps:\n\n```bash\nmeson setup build \u0026\u0026 ninja -C build\n```\n\n### To run unit tests\n\nThe simplest way of running the tests is as described by the meson man page:\n\n```bash\nmeson setup builddir \u0026\u0026 meson setup test -C builddir\n```\n\nAlternatively, tests can be run in the OpenBMC CI docker container using\n[these](https://github.com/openbmc/docs/blob/master/testing/local-ci-build.md)\nsteps.\n\n### To enable pldm verbosity\n\npldm daemon accepts a command line argument `--verbose` or `--v` or `-v` to\nenable the daemon to run in verbose mode. It can be done via adding this option\nto the environment file that pldm service consumes.\n\n```bash\necho 'PLDMD_ARGS=\"--verbose\"' \u003e /etc/default/pldmd\nsystemctl restart pldmd\n```\n\n### To disable pldm verbosity\n\n```bash\nrm /etc/default/pldmd\nsystemctl restart pldmd\n```\n\n### Code Organization\n\nAt a high-level, code in this repository belongs to one of the following three\ncomponents.\n\n#### libpldmresponder\n\nThis library provides handlers for incoming PLDM request messages. It provides\nfor a registration as well as a plug-in mechanism. The library is implemented in\nmodern C++, and handles OpenBMC's platform specifics.\n\nThe handlers are of the form\n\n```c\nResponse handler(Request payload, size_t payloadLen)\n```\n\nSource files are named according to the PLDM Type, for eg base.[hpp/cpp],\nfru.[hpp/cpp], etc.\n\n#### OEM/vendor-specific functions\n\nThis will support OEM or vendor-specific functions and semantic information.\nFollowing directory structure has to be used:\n\n```txt\n    pldm repo\n     |---- oem\n            |----\u003coem_name\u003e\n                      |----libpldmresponder\n                            |---\u003coem based handler files\u003e\n\n```\n\n\u003coem_name\u003e - This folder must be created with the name of the OEM/vendor in\nlower case. Folders named libpldm and libpldmresponder must be created under the\nfolder \u003coem_name\u003e\n\nFiles having the oem functionality for the libpldmresponder library should be\nplaced under the folder oem/\u003coem_name\u003e/libpldmresponder. They must be adhering\nto the rules mentioned under the libpldmresponder section above.\n\nOnce the above is done a meson option has to be created in\n`pldm/meson_options.txt` with its mapped compiler flag to enable conditional\ncompilation.\n\nFor consistency would recommend using \"oem-\u003coem_name\u003e\".\n\nThe `pldm/meson.build` and the corresponding source file(s) will need to\nincorporate the logic of adding its mapped compiler flag to allow conditional\ncompilation of the code.\n\n##### libpldm\n\npldm daemon links against the libpldm library during compilation, For more\ninformation on libpldm please refer to\n[libpldm](https://github.com/openbmc/libpldm)\n\n##### pldmtool\n\nFor more information on pldmtool please refer to plmdtool/README.md.\n\n##### Flows\n\nThis section documents important code flow paths.\n\n###### BMC as PLDM responder\n\na) PLDM daemon receives PLDM request message from underlying transport (MCTP).\n\nb) PLDM daemon routes message to message handler, based on the PLDM command.\n\nc) Message handler decodes request payload into various field(s) of the request\nmessage. It can make use of a decode_foo_req() API, and doesn't have to perform\ndeserialization of the request payload by itself.\n\nd) Message handler works with the request field(s) and generates response\nfield(s).\n\ne) Message handler prepares a response message. It can make use of an\nencode_foo_resp() API, and doesn't have to perform the serialization of the\nresponse field(s) by itself.\n\nf) The PLDM daemon sends the response message prepared at step e) to the remote\nPLDM device.\n\n##### BMC as PLDM requester\n\na) A BMC PLDM requester app prepares a PLDM request message. There would be\nseveral requester apps (based on functionality/PLDM remote device). Each of them\nneedn't bother with the serialization of request field(s), and can instead make\nuse of an encode_foo_req() API.\n\nb) BMC requester app requests PLDM daemon to send the request message to remote\nPLDM device.\n\nc) Once the PLDM daemon receives a corresponding response message, it notifies\nthe requester app.\n\nd) The requester app has to work with the response field(s). It can make use of\na decode_foo_resp() API to deserialize the response message.\n\n###### PDR Implementation\n\nWhile PLDM Platform Descriptor Records (PDRs) are mostly static information,\nthey can vary across platforms and systems. For this reason, platform specific\nPDR information is encoded in platform specific JSON files. JSON files must be\nnamed based on the PDR type number. For example a state effecter PDR JSON file\nwill be named 11.json. The JSON files may also include information to enable\nadditional processing (apart from PDR creation) for specific PDR types, for eg\nmapping an effecter id to a D-Bus object.\n\nThe PLDM responder implementation finds and parses PDR JSON files to create the\nPDR repository. Platform specific PDR modifications would likely just result in\nJSON updates. New PDR type support would require JSON updates as well as PDR\ngeneration code. The PDR generator is a map of PDR Type -\u003e C++ lambda to create\nPDR entries for that type based on the JSON, and to update the central PDR repo.\n\n###### BIOS Support\n\nRedfish supports the BIOS Attribute Registry, which provides users with a list\nof BIOS attributes supported in the BIOS configuration. To incorporate BIOS\nattribute registry support in openBMC, BmcWeb is designed to read data from the\nBase BIOS Table. PLDM populates the Base BIOS Table for the BIOS Config Manager\nbased on BIOS JSON files. BIOS functionality is integrated into PLDM according\nto the guidelines in the\n[PLDM BIOS Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf).\nBIOS attributes, also referred to as BIOS parameters or configuration settings,\nare structured within JSON files. Each attribute is defined by its name, type,\nand type-specific metadata. PLDM parses\n[BIOS JSON file](https://github.com/openbmc/pldm/tree/master/oem/ibm/configurations/bios/com.ibm.Hardware.Chassis.Model.Rainier2U)\nand creates the\n[Base BIOS Table](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L62)\nhosted by [BIOS Config Manager](https://github.com/openbmc/bios-settings-mgr).\nThe design is documented in\n[DesignDoc](https://github.com/openbmc/docs/blob/master/designs/remote-bios-configuration.md).\nRedfish supports\n[BIOS Attribute registry](https://redfish.dmtf.org/schemas/v1/AttributeRegistry.v1_3_8.json),\nwhich provides users with the list of BIOS attributes supported in the BIOS\nconfiguration. The BIOS Attribute registry data is supposed to be derived from\n[Base BIOS Table](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/BIOSConfig/Manager.interface.yaml#L62).\nPLDM populates the Base BIOS Table for BIOS Config Manager based on BIOS Json\nfiles.\n\nAfter the JSON files are parsed, pldm would also create the string table,\nattribute table, and attribute value table as per Section7 in\n[PLDM BIOS Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf).\nThose BIOS tables are exchanged with remote PLDM terminus using the\n`GetBiosTable` command as defined in DSP0247_1.0.0.pdf Section 8.1. All the\n`bios attribute json files are kept under OEM`\n[Path](https://github.com/openbmc/pldm/tree/master/oem). BIOS json configuration\nis provided in bios_attr.json file which contains attributes of type enum,\ninteger and string.\n\nInteger Attribute details as documented at Table9 of\n[PLDM BIOS Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf):\n\n```json\n{\n  \"entries\": [\n    {\n      \"attribute_type\": \"integer\",\n      \"attribute_name\": \"Attribute Name\",\n      \"lower_bound\": \"The lower bound on the integer value\",\n      \"upper_bound\": \"The upper bound on the integer value\",\n      \"scalar_increment\": \"The scalar value that is used for the increments to this integer \",\n      \"default_value\": \"The default value of the integer\",\n      \"help_text\": \"Help text about attribute usage\",\n      \"display_name\": \"Attribute Display Name\",\n      \"read_only\": \"Read only Attribute\"\n    }\n  ]\n}\n```\n\nEnum Attribute details as documented at Table6 of\n[PLDM BIOS Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf):\n\n```json\n{\n  \"entries\": [\n    {\n      \"attribute_type\": \"enum\",\n      \"attribute_name\": \"Attribute Name\",\n      \"possible_values\": [\n        \"An array of character strings of variable to indicate the possible values of the BIOS attribute\"\n      ],\n      \"default_values\": \"Default value\",\n      \"help_text\": \"Help text about attribute usage\",\n      \"display_name\": \"Display Name\",\n      \"read_only\": \"Read only Attribute\"\n    }\n  ]\n}\n```\n\nString Attribute details as documented at Table7 of\n[PLDM BIOS Specification](https://www.dmtf.org/sites/default/files/standards/documents/DSP0247_1.0.0.pdf):\n\n```json\n{\n  \"entries\": [\n    {\n      \"attribute_type\": \"string\",\n      \"attribute_name\": \"Attribute Name\",\n      \"string_type\": \"It specifies the character encoding format, which can be ASCII, Hex, UTF-8, UTF-16LE, or UTF-16BE. Currently, only ASCII is supported\",\n      \"minimum_string_length\": \"The minimum length of the string in bytes\",\n      \"maximum_string_length\": \"The maximum length of the string in bytes\",\n      \"default_string\": \"The default string itself\",\n      \"help_text\": \"Help text about attribute usage\",\n      \"display_name\": \"Attribute Display Name\",\n      \"read_only\": \"Read only Attribute\"\n    }\n  ]\n}\n```\n\nAs PLDM BIOS Attributes may differ across platforms and systems, supporting\nsystem-specific BIOS attributes is crucial. To achieve this, BIOS JSON files are\norganized under folders named after the system type. System type information is\nretrieved from the Entity Manager service, which hosts the\n[Compatible Interface](https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/yaml/xyz/openbmc_project/Inventory/Decorator/Compatible.interface.yaml).\n\nThis interface dynamically populates the Names property with system type\ninformation. However, determining the system type in the application space may\ntake some time since the compatible interface and the Names property are\ndynamically created by the Entity Manager. Consequently, BIOS tables are lazily\nconstructed upon receiving the system type.\n\nTo enable system-specific BIOS attribute support within PLDM, the meson option\n`system-specific-bios-json` can be utilized. With `system-specific-bios-json`\noption `enabled` BIOS JSON files specific to the system type are fetched during\nruntime.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenbmc%2Fpldm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenbmc%2Fpldm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenbmc%2Fpldm/lists"}