Gitiles
Code Review Sign In
gerrit.openbmc.org / openbmc / pldm / 7ad45b401134e3b3a05a75200dbba00afd5aee46
commit7ad45b401134e3b3a05a75200dbba00afd5aee46[log] [tgz]
authorUnive Tien <unive.tien.wiwynn@gmail.com>Mon Aug 18 06:04:53 2025 +0000
committerManojKiran Eda <manojkiran.eda@gmail.com>Fri Sep 12 06:02:53 2025 +0000
tree8d3899e5b73471de4c4d7bd5c46c231f5bc707b6
parent505542588031c26ce7918ad4d35aacf6bc3b80b9 [diff]
fw_update: Introduce FirmwareInventory

Spec reference: [1]

Description:
FirmwareInventory is a class that manages all of the D-Bus
utilities for the firmware update functionality of each entry,
FirmwareInventoryManager is used to manage multiple FirmwareInventory
instances.

Flow of the routine when one or more firmware device is added:
1. When one or more firmware device is added, the InventoryManager
   instance will try to create a FirmwareInventory entry for the added
   device, to accomplish this, it will need to fetch the necessary
   information from various source (e.g. EM, device descriptors).

2. After the information is gathered, the InventoryManager will try to
   obtain a Name for each firmware devices, to fit the different
   platform condition, the name will be reference by the order below:
    1. From Entity Manager (EM), if the endpoint has a specific EM
       configuration with "Name" property listed.
    2. From device descriptors, if the device descriptor contains a
       vendor defined descriptor with "OpenBMC.Name" titled.
    3. Spawn a default one, named "Firmware_Device_<Endpoint ID>".

3. The InventoryManager will then invoke
   `FirmwareInventoryManager::createFirmwareInventory` to create a
   firmware inventory entry.

Properties managed by firmware Inventory:
1. Version
   Version object that represents the firmware version
2. Association
   Association object that represents the associations for the
   firmware

The object path pattern of the firmware inventory entry is:
`/xyz/openbmc_project/software/<BoardName>_<SoftwareName>_<SoftwareID>`

Where:
- `<BoardName>` represents the board the device is on.
- `<SoftwareName>` is the name of the firmware device obtained from the
  InventoryManager.
- `<SoftwareID>` is a 4-byte random number to help consumer
  distinguish from the new/old objects of a inventory item.
  For example:
  `server_board_slot_1_VR_2603`
  The new Activation object and its related interfaces needs to
  resides on a new objectPath, hence the softwareId is appended to
  the path.

Test results:
 - Build passed
 - Successfully create firmware inventory entries
   on Yosemite V4

[1]: https://github.com/openbmc/docs/blob/master/designs/code-update.md

Change-Id: Idebd7d013c82c60f08309a1860d5de1deeb3829a
Signed-off-by: Unive Tien <unive.tien.wiwynn@gmail.com>
Signed-off-by: Carter Chen <carter.chen.wiwynn@gmail.com>
17 files changed
tree: 8d3899e5b73471de4c4d7bd5c46c231f5bc707b6
  1. common/
  2. configurations/
  3. docs/
  4. fw-update/
  5. host-bmc/
  6. libpldmresponder/
  7. oem/
  8. platform-mc/
  9. pldmd/
  10. pldmtool/
  11. requester/
  12. softoff/
  13. subprojects/
  14. test/
  15. tools/
  16. utilities/
  17. .clang-format
  18. .clang-tidy
  19. .eslintignore
  20. .gitignore
  21. .linter-ignore
  22. LICENSE
  23. meson.build
  24. meson.options
  25. OWNERS
  26. README.md
README.md

PLDM - Platform Level Data Model

License

Overview

PLDM (Platform Level Data Model) is a key component of the OpenBMC project, providing a standardized data model and message formats for various platform management functionalities. It defines a method to manage, monitor, and control the firmware and hardware of a system.

The OpenBMC PLDM project aims to implement the specifications defined by the Distributed Management Task Force (DMTF), allowing for interoperable management interfaces across different hardware and firmware components.

Features

  • Standardized Messaging: Adheres to the DMTF's PLDM specifications, enabling consistent and interoperable communication between different components.
  • Modularity: Supports multiple PLDM types, including base, FRU,Firmware update, Platform Monitoring and Control, and BIOS Control and Configuration.
  • Extensibility: Easily extendable to support new PLDM types and custom OEM commands.
  • Integration: Seamlessly integrates with other OpenBMC components for comprehensive system management.

Getting Started

Prerequisites

To build and run PLDM, you need the following dependencies:

  • Meson
  • Ninja

Alternatively, source an OpenBMC ARM/x86 SDK.

Building

To build the PLDM project, follow these steps:

meson setup build && meson compile -C build

To run unit tests

The simplest way of running the tests is as described by the meson man page:

meson test -C build

Alternatively, tests can be run in the OpenBMC CI docker container using these steps.

To enable pldm verbosity

pldm daemon accepts a command line argument --verbose or --v or -v to enable the daemon to run in verbose mode. It can be done via adding this option to the environment file that pldm service consumes.

echo 'PLDMD_ARGS="--verbose"' > /etc/default/pldmd
systemctl restart pldmd

To disable pldm verbosity

rm /etc/default/pldmd
systemctl restart pldmd

Documentation

For complete documentation on the functionality and usage of this repository, please refer to the docs folder.