3 ms·

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 alter

by aseipp 5y ago

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

josteink 5y ago
> 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.
- garaetjjte 5y ago
  U-Boot can provide basic UEFI environment. Hardware description is another thing, either ACPI or DeviceTree can be used.
- aseipp 5y ago
  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")

by aseipp 5y ago

josteink 5y ago

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

garaetjjte 5y ago
U-Boot can provide basic UEFI environment. Hardware description is another thing, either ACPI or DeviceTree can be used.
aseipp 5y ago
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")