Tags: oxidecomputer/hubris
Tags
Update to Brussels 0.6.0 (#2582) This PR updates the release flow to pull in oxidecomputer/brussels#21. This should be the last release process change needed before we can integrate Brussels with the omicron releng tooling! This also changes the configuration to match the current behavior of sprot-release: sidecar and observer images are not included in the CoRIM measurements anymore, and reverso and observer images will not be pulled into omicron.
Update versioning scheme (#2562) This PR updates Brussels and the release workflow to support the proposed versioning scheme in [RFD 705](https://rfd.shared.oxide.computer/rfd/0705) (tl;dr moving the version number to the minor number rather than the patch, to support backports). The new "Custom version number" field in the release workflow will allow both to migrate to the new versioning scheme, and to issue patch releases (where we'll want to bump the patch number rather than let Brussels bump the minor number).
Tiny build-time optimization for config handling (#2526) This change reworks build_notifications from re-loading the task config from an environment variable, and then parsing as toml, once for every task. Instead, we now just get and parse the config once, and grab what we want from the pre-parsed table. This was noticed incidentally while debugging #2524
cosmo_seq: mask STATUS_CML bit 1 to not get annoying pmbus alerts abo… …ut it (#2520) It turns out that PMBus devices like to set this bit bascially any time they saw any kind of I2C behavior that makes them feel uncomfortable. We probably don't want to produce an ereport every time an I2C Thing makes a VRM uncomfortable. So this commit masks out PMBus alerts for STATUS_CML's "other communication fault" bit, since it's annoying and not a big deal. This branch does a bit of extra refactoring on top of the change from #2511. Since we are now setting even more `SMBALERT_MASK`s in `initialize_pmbus_alerts`, I thought it would be nice to have some shared utilities for trying to do this.
Set VLAN FID in configuration (#2501) The MAC tables in the VSC7448 contain a map from `(source mac, filtering id)` tuples to port. The filtering id field ("FID") allows for VLAN-aware learning. Unfortunately, you have to explicitly set a flag to copy the classified VID to the FID. If you're in a situation where you see the same MAC address on multiple ports (which are on different VLANs), properly setting the FID is load-bearing; otherwise, that MAC address will randomly wander between those ports, and packets directed to that MAC address have unpredictable deliverability. Fixes oxidecomputer/mfg#224
PreviousNext