pldm: Use std::expected for instance ID allocation

Refactor InstanceIdDb::next() to return
std::expected<uint8_t, InstanceIdError> instead of throwing exceptions.
With this change, errors are no lon

pldm: Use std::expected for instance ID allocation

Refactor InstanceIdDb::next() to return
std::expected<uint8_t, InstanceIdError> instead of throwing exceptions.
With this change, errors are no longer thrown by default.
Instead, the caller can inspect allocation errors as values, extract
the error message or code as needed, or explicitly throw the error
further up the stack if appropriate.
This approach allows for more flexible and explicit error handling, and
reduces reliance on exception-based control flow.

Motivation:
This change aims to improve robustness by enabling explicit error
handling and reducing the risk of uncaught exceptions that could lead
to a pldmd core dump if an instance ID allocation fails for a single
EID. Such a core dump could disrupt ongoing operations such as sensor
polling or firmware updates for other EIDs

Note:
Currently, some call sites are still void-returning functions and
cannot propagate errors via return values.
As a result, errors from InstanceIdDb::next() are thrown as
InstanceIdError at these locations to avoid silent failures.
Ideally, it would be preferable for these functions to propagate errors
by value (for example, using std::expected), so that errors can always
be handled explicitly without relying on exceptions.

Change-Id: I7189e97f206bae1eed5c8db44ebbbcd4393c8f8d
Signed-off-by: Eric Yang <eric.yang.wiwynn@gmail.com>

show more ...

oem-ibm: Real SAI sensor and effecter PDR support

Real SAI (Sysytem Attention Indicator) is a physical led
indicator which lights up whenever there is a platform
error (originated from BMC) or a par

oem-ibm: Real SAI sensor and effecter PDR support

Real SAI (Sysytem Attention Indicator) is a physical led
indicator which lights up whenever there is a platform
error (originated from BMC) or a partition error
(originated from remote terminus) that is not mapped to
any physical FRU (Field Replaceable Unit)

Real SAI scenarios
1. Real SAI effecter can be turned off by the user OR by a
remote terminus
2. Real SAI sensor is turned on if any of the partition SAI
OR platform SAI is turned on
3. Real SAI is turned off if both partition and platform SAI
are turned off
4. SAI data should be synced to remote terminus

Tested By:
Verified the sensor values with the dbus property changes.
Also executed the effecter operation to clear the Real SAI
state.

oem-ibm flag:
Change successfully built with oem-ibm as disabled

Change-Id: Ia31a9104589acdc08dc42b51082c8103b1d92754
Signed-off-by: Jayashankar Padath <jayashankarpadath@gmail.com>

show more ...

pldmtool: fix multipart pdr printing

Use the size of all the received data, instead of only the last received
chunk, to print the pdr.

respCnt stores the size of the last PDR transferred payload, n

pldmtool: fix multipart pdr printing

Use the size of all the received data, instead of only the last received
chunk, to print the pdr.

respCnt stores the size of the last PDR transferred payload, not the
size of the full pdr record that we are currently retrieving, because of
this, a multipart transmission of a pdr repo fails in the printing
stage.

Change-Id: Ifb292c1c42b4882e82cd238b81761ee4c1307d20
Signed-off-by: Roger G. Coscojuela <roger.gili-coscojuela@sipearl.com>

show more ...

pldmtool: use correct recordChangeNumber in pdr transmission

The recordChangeNumber comes from the first part of the pdr
transmission, and should be reused during the multipart transmission.

Middle

pldmtool: use correct recordChangeNumber in pdr transmission

The recordChangeNumber comes from the first part of the pdr
transmission, and should be reused during the multipart transmission.

Middle parts of a multipart transmission do not have the header
included, so trying to obtain the record change number from them is
wrong.

Change-Id: Ie7d60aa6758f9d1a9450ecda8af35a83090fb5dd
Signed-off-by: Roger G. Coscojuela <roger.gili-coscojuela@sipearl.com>

show more ...

pldmtool: fix misspelling in pdr output

Fixed fatalLeow -> fatalLow

Change-Id: I2106504edbaaa69d07fc9d444baa3cfa9983fc86
Signed-off-by: Roger G. Coscojuela <roger.gili-coscojuela@sipearl.com>

