[a9h74j]

This is something which worries me with Oxide using I2C (according to their board bring-up podcast), and using an auto-direction-switching level-shifter on the I2C bus. I hope and I am sure they can make it work, but to me that comes closer to violating a (core?) value of determinism and observability. Of course if it is only one well-studied component or two, perhaps out of design/supply necessity, this might be a very small risk in the larger scope.

[bcantrill]

It is indeed a very small risk in the larger scope -- and besides, using I2C isn't optional: all of the devices on the board (from converters/regulators, temp sensors, clock generators and fan controllers to CPUs, DIMMs, NICs, and NVMe drives) have I2C (or I2C-based) management interfaces. If you'd like more concrete detail, take a look at the Hubris app definition for our Gimlet board.[0]

[0] https://github.com/oxidecomputer/hubris/blob/master/app/giml...

[a9h74j]

Yes, clearly I2C, properly employed, adds far more to observability than it might, in principle, very rarely take away. And of course: a) Oxide is not the first to use the same components; b) Oxide is past the point of bring-up problems with a previously untried component; c) Oxide will have done all sorts of power cycling and confidence-building; so d) common-mode failures can likely be ruled out; and e) (I presume) any rare bus hang or error can itself be detected and reported.

[AdamH12113]

Are you sure it’s really I2C? Servers often use PMBus for power supply management, which uses the I2C physical layer but the (better-behaved) SMBus link layer.

I’m not familiar with Oxide, but the I2C physical layer is just a pair of open-drain signals, so I wouldn’t worry about a level-shifter too much.