Will Kestrel become the better BMC?

Raptor Engineering's Microwatt-powered Kestrel BMC replacement is improving by leaps and bounds. The screenshot was from a Twitter post showing its internal Web server (like OpenBMC) and ability to update its own firmware (also like OpenBMC). And naturally everything is open-source, based on Zephyr.

But that's not the part that attracted me most. What really got me excited was a 10-second start time. Yup, you read that right: Kestrel is ready and able to bring up the system 10 seconds after power is applied, compared to a good couple minutes or more with the current ASPEED BMC running OpenBMC — and the majority of that ten seconds is programming the FPGA. While a couple minutes isn't a big deal on a server system, it's a real problem when it's a desktop, something I complained about way back in my Blackbird semi-review since in its role as a household HTPC it gets powered up and down a fair bit, and shaving off literal minutes of time to login is huge in that setting (as well as anywhere else OpenPOWER is being used as a "small" system).

OpenBMC on ASPEED is by no means perfect in other respects, either. Raptor claims upstream has been slow to incorporate improvements to the user interface and fan control (though the project disputes this). On the user side, this Raptor Talos II is pretty quiet but it's also a big EATX Supermicro chassis with two HSFs and multiple case fans; the Blackbird in its lithe mATX case tends to have an annoying habit of spooling up and down even in a cool room, even with quieted fan assemblies. And it's always been the case with IBM and IBM-derived hardware where one bad fan can sometimes make the difference between booting or not (the ASMI in my personal POWER6 will refuse, and has refused, to power on the main CPUs if all the fans aren't fully operational).

However, some of the slowness may be due to the current requirement on Power ISA designs that the BMC be fully up before offering the virtual PNOR to the main CPUs, which apparently isn't necessary on x86 and allows some parts of bring-up to occur in parallel. A partial hardware solution may be needed to mitigate that deficiency. OpenBMC does have some ideas, including converting OpenBMC's initramfs and UBI to zstd compression which shaves a few more seconds off, and some of the BMC forks out there have done more by jettisoning entire components judged generally unnecessary (but with corresponding impacts to flexibility, and none have gained significant traction).

It may well be that OpenBMC, because it needs to be all things to all deployments, may not be the best place for firmware designed primarily for workstations. If so, then Kestrel (when it's fully "a thing") would be the next best option. However, that doesn't yield an obvious solution for the installed base like the three Raptor systems here, and installing Kestrel on an existing board is still not a trivial process (nor has, at least of this writing, it been advertised to work on the T2 or T2 Lite). Raptor probably doesn't want to be in the board upgrade business either, so any envisioned Kestrel upgrade for older systems would need to be user-installable, and preferably without a soldering iron. I'm all thumbs with one myself and even more so when it's SMT.

Baseband management is only one part of what makes a system liveable, but for desktop machines it's not an insignificant one. No matter what form it ends up taking, any improvements make a difference. And if a Kestrel board is the current way forward, at least we know it will certainly be as trustworthy, if not more so, as the ASPEEDs we already use.