| commit | 8eedaa6c9649d5513bbf884f20b8a361143914b0 | [log] [tgz] |
|---|---|---|
| author | Aditya Kurdunkar <akurdunkar@nvidia.com> | Mon Aug 18 21:21:08 2025 +0530 |
| committer | Aditya Kurdunkar <akurdunkar@nvidia.com> | Tue Sep 30 21:48:23 2025 +0530 |
| tree | a429b198495024750f92c19433c34f0416bc6275 | |
| parent | 273bee2422de8c0ba4bb2c3e25e74e05afd0fc66 [diff] |
platform-mc: Use a default terminus name if empty
Current flow for terminus name determination is: ( Defined here: [1] )
1. If neither EM nor PDRs provide a terminus name, it will be empty.
2. If only the EM provides a terminus name, the EM-defined name is used.
3. If both EM and PDRs provide a terminus name, the PDRs-defined name
will override the EM-defined name.
If the terminus name is empty the numeric sensor creation is skipped.
This patch ensures that there's a fallback terminus name (in the format
`Terminus_{TID}` for case 1, when both EM and PDRs don't provide the
sensor name and numeric sensor creation isn't skipped.
Tested.
```
-- Terminus on dbus
~ busctl tree xyz.openbmc_project.PLDM
....
| `- /xyz/openbmc_project/inventory/system
| `- /xyz/openbmc_project/inventory/system/board
| |- /xyz/openbmc_project/inventory/system/board/Terminus_101
....
-- Sensors on dbus
~ busctl tree xyz.openbmc_project.PLDM
....
|- /xyz/openbmc_project/sensors
| `- /xyz/openbmc_project/sensors/temperature
| |- /xyz/openbmc_project/sensors/temperature/Terminus_101_Sensor_1
| |- /xyz/openbmc_project/sensors/temperature/Terminus_101_Sensor_8
....
```
[1]: https://gerrit.openbmc.org/c/openbmc/pldm/+/82469
Change-Id: I9c1d05b25371d5549593e24364adf060dd37e056
Signed-off-by: Aditya Kurdunkar <akurdunkar@nvidia.com>
- common/
- configurations/
- docs/
- fw-update/
- host-bmc/
- libpldmresponder/
- oem/
- platform-mc/
- pldmd/
- pldmtool/
- requester/
- softoff/
- subprojects/
- test/
- tools/
- utilities/
- .clang-format
- .clang-tidy
- .eslintignore
- .gitignore
- .linter-ignore
- LICENSE
- meson.build
- meson.options
- OWNERS
- README.md
PLDM - Platform Level Data Model
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:
MesonNinja
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.