control-plane-agent: implement `component-get-vpd` by hawkw · Pull Request #2650 · oxidecomputer/hubris

hawkw · 2026-08-18T18:18:48Z

Depends on oxidecomputer/management-gateway-service#500.
Depends on #2666.

This branch updates the gateway-messages dependency to pick up the new component-get-vpd API and associated messages for reading the vital product data from a component, and, well, implements that API. While the MGS PR better describes the layout of the various wire types, this is where most of the actual heavy lifting happened. Of the various attempts I've made at adding FRUID VPD to control-plane-agent, this is the first one I'm actually more or less satisfied with.

Fixes #2212.
Closes #2217.
Closes #2220.

jamesmunns · 2026-08-18T18:21:49Z

+
+        /// Bitmask for selecting *all* potential VPD register capa
+        pub const ANY_VPD_REGS: Self = Self(
+            // XXX(eliza): this might be less gross if we just used the


+1 from me here

hawkw

some notes for reviewers

hawkw · 2026-08-18T18:21:00Z

+pub struct PmbusVpd<'buf> {
+    /// `MFR_ID` (PMBus operation 0x99)
+    pub mfr_id: Option<&'buf [u8]>,
+    /// `MFR_MODEL` (PMBus operation 0x9A)
+    pub mfr_model: Option<&'buf [u8]>,
+    /// `MFR_REVISION` (PMBus operation 0x9B)
+    pub mfr_revision: Option<&'buf [u8]>,
+    /// `MFR_LOCATION` (PMBus operation 0x9C)
+    pub mfr_location: Option<&'buf [u8]>,
+    /// `MFR_DATE` (PMBus operation 0x9D)
+    pub mfr_date: Option<&'buf [u8]>,
+    /// `MFR_SERIAL` (PMBus operation 0x9E)
+    pub mfr_serial: Option<&'buf [u8]>,
+    pub ic_device_id: Option<&'buf [u8]>,
+    pub ic_device_rev: Option<&'buf [u8]>,
+}


this may look a bit weird; it's designed specifically to let you read all the 32-byte blocks into one statically allocated buffer and then the thing you actually serialize doesn't stack copy any of it.

hawkw · 2026-08-18T18:29:14Z

+        let mfr_range =
+            read(PmbusVpdCmd::MfrId, Capabilities::MFR_ID, buf, &mut off)?;
+        let model_range = read(
+            PmbusVpdCmd::MfrModel,
+            Capabilities::MFR_MODEL,
+            buf,
+            &mut off,
+        )?;
+        let rev_range = read(
+            PmbusVpdCmd::MfrRevision,
+            Capabilities::MFR_REVISION,
+            buf,
+            &mut off,
+        )?;
+        let location_range = read(
+            PmbusVpdCmd::MfrLocation,
+            Capabilities::MFR_LOCATION,
+            buf,
+            &mut off,
+        )?;
+        let date_range =
+            read(PmbusVpdCmd::MfrDate, Capabilities::MFR_DATE, buf, &mut off)?;
+        let serial_range = read(
+            PmbusVpdCmd::MfrSerial,
+            Capabilities::MFR_SERIAL,
+            buf,
+            &mut off,
+        )?;
+        let ic_id_range = read(
+            PmbusVpdCmd::IcDeviceId,
+            Capabilities::IC_DEVICE_ID,
+            buf,
+            &mut off,
+        )?;
+        let ic_rev_range = read(
+            PmbusVpdCmd::IcDeviceRev,
+            Capabilities::IC_DEVICE_REV,
+            buf,
+            &mut off,
+        )?;


unlike the status bits, we bail if any read attempt fails. i'm open to being talked out of that; my thinking here was mostly that for a lot of devices, values like the serial cannot be meaningfully interpreted without the model number, and so forth

hawkw · 2026-08-18T18:29:38Z

this probably needs to be renamed since it's now for all pmbus

hawkw · 2026-08-18T18:30:18Z