meson: pldmtool: fix subproject build

pldmtool uses headers from phosphor-logging for lg2 support, but
was missing the phosphor-logging dependency. Add the dependency
back in, which fixes subprojec

meson: pldmtool: fix subproject build

pldmtool uses headers from phosphor-logging for lg2 support, but
was missing the phosphor-logging dependency. Add the dependency
back in, which fixes subproject-based builds.

Without this change the following failure is observed:
```
In file included from ../pldmtool/pldm_cmd_helper.hpp:4,
from ../pldmtool/pldm_cmd_helper.cpp:1:
../common/utils.hpp:15:10: fatal error: phosphor-logging/lg2.hpp: No such file or directory
15 | #include <phosphor-logging/lg2.hpp>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
```

With the change, the build is successful.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Id4ca9e7a01e3dfb8b93cbb8da4094264923c3e4d

show more ...

pldmtool: Use a non-listening transport for command access

pldmtool does not really need to create a listening (bind) transport
to do a simple send/receive transaction. Hence refactor PldmTransport

pldmtool: Use a non-listening transport for command access

pldmtool does not really need to create a listening (bind) transport
to do a simple send/receive transaction. Hence refactor PldmTransport
allowing a user to specify if the required transport is expected
to be listening or non-listening and switch pldmtool to use a
non-listening transport.

Change-Id: I390298397d71c0ea27234880b844898c7a100ca5
Signed-off-by: Amithash Prasad <amithash@meta.com>

show more ...

pldmtool: Create supported PDR types list dynamically

In current implementation the supported types list, used in the pldmtool
usage text, is hard-coded.

This patch uses the strToPDRType map to gen

pldmtool: Create supported PDR types list dynamically

In current implementation the supported types list, used in the pldmtool
usage text, is hard-coded.

This patch uses the strToPDRType map to generate the list of supported
PDR types.

Tested.

Before:
'''
$ pldmtool platform GetPDR --help
....
-t,--type TEXT retrieve all PDRs of the requested type
supported types:
[terminusLocator, stateSensor, numericEffecter, stateEffecter, compactNumericSensor, sensorauxname, effecterAuxName, numericsensor, EntityAssociation, fruRecord, ... ]
....
'''

After:
'''
$ pldmtool platform GetPDR --help
....
-t,--type TEXT retrieve all PDRs of the requested type
supported types:
[compactnumericsensor, effecterauxname, entityassociation, frurecord, numericeffecter, numericsensor, sensorauxname, stateeffecter, statesensor, terminuslocator, ...]
....
'''

Change-Id: I2203848927445eaec3f861791f51c4ef31457beb
Signed-off-by: Aditya Kurdunkar <akurdunkar@nvidia.com>

show more ...

pldmtool: Fix effecterAuxName typo

Fixes a minor typo.

Change-Id: Ibb06eba8cd48e2ac1dbaee7482d552009f944cad
Signed-off-by: Aditya Kurdunkar <akurdunkar@nvidia.com>

pldmtool: Fix containedEntity parsing

Commit "pldmtool : Migrate to placement_new from reinterpret casting"
(5c3f0d1b09bfbd206c33841b83938ef5f057a655) has broken a parsing of
containedEntities from

pldmtool: Fix containedEntity parsing

Commit "pldmtool : Migrate to placement_new from reinterpret casting"
(5c3f0d1b09bfbd206c33841b83938ef5f057a655) has broken a parsing of
containedEntities from the Entity Association PDR.
Currently the first element of the children array is initialized from
the default constructor instead of using data from a pointer.
Correct statement syntax to fix the issue.

Tested:
Output from the "pldmtool platform GetPDR -v -a -m <MCTP_EID>"

Before:
<...>
pldmtool: Tx: 81 02 51 4c 04 00 00 00 00 00 00 01 ff ff 00 00
pldmtool: Rx: 01 02 51 00 4d 04 00 00 00 00 00 00 05 1a 00 4c 04 00 00
01 0f 00 00 10 00 64 00 00 44 00 01 00 00 00 01 90 00 01 00 64 00
{
<...>
"PDRType": "Entity Association PDR",
<...>
"containedEntityCount": 1,
"containedEntityType[1]": "[Physical] Unspecified",
"containedEntityInstanceNumber[1]": 0,
"containedEntityContainerID[1]": 0
}
<...>

