3 ms·

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'

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.

nsajko 5y ago
> Distro's is shipping binaries that aren't build from source all the time Only because the sources aren't available.
- aseipp 5y ago
  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.
StillBored 5y ago
"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.

nsajko 5y ago

> Distro's is shipping binaries that aren't build from source all the time Only because the sources aren't available.

aseipp 5y ago
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.

StillBored 5y ago

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