+        /// Bitmask for selecting *all* potential VPD register capa
+        pub const ANY_VPD_REGS: Self = Self(
+            // XXX(eliza): this might be less gross if we just used the
+            // bitflags crate for this...
+            Self::MFR_ID.0
+                | Self::MFR_MODEL.0
+                | Self::MFR_REVISION.0
+                | Self::MFR_SERIAL.0
+                | Self::MFR_LOCATION.0
+                | Self::MFR_DATE.0
+                | Self::IC_DEVICE_ID.0
+                | Self::IC_DEVICE_REV.0,
+        );


it might be worth turning this into a bitflags type so that this stuff is less ugly, idk...

hawkw · 2026-08-19T00:42:35Z

    Ok(())
 }
+
+/// Look at the `pmbus` crate metadata to see if a specific command is "Illegal"


All of this is a near-verbatim copy of James' code from control-plane-agent's build script, I just moved it in here so we can do it for each PMBus device's DeviceDescription rather than the rail bindings (which now reference this)

Should we just be doing this in build/i2c instead so it's covered by snapshots? If we're using it in both c-p-a and validate, it seems like it might be worth lifting.

c-p-a only depends on it through validate's API codegen, validate itself doesn't actually use most of that codegen. this relationship is kind of weird and confusing, but I would prefer not to address it in this branch.

hawkw · 2026-08-28T19:54:55Z

Poking at some devices on Cosmo, it seems the RAA229620As do not like the MFR_LOCATION and MFR_SERIAL commands; for everything else they appear to return some mostly-not-ASCII bytes:

eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x99 MFR_ID                    0xde 0x01 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_MODEL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9a MFR_MODEL                 0x01 0x00 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_REVISION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9b MFR_REVISION              0x01 0x00 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_LOCATION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_DATE
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9d MFR_DATE                  0x27 0x03 0x25 0x20                     |'.%
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C MFR_SERIAL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C IC_DEVICE_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xad IC_DEVICE_ID              0x00 0x9b 0xd2 0x49                     |...I
eliza@jeeves ~ $ pfexec humility pmbus -r VDDCR_CPU0_A0 -C IC_DEVICE_REV
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xae IC_DEVICE_REV             0x00 0x01 0x00 0x09                     |....
eliza@jeeves ~ $

The ISL68224s don't like MFR_LOCATION and MFR_SERIAL, but otherwise have some also-probably-not-intended-to-be-ASCII bytes to share with us:

eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x99 MFR_ID                    0xde 0x01 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_MODEL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9a MFR_MODEL                 0x03 0x00 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_REVISION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9b MFR_REVISION              0x01 0x00 0x00 0x00                     |....
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_LOCATION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_DATE
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9d MFR_DATE                  0x27 0x03 0x25 0x20                     |'.%
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C MFR_SERIAL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C IC_DEVICE_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xad IC_DEVICE_ID              0x00 0x52 0xd2 0x49                     |.R.I
eliza@jeeves ~ $ pfexec humility pmbus -r V1P1_SP5_A0 -C IC_DEVICE_REV
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xae IC_DEVICE_REV             0x04 0x00 0x00 0x02                     |....
eliza@jeeves ~ $