After:
<...>
pldmtool: Tx: 81 02 51 4c 04 00 00 00 00 00 00 01 ff ff 00 00
pldmtool: Rx: 01 02 51 00 4d 04 00 00 00 00 00 00 05 1a 00 4c 04 00 00
01 0f 00 00 10 00 64 00 00 44 00 01 00 00 00 01 90 00 01 00 64 00
{
<...>
"PDRType": "Entity Association PDR",
<...>
"containedEntityCount": 1,
"containedEntityType[1]": "[Physical] Network Controller",
"containedEntityInstanceNumber[1]": 1,
"containedEntityContainerID[1]": 100
}
<...>

Change-Id: I938c0ad8a2a42ddb0d43b20b2419a3075b3f30f2
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>

show more ...

pldmtool: Correct bit defs in getFirmwareParameter

The definitions for bit 2 and bit 3 in getFirmwareParameters were
inadvertently swapped in pldmtool, contrary to the DSP0267 v1.3.0
specification.

pldmtool: Correct bit defs in getFirmwareParameter

The definitions for bit 2 and bit 3 in getFirmwareParameters were
inadvertently swapped in pldmtool, contrary to the DSP0267 v1.3.0
specification. This change restores the correct mapping to align with
the standard.

Resolves : openbmc/pldm#50

Change-Id: Ib36af27557bb3a509158e6307fa4e5c6686d3649
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

pldmtool: correct help text for GetPLDMCommands

