fw-update: Refuse FD commands while none is expected
Since the device update is wound down with CancelUpdate before it is
reported, there is a window of up to a few seconds between pldmd giving
up on a device and the device being recorded as completed, during which
UpdateManager::handleRequest() still dispatches the device's commands
(RequestFirmwareData, TransferComplete, VerifyComplete, ApplyComplete)
to its DeviceUpdater as if the update were alive. The same is true
between a RequestUpdate refused with ALREADY_IN_UPDATE_MODE and the end
of the CancelUpdate that recovers from it, when a stale update session
of the device (left behind by a pldmd restart) may still be requesting
data. A compliant device is silent in both situations, but one that
does talk would have its request served from the new package, re-arm
the UA_T2 watchdog, schedule ActivateFirmware behind the in-flight
CancelUpdate, or get the device reported as failed before the FD has
answered the CancelUpdate.
Answer such commands with COMMAND_NOT_EXPECTED, as DSP0267 asks of an
update agent that is not expecting them: handleRequest() now also
requires the DeviceUpdater to be in update mode, which it is from the
accepted RequestUpdate until CancelUpdate or ActivateFirmware is sent,
and logs the refused command. With that, the only way a device update
is reported after its CancelUpdate was queued is the response to that
CancelUpdate, so failDeviceUpdate() no longer reports a device it finds
out of update mode.
Tested: fw-update unit tests (device_updater_test) pass.
mves9-bmc-01 (Velorum, gbmc-release-26.36.22.0, switch MCU at
0033.01.0355, this series applied). A stale update session is
set up out of band with pldmtool (RequestUpdate,
PassComponentTable and a forced UpdateComponent of the
0033.01.0344.0000 image), which leaves the MCU in DOWNLOAD
asking the BMC for firmware data.
- With the 0355 package staged but not yet activated, the MCU's
RequestFirmwareData and the TransferComplete it sends when
that is refused are both answered with COMMAND_NOT_EXPECTED
and logged. Before this change they were dispatched to the
staged DeviceUpdater, which would have served data from the
wrong package and reported the device as failed before the
activation was even requested.
- Activating then: RequestUpdate is refused with CC 0x84, the
stale session is cancelled, the retried RequestUpdate is
accepted, the component is found up to date and the
activation ends Active within a second. Staging and
activating right after the stale session was created, without
the pause, completes the same way.
Google-Bug-Id: 571768585
Change-Id: Idc865d545d5e528c2a26d8a043952687b7c0e16c
Need meson and ninja. Alternatively, source an OpenBMC ARM/x86 SDK.
meson setup build && ninja -C build
The simplest way of running the tests is as described by the meson man page:
meson setup builddir && meson setup test -C builddir
Alternatively, tests can be run in the OpenBMC CI docker container, or with an OpenBMC x86 sdk(see below for x86 steps).
meson setup -Doe-sdk=enabled build ninja -C build test
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
rm /etc/default/pldmd systemctl restart pldmd
At a high-level, code in this repository belongs to one of the following three components.
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>
|----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 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 meson option has to be created in pldm/meson_options.txt with its mapped compiler flag to enable conditional compilation.
For consistency would recommend using “oem-<oem_name>”.
The pldm/meson.build and the corresponding source file(s) will need to incorporate the logic of adding its mapped compiler flag to allow conditional compilation of the code.
pldm daemon links against the libpldm library during compilation, For more information on libpldm please refer to libpldm
For more information on pldmtool please refer to plmdtool/README.md.
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.