31–40 of 53 posts
Earlier quoted context omitted.
Serious question: what things does it make easier? Other than booting windows. I don't know anything about it except that it seems much more complicated than u-boot.
what areas of u-boot do you find much simpler than edk2?
Ugh. Instead of propagating UEFI further, we as an industry should be promoting and improving IEEE 1275 Open Firmware.
Why would we base modern computer firmware around a 1994 standard, on which work had mostly stopped by 1998?
This here is the important next step for ARM SBCs. A working UEFI. Maybe they can get together and standardize something they can work on together. But this whole SD card flashing nonsense needs to stop.
There is a UEFI standard in some of Arms specs, but it’s only mandatory for the server class IP atm. Some soc vendors are starting to adopt it even in non-server class but it’s slow. My feedback to an Arm devrel a few years ago was exactly this though: you need to provide a consistent standard boot path that also helps OS authors with enough bootstrap that debugging is less of a crapshoot every single time. I hope so…
Earlier quoted context omitted.
ARM SoCs have always been very proprietary and fragmented, and until/if something like the x86/PC comes along I don't think just UEFI is enough. The PC flourished because of many de-facto standards, and not just the BIOS. Unfortunately the companies these days seem to love their proprietariness, so I don't think something like that will happen again.
It's this. UEFI doesn't solve the problem of peripheral discovery, for example. SBSA standard in the server realm seems to have it figured out.
Earlier quoted context omitted.
what areas of u-boot do you find much simpler than edk2?
I have not developed using EDK2/UEFI - that's why I'm asking
A common secondary piece is ACPI, which isn’t strictly mandatory, but when you provide both UEFI and ACPI then you can skip the whole dtb mess. Sadly ACPI isn’t the simplest of approaches, as it’s encoded in a way that requires executing bytecode in a stack machine. There are real and valid security concerns that come with this, but there are also big advantages- the abstraction generalizes over a lot of what would otherwise be specialization that has to be carried around in the bootloader and OS.
Uboot implements a subset of the uefi spec, but typically is used where there is no ACPI type configuration, with the gap filled by a combination of dtbs and vendor forks or patches (often before upstreaming, which sometimes never happens).
Depending on how deep your relationship is with all of this, you may live with uboot as a plain binary blob from a board vendor, in which case whatever version they formed and options they chose may bring various constraints or challenges doing anything novel like booting an alternative kernel or distro.
Typically a more complete uefi and ACPI system will be able to get much further in the boot process with far less hardware specialization, a lot of operating systems can boot very far with this combo even if they’ve never seen the specific hardware topology before.
Uboot upstream has a lot of implementations for a lot of hardware targets. There isn’t really so much of a central place for uefi implementations
Earlier quoted context omitted.
It's this. UEFI doesn't solve the problem of peripheral discovery, for example. SBSA standard in the server realm seems to have it figured out.
UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want.
Manufacturers kind of suck at actually describing the hardware on their motherboards and hacks and workarounds are very much required to provide a usable experience on many machines.
Unless manufacturers stop lazily copy-pasting their DSDTs with minor changes, we should probably hope for a better solution.
U-Boot does basic enough UEFI emulation for most use cases. I find that I don't need native UEFI firmware and I can just build U-Boot with UEFI support for most ARM devices. For example, right now I have an old armhf i.MX6 Wandboard Quad that runs: U-Boot -> UEFI (with Secure Boot if desired) -> Systemd Boot (or Linux EFI Boot Stub) -> Debian (or other distro) That same layout should be doable on any U-Boot¹ supporte…
Earlier quoted context omitted.
UEFI+ACPI+PCIE+XHCI pretty much covers everything you could want.
In theory yes, in practice ACPI isn't always a great solution (as can be seen by the many lines of kernel logs about broken DSDTs on my motherboard). Manufacturers kind of suck at actually describing the hardware on their motherboards and hacks and workarounds are very much required to provide a usable experience on many machines. Unless manufacturers stop lazily copy-pasting their DSDTs with minor changes, we should…
On PC, the main check against it is Microsoft because they at least try to make vendors care with "Designed for Windows" and the like and their test suites.
UEFI is a fairly insane spec, but at least it's a fairly complete spec. Following it is preferable to custom nonsense. (Spoken as someone writing a custom non-UEFI bootloader right now)
Like the entire HII thing, with an UI toolkit!
Earlier quoted context omitted.
There is a UEFI standard in some of Arms specs, but it’s only mandatory for the server class IP atm. Some soc vendors are starting to adopt it even in non-server class but it’s slow. My feedback to an Arm devrel a few years ago was exactly this though: you need to provide a consistent standard boot path that also helps OS authors with enough bootstrap that debugging is less of a crapshoot every single time. I hope so…
I don't understand the hatred for UEFI. It seems like people get irrationally disgusted when they find out that it's a big complex standard with lots of extraneous stuff that almost nobody cares about (on desktop, that is). Just give me text, a framebuffer, file system access, and a memory map. It's not difficult. Sadly I think that no one will be happy until there is some equally-overwrought spec on the ARM side.
People also rarely think of the complexity inherent in having an open platform where owner of a device does not need to build/acquire a custom OS build for their machine, and thus see cases of "enough to run something they care about" and think that's enough.
[0] I still remember BIOS config menus and PCI card option roms that effectively had stripped down windows 3.0 in them, or an approximation of it. And how it meant presence of Intel PCI hardware RAID controller in certain server meant I needed a full crash cart or remote KVM to fix RAID config.