(this is also a Renesas part, so we can see that it at least has the same MFR_ID as the RAA229620A, and the other responses look similarish, so I imagine there is a renesas-y way you're supposed to interpret these)

The TPS546B24As dislike MFR_LOCATION and MFR_DATE, but happily return a bunch of mostly nulls for every command other than IC_DEVICE_ID and IC_DEVICE_REV, which are some mostly-ASCII bytes that are probably not ASCII on purpose:

eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x99 MFR_ID                    0x00 0x00 0x00                          |...
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_MODEL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9a MFR_MODEL                 0x00 0x00 0x00                          |...
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_REVISION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9b MFR_REVISION              0x00 0x00 0x00                          |...
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_LOCATION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_DATE
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C MFR_SERIAL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9e MFR_SERIAL                0x00 0x00 0x00                          |...
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C IC_DEVICE_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xad IC_DEVICE_ID              0x54 0x49 0x54 0x6b 0x24 0x41           |TITk$A
eliza@jeeves ~ $ pfexec humility pmbus -r V3P3_SP_A2 -C IC_DEVICE_REV
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0xae IC_DEVICE_REV             0x40 0x00                               |@.
eliza@jeeves ~ $

The BMR491 actually likes talking PMBus and gives us some nice strings; this works so well that the actual MGS request works without having to update things in pmbus to mark some commands as illegal:

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd U80
Aug 28 18:56:17.381 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 18:56:17.411 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID:       Flex
MFR_MODEL:    BMR4913203851
MFR_REVISION: R1C A
MFR_LOCATION: CB6
MFR_DATE:     2023-02-28
MFR_SERIAL:   FP1C481053
eliza@jeeves ~ $

The LM5066Is are basically only interested in telling us their MFR_ID, MFR_MODEL, and MFR_REVISION, which is a shame, since there's probably nothing in here to uniquely identify that instance of the part:

eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x99 MFR_ID                    0x54 0x49 0x00                          |TI.
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_MODEL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9a MFR_MODEL                 0x4c 0x4d 0x35 0x30 0x36 0x36 0x49 0x00
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_REVISION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9b MFR_REVISION              0x41 0x41                               |AA
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_LOCATION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_DATE
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C MFR_SERIAL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C IC_DEVICE_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_FAN_EAST -C IC_DEVICE_REV
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $

Using the technique of "knowing that this happens to be a Texas Instruments part" and that the MFR_ID is TI\0, I am guessing that these are intended to be ASCII strings which are...sometimes null-terminated?.

The ADM1272 gives us some rather nice clearly ASCII strings back, but is unwilling to disclose its MFR_LOCATION and MFR_SERIAL, and is also unwilling to share its IC_DEVICE_ID or IC_DEVICE_REV:

eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x99 MFR_ID                    0x41 0x44 0x49                          |ADI
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_MODEL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9a MFR_MODEL                 0x41 0x44 0x4d 0x31 0x32 0x37 0x32 0x2d |ADM1272-
                               0x32 0x41                               |2A
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_REVISION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9b MFR_REVISION              0x32 0x35                               |25
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_LOCATION
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_DATE
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
0x9d MFR_DATE                  0x32 0x30 0x30 0x34 0x31 0x35           |200415
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C MFR_SERIAL
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C IC_DEVICE_ID
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $ pfexec humility pmbus -r V54P5_IBC_A3 -C IC_DEVICE_REV
humility: WARNING: archive in environment variable overriding archive in environment file
humility: attached to 1fc9:0143:NE5MJWEAVZOK0 via CMSIS-DAP
eliza@jeeves ~ $

So we shall want to go and edit pmbus to mark some of the commands that these devices find distasteful as illegal.

Based on some testing I did on a Cosmo in the lab, there are a variety of VPD-related `MFR_$whatever` and `IC_DEVICE_{ID, REV}` commands that various devices dislike. See [this comment][1] for details. To prevent them from NACKing us and setting `STATUS_CML` a bunch, and to better support the codegen changes I'm working on in oxidecomputer/hubris#2650, this commit updates the config files for those devices to mark the commands they find distasteful as `Illegal`. [1]: oxidecomputer/hubris#2650 (comment)

hawkw · 2026-08-28T22:33:10Z

Progress has been made!

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J200/U2'
Aug 28 22:28:59.698 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:28:59.728 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000026:003:2JHM84Y0
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J209/U2'
Aug 28 22:29:28.415 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:29:28.445 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000026:003:21MVG4F1
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J34/U2'
Aug 28 22:29:55.168 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:29:55.198 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: unsupported request for this SP component
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J34/U1'
Aug 28 22:30:10.157 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:30:10.187 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
FAN TRAY:  0XV2:991-0000151:003:2W6DXFGF
VPD BOARD: 0XV2:913-0000027:001:BRM40250270
FANS: [
  0XV2:418-0000005:001:FAN3924003S
  0XV2:418-0000005:001:FAN3924003W
  0XV2:418-0000005:001:FAN3924003V
]

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U32'
Aug 28 22:30:47.567 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:30:47.597 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000023:002:2MX4G4PJ
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U80'
Aug 28 22:31:10.699 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:31:10.729 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID:       Flex
MFR_MODEL:    BMR4913203851
MFR_REVISION: R1C A
MFR_LOCATION: CB6
MFR_DATE:     2023-02-28
MFR_SERIAL:   FP1C481053
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U71'
Aug 28 22:31:13.996 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:31:14.026 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: vpd: vpd device is unavailable
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U79'
Aug 28 22:31:22.306 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 22:31:22.336 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: vpd: vpd device is unavailable
eliza@jeeves ~ $

hawkw · 2026-08-29T00:08:00Z

Testing the latest commit (257c6a5) on mb-0 in the lab:

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J200/U2'
Aug 28 23:34:19.197 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:34:19.228 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000026:003:2JHM84Y0
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J209/U2'
Aug 28 23:34:28.441 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:34:28.471 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000026:003:21MVG4F1
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J34/U1'
Aug 28 23:34:56.337 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:34:56.367 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
fan tray    : 0XV2:991-0000151:003:2W6DXFGF
  VPD board : 0XV2:913-0000027:001:BRM40250270
  fan 0     : 0XV2:418-0000005:001:FAN3924003S
  fan 1     : 0XV2:418-0000005:001:FAN3924003W
  fan 2     : 0XV2:418-0000005:001:FAN3924003V

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'J44/U1'
Aug 28 23:36:09.352 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:36:09.383 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
device ID : 0x1701
  EEPROM1 : 0x7aa5
  EEPROM2 : 0x590f
  EEPROM3 : 0x69a4

eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U80'
Aug 28 23:36:24.176 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:36:24.205 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID        : Flex
MFR_MODEL     : BMR4913203851
MFR_REVISION  : R1C A
MFR_LOCATION  : CB6
MFR_DATE      : 2023-02-28
MFR_SERIAL    : FP1C481053
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U71'
Aug 28 23:36:29.635 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:36:29.665 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID        : TI
MFR_MODEL     : LM5066I
MFR_REVISION  : AA
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U79'
Aug 28 23:36:32.660 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:36:32.690 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID        : ADI
MFR_MODEL     : ADM1272-2A
MFR_REVISION  : 25
MFR_DATE      : 200415
eliza@jeeves ~ $ ./faux-mgs-vpd --interface e1000g0 --discovery-addr '[fe80::aa40:25ff:fe04:1200]:11111' component-vpd 'U123'
Aug 28 23:37:09.482 INFO creating SP handle on interface e1000g0, component: faux-mgs
Aug 28 23:37:09.513 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe04:1200%2]:11111, interface: e1000g0, socket: control-plane-agent, component: faux-mgs
MFR_ID        :
MFR_MODEL     :
MFR_REVISION  :
MFR_SERIAL    :
IC_DEVICE_ID  : TITk$A
IC_DEVICE_REV : @
eliza@jeeves ~ $

I still need to test a PSC and a Sidecar, but that'll have to wait until I get some racklette time. The faux-mgs output for the TPS546B24A's PMBus EEPROM is a little bit silly, because it's trying to interpret it as ASCII because it just so happens to be valid ASCII, which is kinda a bummer, but, meh.

hawkw · 2026-08-29T00:15:52Z

(To anyone scared about how this branch is adding 3000 lines of code, a lot of it is that I added I2C codegen snapshot tests for gimletlet, since it's representative of boards that don't have any power/pmbus devices and therefore hit some unused arguments in the codegen)

jamesmunns

I think these changes are good to have, I made a variety of nit comments, some of them might be nice to fix, some of them are more just commentary.

jamesmunns · 2026-09-01T10:55:41Z

+        match index {
+            0 => Some(
+                // Front FPGA virtual mux
+                I2cDevice::new(


Not something to fix this PR, but I feel like it would be nice if someday we didn't re-generate the whole I2cDevice::new and instead called the constructor function instead. The optimizer is probably going to do the same anyway, but it would make the snapshots shorter (and probably generate less code for rustc to chew on).

jamesmunns · 2026-09-01T11:03:32Z

+            .map_err(SpError::Vpd)
+    };
+    let vpd = Tmp117Identity {
+        id: read(0x0f_u8)?,


Do we not have driver methods for these register IDs? Slightly magic numbers.

huh, apparently there is actually a Tmp117::read_eeprom, but host-sp-comms, which I blatantly copied this from...doesn't use them:

hubris/task/host-sp-comms/src/bsp/cosmo_ab.rs

Lines 452 to 455 in 4113fbc

*id = dev.read_reg(0x0Fu8)?;

*eeprom1 = dev.read_reg(0x05u8)?;

*eeprom2 = dev.read_reg(0x06u8)?;

*eeprom3 = dev.read_reg(0x08u8)?;

I should probably make this use the driver...

hmm, upon re-considering what §2.11 RDD 360 has to say about this device, I begin to wonder whether whether the way we are currently representing it, which again I stole from hostess-pecans, may in fact be basically the most endianness-confusion-y possible way to represent it...

may in fact be basically the most endianness-confusion-y possible

by which i mean, when i was reading this code, i got confused about what the endianness was

ah, upon consulting the git blame, this is just because Bryan appears to have written the TMP117 driver some time before the advent of <u{16, 32, 64}>::from_{be,le}_bytes...

what if i rewrite the whole driver

OOPS I REWROTE THE WHOLE DRIVER (AND ASLSO ALL THE CODE THAT USES IT): 248b890

that probably should be factored out into its own PR; sorry james

LOL NOTHING ELSE ACTUALLY USES THE Tmp117::read_eeprom FUNCTION ANYWAY so i'm just gonna change it to do what i want it to

UPDATE whoops i was wrong about this, something was using it and it was goddamn DONGLET i hate everthing

So, after #2666, I think this will be a bit nicer, but I'd rather not have this PR depend on that one, if you're okay with that?

jamesmunns · 2026-09-01T11:06:48Z

        self.power_state_impl()
    }

+    fn power_state_with_reason(


Why is this RequestUnsupportedForSp for every instance?

Ah, this is a fill-in because #2515 hasn't landed yet.

Added a comment here in case this is something to be concerned about: #2515 (comment)

Yeah. I think we are okay with merging Evan's API unimplemented, since we are not actually using it yet in any other upstack software...

jamesmunns · 2026-09-01T11:10:11Z

    Ok(())
 }
+
+/// Look at the `pmbus` crate metadata to see if a specific command is "Illegal"


Should we just be doing this in build/i2c instead so it's covered by snapshots? If we're using it in both c-p-a and validate, it seems like it might be worth lifting.

jamesmunns · 2026-09-01T11:20:30Z

    pub device_id: Option<String>,
    pub name: Option<String>,
    pub validate_with_raw_read: bool,
+    pub vpd: EepromVpd,


Interestingly, we don't have any snapshot coverage for I2cDeviceDescription or device_descriptions(). We might want a similar snapshot to what we have with I2cSensorsDescription.

hawkw · 2026-09-03T19:05:05Z

Ugh, looks like the code for reading the TMP117 eeproms is endianness-confused:

eliza@castle ~ $ pilot sp exec -e 'component-vpd J71' BRM44220004
Sep 03 19:03:38.008 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 03 19:03:38.010 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe05:200%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
device ID : 0x1701
  EEPROM1 : 0x7aa5
  EEPROM2 : 0x8b0f
  EEPROM3 : 0x0000

so actually, we probably should merge #2666 and then update this change to use that.

hawkw · 2026-09-03T20:53:02Z

Ugh, okay, so having finally gotten as far as testing this on a PSC:

eliza@castle ~ $ pilot sp exec -e 'inventory' BRM11230017
Sep 03 20:43:34.910 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 03 20:43:34.913 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
COMPONENT        STATUS       DEVICE           DESCRIPTION (CAPABILITIES)
sp               Present      sp               Service Processor (DeviceCapabilities(1))
system-led       Present      system-led       System attention LED (DeviceCapabilities(8))
U31              Present      tmp116           Temperature sensor (DeviceCapabilities(0))
U32              Present      at24csw080       FRU ID EEPROM (DeviceCapabilities(16))
PSU0/ID          Present      m24c02           PSU 0 EEPROM (DeviceCapabilities(0))
PSU0             Present      mwocp68          PSU 0 MCU (DeviceCapabilities(50))
PSU1/ID          NotPresent   m24c02           PSU 1 EEPROM (DeviceCapabilities(0))
PSU1             NotPresent   mwocp68          PSU 1 MCU (DeviceCapabilities(50))
PSU2/ID          Present      m24c02           PSU 2 EEPROM (DeviceCapabilities(0))
PSU2             Present      mwocp68          PSU 2 MCU (DeviceCapabilities(50))
PSU3/ID          NotPresent   m24c02           PSU 3 EEPROM (DeviceCapabilities(0))
PSU3             NotPresent   mwocp68          PSU 3 MCU (DeviceCapabilities(50))
PSU4/ID          NotPresent   m24c02           PSU 4 EEPROM (DeviceCapabilities(0))
PSU4             NotPresent   mwocp68          PSU 4 MCU (DeviceCapabilities(50))
PSU5/ID          NotPresent   m24c02           PSU 5 EEPROM (DeviceCapabilities(0))
PSU5             NotPresent   mwocp68          PSU 5 MCU (DeviceCapabilities(50))
eliza@castle ~ $ pilot sp exec -e 'component-vpd PSU0' BRM11230017
Sep 03 20:44:10.812 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 03 20:44:10.814 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: vpd: vpd device is unavailable
eliza@castle ~ $ pilot sp exec -e 'component-vpd U31' BRM11230017
Sep 03 20:47:58.429 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 03 20:47:58.432 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
Error: Error response from SP: unsupported request for this SP component
eliza@castle ~ $ pilot sp exec -e 'component-vpd U32' BRM11230017
Sep 03 20:48:08.652 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 03 20:48:08.655 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
0XV2:913-0000003:009:BRM11230017
eliza@castle ~ $

i have clearly screwed up something such that the TMP116 doesn't advertise itself as a VPD device, and it doesn't work
we are trying to read at least one command that the MWOCP68 doesn't like and which has not been marked as illegal in pmbus yet
i should probably figure out what's actually stored in the M24C02 EEPROMs and whether we should read them...

hawkw · 2026-09-03T20:55:00Z

i should probably figure out what's actually stored in the M24C02 EEPROMs and whether we should read them...

oh good:

hubris/drv/i2c-devices/src/m24c02.rs

Lines 41 to 51 in 1cbf835

    
           impl Validate<Error> for M24C02 { 
        
               fn validate(device: &I2cDevice) -> Result<bool, Error> { 
        
                   // Attempt to read a byte at address 0 
        
                   // 
        
                   // TODO: actually check against an expected pattern 
        
                   device 
        
                       .read_reg::<u8, u8>(0) 
        
                       .map_err(|e| Error::BadValidation { code: e })?; 
        
                   Ok(true) 
        
               } 
        
           }

hawkw · 2026-09-03T22:17:07Z

we are trying to read at least one command that the MWOCP68 doesn't like and which has not been marked as illegal in pmbus yet

Ah, I think pmbus should mark IC_DEVICE_ID and IC_DEVICE_REG as Illegal for the Murata rectifiers; neither ACAN-114 nor ACAN-157 mention those commands. Opened oxidecomputer/pmbus#39

hawkw · 2026-09-04T17:38:32Z

Good news: after updating to oxidecomputer/pmbus#39, the MWOCP68s work! Bad news: the temp sensor is still endianness-confused-y?

eliza@castle ~ $ pilot sp exec -e 'component-vpd U31' BRM11230017
Sep 04 17:36:36.365 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 04 17:36:36.406 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
device ID : 0x1701
EEPROM1   : 0x7ba5
EEPROM2   : 0x820f
EEPROM3   : 0xc7b1

eliza@castle ~ $ pilot sp exec -e 'component-vpd PSU0' BRM11230017
Sep 04 17:37:01.120 INFO creating SP handle on interface london_sw0tp0, component: faux-mgs
Sep 04 17:37:01.123 INFO initial discovery complete, addr: [fe80::aa40:25ff:fe06:108%3]:11111, interface: london_sw0tp0, socket: control-plane-agent, component: faux-mgs
MFR_ID        : Murata-PS
MFR_MODEL     : MWOCP68-3600-D-RM
MFR_REVISION  : 0762-0701-0000
MFR_LOCATION  : China
MFR_DATE      : 2111
MFR_SERIAL    : LL2111Q9002T
eliza@castle ~ $

hawkw · 2026-09-04T19:03:56Z

turns out the temp sensor endianness mess was much sillier than i thought: 9b3e06b

oxidecomputer/management-gateway-service#500

…5df9a38eed1 picks up the merged version from `main`

jamesmunns reviewed Aug 18, 2026

View reviewed changes

hawkw commented Aug 18, 2026

View reviewed changes

hawkw commented Aug 19, 2026

View reviewed changes

Comment thread task/control-plane-agent/src/inventory.rs Outdated

hawkw mentioned this pull request Aug 28, 2026

Mark unsupported VPD commands as Illegal oxidecomputer/pmbus#38

Merged

hawkw mentioned this pull request Aug 28, 2026

Add component-get-vpd request oxidecomputer/management-gateway-service#500

Merged

hawkw changed the title ~~[wip] generic API for reading PMBus VPD~~ control-plane-agent: implement component-get-vpd Aug 29, 2026

hawkw marked this pull request as ready for review August 29, 2026 00:14

hawkw requested review from evan-oxide, jamesmunns and jgallagher August 29, 2026 00:14

hawkw added control-plane-agent fault-management Everything related to the Oxide's Fault Management architecture implementation labels Aug 29, 2026

jamesmunns mentioned this pull request Sep 1, 2026

Report reason for power state change #2515

Open

2 tasks

jamesmunns approved these changes Sep 1, 2026

View reviewed changes

hawkw force-pushed the eliza/pmbus-vpd-3 branch from 653d63c to 1a64cdd Compare September 1, 2026 23:37

hawkw mentioned this pull request Sep 1, 2026

drv-i2c-devices: make TMP117 driver nicer #2666

Merged

hawkw force-pushed the eliza/pmbus-vpd-3 branch 2 times, most recently from 57150bb to c0067fb Compare September 4, 2026 18:20

hawkw added 25 commits September 4, 2026 13:18

wire it up

dbc18e1

redo vpd reader to work with

b441939

oxidecomputer/management-gateway-service#500

oops

96bddd2

draw much of the remaining owl

ac6c206

wip other VPD types

0dceceb

reticulating

586f4df

normal eeproms work now

a610f19

roll pmbus for new stuff

dc271be

do the temp sensors

29f488f

post merge fixy-uppy

26691f4

fix gimletlet

ecbafac

tidy up a bit

86e8ea0

also use that here

442ef5f

make EEPROM VPD config more explicit

dd37bff

fix bonus whitespace

1631cf8

oops the toml keys are hyphenated

49935cb

blarg

b349e0b

update MGS, fix some stuff

4d25c9b

renaming things, also support tmp116

417731c

update mgs

f361de9

use fixed tmp117 driver

d344334

update to oxidecomputer/pmbus@9447159

494735e

add a quick ringbuf

28918a9

handle register naks nicer

74eb7a7

you cant type lol

0ac4418

hawkw force-pushed the eliza/pmbus-vpd-3 branch from 746d161 to 0ac4418 Compare September 4, 2026 20:23

oxidecomputer/management-gatway-service@438cd185666d5f164548885873f0f…

3d985c9

…5df9a38eed1 picks up the merged version from `main`

hawkw enabled auto-merge (squash) September 4, 2026 20:33

hawkw merged commit 0d1ba04 into master Sep 4, 2026
190 checks passed

hawkw deleted the eliza/pmbus-vpd-3 branch September 4, 2026 20:51

	*id = dev.read_reg(0x0Fu8)?;
	*eeprom1 = dev.read_reg(0x05u8)?;
	*eeprom2 = dev.read_reg(0x06u8)?;
	*eeprom3 = dev.read_reg(0x08u8)?;

Uh oh!

Conversation

hawkw commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hawkw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

hawkw commented Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hawkw commented Aug 28, 2026

Uh oh!

hawkw commented Aug 29, 2026

Uh oh!

hawkw commented Aug 29, 2026

Uh oh!

jamesmunns left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hawkw commented Sep 3, 2026

Uh oh!

hawkw commented Sep 3, 2026

hawkw commented Aug 18, 2026 •

edited

Loading

hawkw commented Aug 28, 2026 •

edited

Loading

hawkw commented Sep 3, 2026 •

edited

Loading

hawkw commented Sep 4, 2026 •

edited

Loading