Skip to content

Feature/hpm improvements - #210

Merged
hthiery merged 12 commits into
masterfrom
feature/hpm-improvements
Oct 6, 2026
Merged

hthiery merged 12 commits into
masterfrom
feature/hpm-improvements

Conversation

@hthiery

@hthiery hthiery commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

No description provided.

hthiery and others added 12 commits October 6, 2026 14:25
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
The spelling of 'preparation' was fixed in the general component
properties, update the test accordingly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
The 'hpm check' command does not need a connection, so no Ipmi object is
passed to the command function. Calling open_upgrade_image() on it
failed with an AttributeError. Open the upgrade image directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
A file that is not an HPM.1 upgrade image (e.g. a gzip compressed
package) was parsed anyway and failed later with a misleading BCD
decoding error of the version fields. Check the 'PICMGFWU' signature of
the image header and raise an HpmError.

ipmitool.py prints an HpmError as error message instead of a traceback.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
The bits of the global capabilities of the Get Target Upgrade
Capabilities response were decoded in reverse order. Bit 0 is the IPMC
self-test support and bit 7 'firmware upgrade undesirable', as defined
by HPM.1 and also used by ipmitool.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
HPM.1 defines only three action record types in an upgrade image:
backup components, prepare components and upload firmware image. The
'upload for compare' is no record type, it is an action of the Initiate
Upgrade Action command. Remove the UpgradeActionRecordUploadForCompare
class, a record with a reserved type raises an HpmError.

Further fixes of the action records:
- a record can be created without data
- a truncated firmware image raises an HpmError
- strip the '\x00' padding of the firmware description string
- print the firmware version, description and length of the upload
  record
- use the HPM.1 names of the action types

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Add compare_component_from_image() and compare_component_from_file()
to compare the firmware of an image with the active copy of a
component. In compare mode the upgrade stage skips the backup and
prepare actions and uploads the firmware image with the 'upload for
compare' action.

The upgrade stage maps the action record types to the actions of the
Initiate Upgrade Action command instead of using the record type
directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
The MD5 checksum was never verified and the calculated checksum was
always None, because the return value of hashlib's update() was used
instead of the digest. Calculate the digest and raise an HpmError on a
mismatch. The checksum is verified after the image header, so a file
that is no upgrade image is reported by the signature check.

Read the file with a context manager, a missing file raised a NameError
after printing an error message.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
On a timeout of the Upload Firmware Block command the retry counter was
decremented, but the block was not sent again. The next block was
uploaded instead and the firmware data of the timed out block was
missing. Send the same block again, up to 'retry' times.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
wait_until_new_firmware_comes_up() polled the controller until the
timeout, also when the controller answered again. Return as soon as the
controller answers after it was not accessible. Before it is not
accessible, an answer may still be from the old firmware, so wait until
the timeout in this case.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
The firmware block size was fixed at 22 bytes. An IPMB message has 25
bytes request data, 2 bytes are used by the PICMG identifier and the
block number, so a block can hold 23 bytes. A message sent through two
bridges is embedded in a Send Message request on the IPMB and the fixed
size was too large.

Determine the block size like ipmitool:
- a message sent directly by the interface is limited by the interface,
  the new MAX_REQUEST_DATA_SIZE attribute (38 bytes for RMCP)
- a bridged message is limited by the IPMB message length, 8 bytes less
  for each additional bridge

If the target rejects the length of the first block (CC 0xc7 or 0xc8),
the block size is reduced until a block is accepted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Check if the component is in the image before the firmware upgrade is
aborted, so nothing is sent to the controller on a wrong component.
The error message lists the components of the image.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
@coveralls

coveralls commented Oct 6, 2026 •

Copy link
Copy Markdown

Coverage Status

coverage: 91.395% (+0.08%) from 91.311% — feature/hpm-improvements into master

@hthiery
hthiery force-pushed the feature/hpm-improvements branch from 7a4cb3b to 4909944 Compare October 6, 2026 13:22
@hthiery
hthiery merged commit 4ecefad into master Oct 6, 2026
25 of 26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants