Skip to content

Murata PSUs dislike IC_DEVICE_{ID, REV} - #39

Merged
hawkw merged 1 commit into
masterfrom
eliza/mwocp-unsupported
Sep 3, 2026
Merged

Murata PSUs dislike IC_DEVICE_{ID, REV}#39
hawkw merged 1 commit into
masterfrom
eliza/mwocp-unsupported

Conversation

@hawkw

@hawkw hawkw commented Sep 3, 2026

Copy link
Copy Markdown
Member

No description provided.

@hawkw
hawkw merged commit 9447159 into master Sep 3, 2026
8 checks passed
hawkw added a commit to oxidecomputer/management-gateway-service that referenced this pull request Sep 4, 2026
Closes #435 (which this obsoletes).

This branch adds a new `component-get-vpd` RPC that allows MGS to read
the vital product data (VPD) for the requested SP component. The SP
components that have VPD advertise this property via the `HAS_VPD`
capabilities bit. The wire types allow reading a few different kinds of
VPD:

- A variety of PMBus commands for PMBus devices. Hubris will determine
  which of the commands a given PMBus device supports based on 
  oxidecomputer/pmbus#38 and oxidecomputer/pmbus#39. This is
  potentially quite large, but usually isn't, based on what the device
  actually supports.
- An Oxide barcode from a VPD EEPROM, which may be in either the 0XV1,
  0XV2, or MPN1 formats as defined in [RFD 308].
- A Gimlet or Cosmo fan tray EEPROM, which contains barcodes for the
  fan tray assembly, the VPD board, and each individual fan on the
  assembly.
- A TMP117 temperature sensor's little EEPROM thingy.

The way this all works is designed to allow Hubris to avoid
constructing these on the stack. In particular, the fan tray VPD may be
"up to 640 bytes or more", given that the only real length limit on the
MPN1 barcodes is that the whole thing will not be in excess of 128
bytes, and we may have a fan tray whose EEPROM contains five MPN1
barcodes, which is a lot. The PMBus VPD is also Not Small. Therefore,
all the wire types are designed in such a way so that Hubris can read
data _into_ a single scratch instance of the wire type which lives in a
static, and then serialize from that straight into the trailing data of
a response. This felt like the best compromise between wanting to use
`hubpack` for serialization and not building really giant structs on
the stack in `control-plane-agent`.

This all probably makes a bit more sense if you also read the
corresponding Hubris PR oxidecomputer/hubris#2650.

[RFD 308]: https://rfd.shared.oxide.computer/rfd/0308
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