Tags: oxidecomputer/hubris
Tags
Skip programming erased pages Flash memory is set to all `1` when erased. We have to erase pages before writing so writing pages full of `1` is not a good use of CPU time. Before real 2m0.817s user 0m4.380s sys 0m3.305s After real 1m44.543s user 0m3.586s sys 0m2.710s
Only read DIMMs in A0HP (#2287) This includes a workaround for oxidecomputer/quartz#434; and has FPGA fixes for oxidecomputer/quartz#437 and oxidecomputer/quartz#435 which resulted in topo not showing the correct number of dimms or the correct information for the dimms. I've cycled this ~100 boots without seeing any dimm training failures so this seems to be reliable. --------- Co-authored-by: Nathanael Huffman <nathanael@oxidecomputer.com>
Tag releases with Brussels (#2270) The first phase of the SP and RoT release process is to determine the version number, tag the latest commit with that version number, and push it to kick off the build. To start fully automating the SP release process, this PR replaces this phase with a single GitHub Actions workflow that can be started through the UI: <img width="933" height="477" alt="image" src="https://github.com/user-attachments/assets/2fb0b680-b4ac-41d7-a37a-6455bafd4735" /> <br/><br/> This uses [Brussels](https://github.com/oxidecomputer/brussels), the new SP and RoT release tooling I'm working on, and in particular the changes I introduced in oxidecomputer/brussels#3. Brussels is fetched as a pre-built binary from its GitHub Release to ensure it doesn't delay the release process by trying to compile it. The `brussels init` command will be executed in its own job as the first build step. It will look at all the existing tags to determine what is the next version number, calculate the tag name, and expose all of that information into `GITHUB_OUTPUT` to let the rest of the workflow know the version to use. It will also write all the metadata it gathered in a `brussels-manifest.json` file, so that future Brussels steps can reference that metadata. The tag will not be created and pushed by `brussels init`. Instead, we will let the "create GitHub Release" step at the end of the workflow create the tag on its own, as GitHub will do so when creating a release without an underlying tag. While I was there, I also changed the build process to inject the version number directly during the build, instead of waiting for permslip to add it as part of the signature process. This is just the first improvement to the SP release process that I'm going to do. The end goal is for SP releases to be fully automated (either by requiring a single button click or by putting the whole release process in a cronjob). Note that by default the workflow will use the latest release of Brussels. An optional field when starting the workflow run lets you download Brussels from a CI job in the Brussels repository. This mostly exists to help me test changes without publishing endless releases.
Revert "stm32xx-i2c: remove soft timeout, LostInterrupt" (#2262) This reverts commit e199470, plus a small change to adapt to the NotificationBits API, which changed since this commit was originally applied. This adds a known-flaky system load detector that crashes the i2c driver. We're doing this because otherwise the i2c driver still contains bugs that result in unpredictable hangs, and hangs are currently believed to be worse than crashes. I'm really hoping to de-revert this in the very near future. --------- Co-authored-by: Matt Keeter <matt@oxide.computer>
Revert "stm32xx-i2c: remove soft timeout, LostInterrupt" (#2262) This reverts commit e199470, plus a small change to adapt to the NotificationBits API, which changed since this commit was originally applied. This adds a known-flaky system load detector that crashes the i2c driver. We're doing this because otherwise the i2c driver still contains bugs that result in unpredictable hangs, and hangs are currently believed to be worse than crashes. I'm really hoping to de-revert this in the very near future. --------- Co-authored-by: Matt Keeter <matt@oxide.computer>
host-sp-messages: don't copy that floppy^H^H^H^H^H^HInventoryData (#2253 ) The `InventoryData` enum in `host-sp-messages` is *real* big: at least 512B for the `DimmSpd` message, or perhaps more if one of the other variants whose fields I didn't want to add up is more than that. Currently, it `#[derive(Copy)]`s, which feels like a big stack overflow footgun: if an `InventoryData` value is accidentally moved by value, it gets copied on the stack. This kills the Hubris. Thus, this commit just removes the `#[derive(Copy)]`, which should take the bullets out of the footgun. Other `host-sp-messages` are left alone, and everything still builds fine. While the `SpToHost` and `HostToSp` messages also derive `Copy`, they aren't as big, and the `Copy` impl is necessary because they get stuck in ringbufs.
PreviousNext