Unveiling Tow-Boot

I have spent the past few weeks polishing up a project which might look frivolous to some, unneeded to others, but I believe it is long overdue.

This project is Tow-Boot, an opinionated U-Boot distribution with a strong focus on end-user-experience.

Booting your ARM SBC or ARM computer should be as boring as booting the trivial and generic x86_64 computer, and we're already almost there.

Can I see it in action?

Yes!

This unedited video shows a Pinebook (A64, 11 inch) booting. It first shows that there is an installed system using GRUB (UEFI). The system is powered off, then a NixOS installer USB drive is used. The system is again powered off, and a Fedora installer USB drive is used, to finally power off the laptop again.

I wanted to show other boards too, but really it's the same experience, but in a less neat package.

I would have shown it on the Pinebook Pro, but an issue with the Linux kernel, and VT rendering on EFI-booted RK3399 prevented me. Again, it would have looked similar, but on a slightly larger, faster, black laptop.

The main feature presented in this video is the graphical boot menu, which is accessed through a similar process as one would on a normal boring computer, by pressing Escape at the right moment. Just like on your boring computer, you can also spam press Escape before the moment.

This video does not show how the shared firmware media is prepared, nor does it show installation steps. Those are harder to show quickly.

What is this solving?

The goal is to solve the age old question of how do I boot $THING on my $ARM_SBC?

This aims to be solved by abstracting the board specifics the most we can, and producing the smallest set of diverging instructions for the supported combinations. This also solves the question: "where do I get my firmware from?"

Generally speaking, this separates the instructions for installing any generic enough operating systems into two main strategies. The first is with shared firmware storage, and the second is with dedicated firmware storage.

With shared firmware storage, the initial boot firmware lives on a storage media where the operating system could be installed. In effect, this is what most distributions shipping per-device disk images do. The difference is that with Tow-Boot, you get the firmware from a unique distributor (Tow-Boot), and the operating system only need to ship one generic installer disk image. Some care will be needed when installing the operating system so that the firmware partition is not accidentally erased.

With dedicated firmware storage, the initial boot firmware is written to a location where, generally speaking, the operating system wouldn't be installed. For example, the SPI flash "generally unused" in many SBCs. When installing from a generic installer, no care is needed as the firmware is stored safely elsewhere.

NOTE: This assumes that a single kernel is enough to boot all supported boards with your operating system. Obviously if a board requires a specialized kernel build, it would require a different disk image, or the disk image to support it as a boot option.

Does this replace U-Boot?

No! Probably not for many of its use case! But it might for a specific use case. The use case of using an ARM system as a generic computer platform.

U-Boot is a wonderful project. I love it, even for all its faults. This doesn't aim to replace U-Boot, since it builds on top of the excellent foundations from U-Boot. Everything that can be upstreamed will be. Anything that cannot, we'll see how things goes.

This is mainly an incubator for my long shot ideas that I would like to see, at one point in the future, entirely integrated in U-Boot. Closing down shop because there is nothing differing this project compared to U-Boot would be a total success in my opinion.

What is the next big step?

A GUI (TUI) for settings. Not dissimilar to what you would find on your normal computer. A selection of settings that are relevant for the board. This is where you could configure the boot order, or do change options like select a default device tree binary or apply device tree overlays. Editing some device tree options like, let's say, disabling or enabling some hardware nodes too. Relatedly, some vendor ecosystems could use a similar GUI to edit their board-specific configuration; editing config.txt options for the Raspberry Pi would be such an example.

But this will require a lot of work further down the line.