Booting ARM Linux the standard way
tuxphones.com
tuxphones.com
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 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.
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.
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.
Only because the sources aren't available.
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.
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.
Tow-Boot appears to be MIT Licensed. There appears to be nothing stopping them from building Tow-Boot from source.
> 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.
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.
In any event, the nix store doesn't need to be in "/nix/store" anymore: https://nixos.wiki/wiki/Nix_Installation_Guide#nix_2.0.27s_n...
If you're willing to recompile the nix interpreter and sacrifice cached binaries you don't even need namespaces or ptrace. Just
./configure --with-store-dir=xyz
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.
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...
tow-boot is one such implementation of this interface
I use Tow-Boot on my Pine64 RockPro64, with a plain NixOS aarch64 installation. Bliss!
Thanks Samuel and Martijn!
/boot/efi/debian/grubaa64.efi
"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
As an American English speaker, tow-boot (like the shoe or car storage space)n was hard to read.