Most firmware verification problems involve one board and one toolchain. Management firmware is a different kind of problem. A BMC, the Baseboard Management Controller on a server motherboard, has to be correct against a layered protocol stack before it’s correct in any other sense, and that stack is what this case was about.
What a BMC Actually Has to Get Right
A Baseboard Management Controller is a dedicated chip on a server motherboard that handles remote power control, temperature monitoring, and firmware updates, independently of the host OS. OpenBMC is the open-source Linux distribution most server and data center vendors build this layer on. The customers at the end of this chain are data centers and cloud providers, where a single contract covers large fleets and runs for years, so correctness here isn’t optional.
Getting OpenBMC firmware right means it has to behave correctly across three layers: Redfish, the REST API standard that replaced the older IPMI protocol for server hardware management, PLDM, which defines the data format for things like sensors and firmware updates, and MCTP, the transport layer PLDM runs on. A change that compiles cleanly can still be wrong at any one of these layers, and none of that shows up until something actually talks to the board over the real stack.
Why This Doesn’t Verify Itself in a Simulator
You cannot fully confirm Redfish, PLDM, and MCTP behavior by reading the code. These are communication protocols: correctness means the board responds the right way when something on the other end of SSH actually asks it a question in that protocol. That’s a live interaction with the target, not a static check.
How the Verification Ran
Before generating anything, FWAuto read the full README and the entire repository for the project, the same accuracy step used across its workflow, so changes were grounded in the actual codebase rather than a guess at what an OpenBMC project usually looks like. From there, it connected to the board over SSH, the same channel used for Linux-based targets, and ran verification against the Redfish, PLDM, and MCTP stack directly, without an engineer manually driving each check.
This case was run in collaboration with ARM. A more detailed technical write-up of the verification approach is currently being co-authored for publication on developer.arm.com.
The Result
The project was originally estimated at approximately one month. It was completed in five days.
This reflects the scope and baseline of this specific OpenBMC project; it is one verified case, not a universal multiplier, and the original estimate was itself an internal projection rather than a fixed external benchmark.
What This Case Actually Shows
The headline number is the five days. The more specific point is what made that possible: a protocol-level correctness problem like this can’t be checked by looking at generated code in an editor. It has to be checked by running the actual stack against the actual board and reading back what comes out, which is a different kind of verification than confirming a driver compiles. That’s the layer this case was testing, and it’s the layer most firmware tooling still skips.