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

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...