Booting ARM Linux the standard way

> There's going to be a lot of resistance to distros shipping a binary they didn't build from source. It might work if you could ship Tow-Boot on the hardware and make it optional for the OS to care, but unless I've missed something OS integration is needed (if nothing else, because it has to share storage).

That's kind of the point here -- distros would stop shipping the bootloader, and the bootloader would be independently managed, to be treated as a board firmware instead of os package.

Thanks I hadn’t realised from the post. Makes sense.

I'm happy to see something like this; in my own research, for my use cases, it seems like using U-Boot to create a UEFI compatible environment was a solid alternative to e.g. TianoCore for many cases. (Not that they don't work; I'm running a TianoCore build on my RPi4 successfully, too.[1]) One of the reasons I concluded this was actually highlighted in this article in an indirect way: U-Boot is very easy to build and patch and hack on, and it's well known in these streets. I had a real pleasure when I had to fix a minor bug in it for booting seL4 one time. I can speak positively for (upstream!) U-Boot, at least, from that perspective.

I can also say I'm happy to see this coming from Samuel Dionne-Riel, a fellow co-developer of NixOS. Always glad to see the stuff the community produces. :)

On mobile platforms U-Boot is managed independently of the kernel or host operating system; you typically flash it directly onto something, and point the CPU to boot from there. And it loads your kernel and rootfs from somewhere else. So in this case, the firmware is not managed by the distribution, at all. That is the use case such a tool caters to. It is also how UEFI works today, on modern x86 systems.[1]

The way this whole thing is intended to work is something like this:

- You are going to ship a bootloader for a device.

- You choose Tow-Boot, because you want UEFI and you want to build on an established tool (U-Boot)

- You patch/tweak the Tow-Boot build to produce a firmware for your device. That would require, for example, shipping a device tree with it, and maybe a few patches to U-Boot if you needed it (sometimes unavoidable), and tweaking some build system parameters.

- Tow-Boot will also have its own specific integration you probably need, to follow its given conventions and UX guidelines (e.g. when to flash red LEDs)

- Presumably, they would also hopefully work to upstream that into Tow-Boot and, by association, U-Boot. Many vendors do this already.

- The developer can then flash the binary from the Tow-Boot build to their internal flash or whatever. They ship the devices.

- The user now only needs to load any UEFI-compatible Linux/Windows/Whatever distro and point Tow-Boot to it. All of these systems generally expect the UEFI environment to be managed independently of the host OS, already. This is precisely how x86 systems work today, so it really does mostly "Just work."

The point here is that the work around the firmware build, its user interface, and its quality control are all shared under a single umbrella. U-Boot by itself isn't enough; you typically also need the device trees, configuration, patches, etc. This is a unified project to collect all that.

That is why Tow-Boot needs its own reproducible build system, because the OS package manager isn't going to build it or ship it to users. It literally isn't the way it's treated on most modern systems.

> It might work if you could ship Tow-Boot on the hardware

That is how it works: the vendor ships Tow-Boot (or any other loader) onto the flash and ships the device. Users then load an OS onto it. Or the user could re-load a new version of Tow-Boot too. But the point is the OS and the OS packaging infrastructure is actually not handling this.

> OS integration is needed (if nothing else, because it has to share storage).

Yes, it needs to support UEFI.

> Like... I would expect the existing u-boot project to be very much in favor of supporting all possible hardware and standardizing ex. LED colors to always mean the same thing.

That's not a good solution. Things like LED colors are human interface decisions, not technical ones, trying to unify them in a place like U-Boot isn't the right layer; it just ships device trees and might enable these interfaces by writing to some configuration registers, but that's it. How the system blinks LEDs across different devices is largely a policy decision that isn't something that should be handled there.

[1] Though, in theory, there's nothing to stop tools like fwupd from shipping UEFI capsules or whatever and having Tow-Boot somehow apply those updates. This is how fwupd already works on Linux x86 systems, so it's not that far-fetched. But probably not an immediate goal, either. And it still treats the UEFI firmware as completely separate from the host packaging system; UEFI capsules can only be applied after the system reboots, and before control is handed back to the OS...

For random software, yes, but in the case of UEFI firmware it's not really applicable, which is the context of the parent comment. You can go build a UEFI bootloader for the RPi4 from TianoCore right now. What you can't do is use the OS-level distro tools to package or "manage" that TianoCore-based UEFI firmware in any way.[1] You have to stick it on the device yourself, and that's not a coincidence: all modern UEFI platforms treat that boot firmware as separate from the host operating system environment, and they generally do not treat these updates as "package repository updates" in the typical way. That's why UEFI is an "interface", after all.

The correct way to manage that firmware, in the best case scenario, is to let the vendor produce a (correct) binary that is source-available, reproducible down to the last bit, and then use a system fwupd to apply updates that firmware in a generic way, like using UEFI capsules. Which is exactly the kind of project Tow-Boot is aiming to be: a base upon which vendors can create reproducible UEFI-compatible firmware.

Naturally there are exceptions to all of this (such as the infamous linux-firmware package which is managed by your OS packager) but I think you catch the drift. It's not a binary decision on whether to ship something in this way, it's a spectrum.

[1] What I mean by this is, you don't install firmware updates using apt or yum or whatever, like you did in the past with grub. You apply firmware updates using fwupd, which is a third party tool that actually integrates with UEFI to apply patches directly.