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. :)
> U-Boot is very easy to build and patch and hack on, and it's well known in these streets.
U-boot is very simple and very good at booting device-specific OS images.
What it fail at is providing abstractions and interfaces to provide to device-agnostic images so that they can boot without being tailored to a specific piece of hardware.
Which is why most Rpis are running Raspbian, not Debian.
For better or worse UEFI solves this and allows you to boot a plain Debian ARM64 ISO on any ARM64 machine with UEFI-compliant firmware.
Just like you (of course!) can on a regular PC. That’s where we need to get with ARM too. Make them work just like regular PCs.
Aarch64 has this solved in user-space. Now we need to get booting fixed too.
Attached device enumeration and boot firmware are somewhat orthogonal concerns; though certain ARM standards for various boot certifications ("ServerReady") do, in fact, require ACPI. But for mobile phones there's no need for it. You can just use a device-tree for the system and be done with it. (And yes, there are a lot of device tree files needed for all the devices, and while "self describing" would be nice it's ultimately a lot easier to just "have a lot of small files")
Title is misleading: Tow-Boot wants to become the standard way, but it isn't one today.
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).
Why make a new thing, rather than improving upstream u-boot to cover as much as possible? 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.
Tow-Boot isn't the standard yet no, but it provides the standard EFI booting interface so it's at least somewhat true.
Distro's is shipping binaries that aren't build from source all the time, it's called firmware. Which is why this should probably be managed by fwupd, not packaged by distributions.
"but it provides the standard EFI booting interface so it's at least somewhat true."
AFAIK, it just provides the uboot-uefi interfaces, which are only standard if you are okay with throwing out the vast majority of things marked mandatory in the UEFI specification. The efi bits are just a tiny shim over uboot that provides just enough of the UEFI protocol interface to boot grub/etc from some subset of the available devices.
Its a vast improvement over uboot by itself, but just barely scrapes the surface of fixing the arm boot problem. On many of the platforms there still isn't a uboot/pcie driver so booting from NVMe rarely works. None of uboot-uefi supported platforms provide the full set of UEFI drivers/protococls required by the spec, so its a crapshot if one deviates much from the expected emmc/sd boot path whether it works.
In a few years that might change because there continues to be a fair amount of ongoing work to make it more spec compliant but as of today, its a bit of a misnomer to call it uefi. Going forward some of this work is going to be quite difficult as the core architecture of uboot still isn't even segmented sufficiently to support UEFI runtime services, or ACPI platforms.
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.
> 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.
Sure, there's no technical blocker, but the article seems to be implying that they shouldn't:
> One of the nice things about Tow-Boot is that it leverages the Nix build system to generate a nice reproducable build of the platform firmware. This should take away some of the doubts of having a prebuild platform firmware instead of every distribution figuring out how to do this from source. Also distributions not doing this from source would mean there's less chance of inconsistencies slipping in.
What’s the difference between a reproducible binary and one they’ve built themselves? Can’t they just build it from source and check that the digests match?
I mean heck, since it's a Nix Package, couldn't they just build it with Nix as the build system? And if for any reason that is the issue (installing Nix on a foreign distros can be pretty invasive, containerized?), the recipe for how to build it is right there.
> installing Nix on a foreign distros can be pretty invasive
Is this some kind of joke?
Installing nix on a non-nixOS computer doesn't even require root. You can even bootstrap the entirety of nixpkgs that way. That's one of the most awesome things about nix and nixpkgs.
But distros's don't have to. On most hardware it should be possible to flash Tow-Boot to some form of on-board boot storage and after that the board Just Works(tm)
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...
Noble goal, but I want to point out that ARM recommends using UEFI as the standard way to boot. Then you can just boot whatever popular distro you want without weird tweaks. I’m not a fan of EFI but I think the downsides are less bad these days.
Sorta, UEFI is a lot more complete than the small part of the spec that uboot implements. Put another way, its not yet a spec compliant implementation.
Fwiu, the magical path to launch Grub on an ARM board is:
/boot/efi/debian/grubaa64.efi
And that doesn't quite require tow-boot to do hw init?
"DOC: How to boot into Grub" (in order to get a passphrase-protected graphical boot menu where you can modify kernel parameters like `rescue`)
https://github.com/Tow-Boot/Tow-Boot/issues/110
putting a file in /boot/efi/debian/ won't do anything at all unless the specific board you have already has platform firmware onboard to actually make that work. Arm EBBR complicant server boards do this for example, this won't work for the vast majority of ARM single board computers though.
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. :)