Skip to content

gateway: add sp_component_vpd_get - #11273

Merged
hawkw merged 9 commits into
mainfrom
eliza/mgs-vpd
Sep 11, 2026
Merged

hawkw merged 9 commits into
mainfrom
eliza/mgs-vpd

Conversation

@hawkw

@hawkw hawkw commented Sep 9, 2026

Copy link
Copy Markdown
Member

Now that oxidecomputer/hubris#2650 and oxidecomputer/management-gateway-service#500 have merged, we now have a gateway-sp-comms API for reading VPD from individual components exposed by the SP. This includes PMBus devices (including, importantly, the rectifiers in the power shelf) and FRU EEPROMs, such as those on fan modules, sharkfins, and so forth. This branch updates our dependency on gateway-sp-comms to oxidecomputer/management-gateway-service@438cd18, and adds an HTTP API to MGS for Nexus to actually read component VPD.

One note here is that, because I implemented the gateway-messages and Hubris side of this in a way that allows hubris to read the raw VPD EEPROM contents into trailing data,1 Hubris isn't parsing barcodes the way it does for the baseboard VPD. Thus, MGS has to do this parsing, which this branch implements. This is a bit duplicative, but I don't hate doing it here.

Since this updates MGS, it also picks up some other new APIs, but I haven't added HTTP API endpoints for them. I'd prefer to do that separately.

Closes #11256

Footnotes

  1. Which was a design decision I ended up making largely to handle the fact that parsing an MPN1 barcode, where the only length limit is that the entire barcode will not exceed 128 bytes, would require representing each of the 4 pieces as a 128b array, making the barcode 512B long and making a fan tray with 3 MPN1 barcodes not fit in a MGS datagram... ↩

@hawkw
hawkw requested review from jgallagher and smklein September 9, 2026 21:10
)]
pub struct PmbusDevice {
/// `MFR_ID` (PMBus command 0x99).
pub mfr_id: Option<Vec<u8>>,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Entirely for my own curiosity - who/what is going to end up parsing the contents of these fields?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with these is that their contents vary a lot based on the device. In the immediate future, my plans are mainly to use the PMBus VPD fields for the MWOCP68/MWOCP67 rectifiers in the gateway hardware-component metrics for the power shelf, and use them to start inventorying the PSUs (see #11047). The PSUs are currently the only field-replaceable units whose identity is determined via these PMBus commands, so I think we won't immediately be reading them for other devices, but we may eventually.

@hawkw
hawkw enabled auto-merge (squash) September 11, 2026 20:12
@hawkw
hawkw merged commit 257dbb3 into main Sep 11, 2026
20 checks passed
@hawkw
hawkw deleted the eliza/mgs-vpd branch September 11, 2026 21:04
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.

Gateway API HTTP API(s) for component VPD

2 participants