The previous help example showed the PLDM version bytes in the wrong
order, leading to incorrect requests. The version bytes must be
specified as [alp

pldmtool: correct help text for GetPLDMCommands

The previous help example showed the PLDM version bytes in the wrong
order, leading to incorrect requests. The version bytes must be
specified as [alpha update minor major] to match the ver32_t decode
logic and PLDM spec (DSP4014). Updated the help text example to show
the correct order: e.g., version 1.1.0 should be `0x00 0xF0 0xF1 0xF1`.

This helps users avoid confusion when passing version data to --data.

Change-Id: Id7573217bf2e46ffcabb82237bb63d452c4fb33d
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

Revert "pldm: use std::expected for instance ID allocation"

This reverts commit 70262ed7bf854b25d4b65628bc3c892ddfe9380f.

Change-Id: I1f54d6b60bf3cfa9f00764140eec6167e1e182d6
Signed-off-by: Manojki

Revert "pldm: use std::expected for instance ID allocation"

This reverts commit 70262ed7bf854b25d4b65628bc3c892ddfe9380f.

Change-Id: I1f54d6b60bf3cfa9f00764140eec6167e1e182d6
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

pldmtool: Include fwupdate in supported PLDM types

`pldmd` daemon has supported firmware update for over a year. This
commit adds the firmware update type to the list of supported PLDM
types so that

pldmtool: Include fwupdate in supported PLDM types

`pldmd` daemon has supported firmware update for over a year. This
commit adds the firmware update type to the list of supported PLDM
types so that it is correctly reported in the response to the
`PLDMGetTypes` command.

Change-Id: I024c122c73a77da8f74e579672b2b18f75ad764e
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

pldm: use std::expected for instance ID allocation

Refactor InstanceIdDb::next() to return
std::expected<uint8_t, InstanceIdError> instead of throwing exceptions.
This change enables callers to expl

pldm: use std::expected for instance ID allocation

Refactor InstanceIdDb::next() to return
std::expected<uint8_t, InstanceIdError> instead of throwing exceptions.
This change enables callers to explicitly handle allocation errors via
value inspection, rather than relying on exception handling.

This approach prevents core dumps from uncaught exceptions and
eliminates the need for pervasive try-catch blocks.
Callers can now access the error code and message directly, improving
clarity and control of error propagation.

Note:
Errors from InstanceIdDb::next() are currently handled via early
return, which may silently discard failures.
This is a temporary solution; APIs and callers will need to be updated
in the future to propagate and handle errors explicitly.

Change-Id: Ibf2e0034b0ee725cb59adfd93b74e48db8c42cba
Signed-off-by: Eric Yang <eric.yang.wiwynn@gmail.com>

show more ...

wstring_convert: pragma out deprecation warning

With GCC 15, we are starting to see the following warnings:

```
15:17:59 | ../git/platform-mc/terminus.cpp:333:22: error: 'template<class _Codecvt, c

wstring_convert: pragma out deprecation warning

With GCC 15, we are starting to see the following warnings:

```
15:17:59 | ../git/platform-mc/terminus.cpp:333:22: error: 'template<class _Codecvt, class _Elem, class _Wide_alloc, class _Byte_alloc> class std::__cxx11::wstring_convert' is deprecated [-Werror=deprecated-declarations]
```

Insert pragmas around them until another solution is found, so that
we can perform the next Yocto upgrade.

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: I4132eec42b79cd7f3c18b9b1798e8f871241328b

show more ...

pldmtool: Add GetEventReceiver command

Added GetEventReceiver to receive the current configured event receiver
from a terminus.

This command is defined in DSP0248 as a conditional command

Tested r

pldmtool: Add GetEventReceiver command

Added GetEventReceiver to receive the current configured event receiver
from a terminus.

This command is defined in DSP0248 as a conditional command

Tested results:
```
root@bmc:~# pldmtool platform GetEventReceiver --help
Get the configured event receiver from a terminus
Usage: pldmtool platform GetEventReceiver [OPTIONS]

Options:
-h,--help Print this help message and exit
-m,--mctp_eid UINT MCTP endpoint ID
-v,--verbose

root@bmc:~# pldmtool platform GetEventReceiver -m 42
{
"completionCode": 0,
"transportProtocolType": 0,
"eventReceiverAddressInfo": 142
}
```

Change-Id: Id699875b84d1a6fd851d935f2aed038df661376b
Signed-off-by: Roger G. Coscojuela <roger.gili-coscojuela@sipearl.com>

show more ...

pldmtool: Add support for CancelUpdate

Tested:

pldmtool fw_update CancelUpdate -m 13
{
"CompletionCode": "SUCCESS",
"NonFunctioningComponentIndication": "False"
}

Change-Id: I9a5824658e8e8

pldmtool: Add support for CancelUpdate

Tested:

pldmtool fw_update CancelUpdate -m 13
{
"CompletionCode": "SUCCESS",
"NonFunctioningComponentIndication": "False"
}

Change-Id: I9a5824658e8e8f2611427b8722947d9777e08813
Signed-off-by: Tom Joseph <rushtotom@gmail.com>

show more ...

pldmtool: Add support for CancelUpdateComponent

Tested:

pldmtool fw_update CancelUpdateComponent -m 13
{
"CompletionCode": "SUCCESS"
}

Change-Id: I1b2c36ad9d181ae9bd8d611b769bfbc8287c36f1
Sign

pldmtool: Add support for CancelUpdateComponent

Tested:

pldmtool fw_update CancelUpdateComponent -m 13
{
"CompletionCode": "SUCCESS"
}

Change-Id: I1b2c36ad9d181ae9bd8d611b769bfbc8287c36f1
Signed-off-by: Tom Joseph <rushtotom@gmail.com>

show more ...

pldmtool: Add support for ActivateFirmware

Tested:

pldmtool fw_update ActivateFirmware ..

{
"CompletionCode": "SUCCESS",
"EstimatedTimeForSelfContainedActivation": "2s"
}

Change-Id: I265b

pldmtool: Add support for ActivateFirmware

Tested:

pldmtool fw_update ActivateFirmware ..

{
"CompletionCode": "SUCCESS",
"EstimatedTimeForSelfContainedActivation": "2s"
}

Change-Id: I265bdc9dc4d2552f74ee8fb8971d31d839fe6793
Signed-off-by: Tom Joseph <rushtotom@gmail.com>

show more ...

pldmtool: Add support for UpdateComponent

Tested:

pldmtool fw_update UpdateComponent --component_classification ..

{
"CompletionCode": "SUCCESS",
"ComponentCompatibilityResponse": "Compone

pldmtool: Add support for UpdateComponent

Tested:

pldmtool fw_update UpdateComponent --component_classification ..

{
"CompletionCode": "SUCCESS",
"ComponentCompatibilityResponse": "Component can be updated",
"ComponentCompatibilityResponseCode": "0x00",
"UpdateOptionFlagsEnabled": "1",
"EstimatedTimeBeforeSendingRequestFirmwareData": "0s"
}

Change-Id: I4bbea500514c551fcbb75a06e109f1a9bfb7b7e4
Signed-off-by: Tom Joseph <rushtotom@gmail.com>

show more ...

pldmtool: Use valid completion code as per spec

Use `PLDM_ERROR_UNEXPECTED_TRANSFER_FLAG_OPERATION` rather than
`PLDM_INVALID_TRANSFER_FLAG_OPERATION` which is inaccurate as per
the pldm spec.

Chan

pldmtool: Use valid completion code as per spec

Use `PLDM_ERROR_UNEXPECTED_TRANSFER_FLAG_OPERATION` rather than
`PLDM_INVALID_TRANSFER_FLAG_OPERATION` which is inaccurate as per
the pldm spec.

Change-Id: I327f36cc37427b900b0b1d1762e1fd62d28bd21e
Signed-off-by: Manojkiran Eda <manojkiran.eda@gmail.com>

show more ...

pldmtool: Add PassComponentTable command support

Add support for PLDM PassComponentTable command defined in the
PLDM Firmware Update specification.

Test Results:
```
./pldmtool fw_update PassCompon

pldmtool: Add PassComponentTable command support

Add support for PLDM PassComponentTable command defined in the
PLDM Firmware Update specification.

Test Results:
```
./pldmtool fw_update PassComponentTable --transfer_flag START --comp_classification 0x0A --comp_identifier 65280 --comp_classification_idx 0 --comp_compare_stamp 1 --comp_ver_str_type ASCII --comp_ver_str_len 4 --comp_ver_str ver1 -m 13
{
"CompletionCode": "SUCCESS",
"ComponentResponse": "Component may be updateable",
"ComponentResponseCode": "0x02"
}
```

Change-Id: Id5285267d884ca27788a1eae13397bf38eb45f12
Signed-off-by: Rajeev Ranjan <ranjan.rajeev1609@gmail.com>

show more ...

pldmtool: Add completion code to GetPLDMTypes & GetPLDMVersion

Add human readable completion code strings to GetPLDMTypes
and GetPLDMVersion command response.
Test Results:
```
./pldmtool base GetPL

pldmtool: Add completion code to GetPLDMTypes & GetPLDMVersion

Add human readable completion code strings to GetPLDMTypes
and GetPLDMVersion command response.
Test Results:
```
./pldmtool base GetPLDMTypes -m 13
{
"CompletionCode": "SUCCESS",
"PLDMTypes": [
{
"PLDM Type": "base",
"PLDM Type Code": 0
},
{
"PLDM Type": "platform",
"PLDM Type Code": 2
}
]
}

./pldmtool base GetPLDMVersion -t base -m 13
{
"CompletionCode": "SUCCESS",
"Response": "1.0.0"
}
```
Change-Id: Ic6441812a1958016345516527ff10f4cf2b72379
Signed-off-by: Rajeev Ranjan <ranjan.rajeev1609@gmail.com>

show more ...

pldmtool: Add RequestUpdate command support

Add support for the PLDM RequestUpdate command defined
in the PLDM Firmware Update specification. This enables
pldmtool to initiate firmware update reques

pldmtool: Add RequestUpdate command support

Add support for the PLDM RequestUpdate command defined
in the PLDM Firmware Update specification. This enables
pldmtool to initiate firmware update requests with
parameters such as maximum transfer size, number of
components, and component image version info.

Test Results:
```

pldmtool fw_update RequestUpdate --max_transfer_size 32
--num_comps 2 --max_transfer_reqs 10 --package_data_length
10 --comp_img_ver_str_type ASCII --comp_img_ver_str_len 4
--comp_img_set_ver_str ver1 -m 13

{
"CompletionCode": "SUCCESS",
"FirmwareDeviceMetaDataLength": 0,
"FDWillSendGetPackageDataCommand": "0x00"
}

```
Change-Id: I02ac06070dbb12a5756cae440dff28788751dceb
Signed-off-by: Rajeev Ranjan <ranjan.rajeev1609@gmail.com>

show more ...