Page MenuHomeFreeBSD

mpi3mr: Fix firmware package version reporting from active flash partition
Needs ReviewPublic

Authored by chandrakanth.patil_broadcom.com on Sun, Oct 4, 1:24 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 9, 3:01 PM
Unknown Object (File)
Fri, Oct 9, 12:25 PM
Unknown Object (File)
Thu, Oct 8, 12:06 PM
Unknown Object (File)
Wed, Oct 7, 11:14 PM
Unknown Object (File)
Wed, Oct 7, 10:22 PM
Unknown Object (File)
Wed, Oct 7, 9:43 PM
Unknown Object (File)
Wed, Oct 7, 1:55 PM
Unknown Object (File)
Wed, Oct 7, 6:37 AM
Subscribers
None

Details

Summary

During controller initialization and post-reset, the driver retrieves
and logs the firmware package version. Previously, the component image
upload request used incorrect offset and signature parameters, preventing
the driver from reading the complete package manifest.

In addition, after online firmware updates or when booting in dual-image
environments, the controller can execute from either the primary or
secondary flash partition. The driver previously queried only the primary
partition without evaluating the active boot status in the controller
exceptions flags, resulting in reporting stale firmware package versions.

Update the upload request to properly fetch the manifest structure from the
currently active boot partition (primary or secondary) based on controller
boot status flags, and format the complete package version into the log.

Test Plan
  • Clean build with WERROR=-Werror across FreeBSD 16, 15, and 14 with INVARIANTS/WITNESS enabled; git bisect verified.
  • Tested controller initialization and online firmware updates on SAS4116/SAS5116 controllers.
  • Verified that the firmware package version is queried from the active flash partition and logged accurately across boots and resets.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

sys/dev/mpi3mr/mpi3mr.c
2148

Don't these need the htole() macros to make them big endian safe?

sys/dev/mpi3mr/mpi3mr.c
2183–2184

These are multi-byte fields, don't they need le16toh to not break big endian?

sys/dev/mpi3mr/mpi3mr.c
2148

Don't these need the htole() macros to make them big endian safe?

Thanks. I will add htole32() for ImageOffset and SegmentSize (as well as Signature1) in V2 patch

2183–2184

These are multi-byte fields, don't they need le16toh to not break big endian?

Thanks. I will add le16toh() for CustomerID and BuildNum in V2 patch. PhaseMinor is a U8, so no conversion is needed there.