We proudly announce that there is a new BMC-Firmware release coming up. ‘v2.0.0’ will be released within the next two weeks. It will contain some significant updates that should improve the overall user experience of the Turing Pi. In this blog post, we want to tell you more about what we have been cooking.
Goodbye PhoenixSuit
We are one step closer to our end goal of running mainline Linux. In v2, we got rid of the proprietary bootloader and flash driver, enabling us to cut loose from PhoenixSuit, the third-party tool used until now for flashing new BMC firmware. Having a stock driver means that we can significantly improve the firmware upgrade capabilities. Inherently, the PhoenixSuit can no longer be used to flash future releases. Instead, we have a couple of alternatives, which we discuss in the following paragraphs.
Upgrading the Firmware
Following the bootloader and flash changes as well as becoming independent from the PhoenixSuit software, we could also develop a more robust firmware update process. We have implemented a new system that fixes all the robustness concerns we had. How it works now is the incoming firmware image is written to a new volume, and the bootloader is told to boot from that newly created and flashed volume once, on the next boot only. Upon successful reboot (which also means the flashing process was successful), the volumes are renamed to make the change permanent. But if the incoming firmware image is invalid, corrupt, or won’t boot, the volumes won’t get renamed and the system will boot back to the old working firmware (sometimes even without a hard reboot) and no changes will be made. Before, an unsuccessful upgrade process could cause the BMC to not boot anymore.
Fail-safe Mode
We have implemented a fail-safe mode in case you ever end up with non-working firmware. You can boot into fail-safe mode by holding the KEY_1 key during boot. The v2 firmware runs an overlay filesystem, meaning that all modifications to the filesystem are stored on a different partition. The overlay isn’t mounted in failsafe mode, temporarily booting the board with ‘back to factory’ firmware.
SD Card Edition
An SD card edition will be available. The image is identical to the firmware written on the flash chip. So it has the same features but has the advantage that SD cards usually can store far more data. It is an excellent addition for tinkerers who want more BMC storage or to experiment more freely. A very cool additional feature is that it can also be used as a recovery tool. In case your board doesn’t boot anymore, it’s as simple as inserting the SD in the back of the Turing-Pi board and hitting ‘confirm’ when prompted during boot to rewrite the flash with a new image. We hope this SD card can be the basis for a CE (community edition) version of the firmware, providing more packages and features on the BMC as well as new features provided by the community that cannot be embedded into the official image.
Rusty Daemon
The rewrite of the BMC daemon to Rust is completed. Our API server boasts extra features such as IPV6 support, TLS, and basic and token-based authentication. We hope the community can appreciate the Rust ecosystem as much as we do and are open to anybody who wants to contribute. Importantly, we’ve added RK1 support to the firmware, as well as multipart file upload support. This means you can write an OS image (like Ubuntu) to one of the nodes from your computer with a single command! We tried not to diverge from the current API while rewriting. While this is great for backward compatibility reasons, we also acknowledge that there is room for improvement. We will continue supporting this ‘legacy’ API, as we call it internally, but we will likely explore other options, such as Redfish, soon.
TPI
The TPI tool also got a complete revamp to support all the new features of the BMC API. We reviewed the commands and tried to make them more intuitive, which should make it easier to work with the CLI. TPI is distributed in the BMC firmware, but can also be installed and used remotely from any machine running one of the supported operating systems. We have binaries and packages for Windows, Debian/Ubuntu, Arch Linux, and macOS.
How to Upgrade
As mentioned, we will have two ways of upgrading to newer releases – using our new OTA upgrade system and using an SD card. Be aware that the first upgrade to v2 (or later versions) is only possible using an SD card. Exact instructions will follow shortly, but to briefly explain the new upgrade process: you’ll be able to either flash the SD card with the new firmware and it will be applied automatically upon next reboot, or (if you are already using at least v2 of the firmware), a new OTA system will be available (including upgrading from the BMC web panel). An alternative way, a USB imager (similar to the old PhoenixSuit), is still being developed. We hope to tell you more about it once we are nearing completion. This would give you an extra alternative to flash firmware on the board. This, in particular, will be useful for users who cannot access the SD card slot on the back of their board, for instance, because it’s mounted in a case.
On the Horizon
One of the most requested features in the community is VLAN and LACP support. We heard you and are working on it, and I hope to tell you more about it soon.
Contributions
We’d like to thank all contributors for their ideas and improvements, especially Sam Edwards for incredible work mainlining BMC support and providing help with the bootloader, OS, and new flashing system.
