8 ms·

UEFI is a necessary evil, we just have to get better, open-source implementations. Device Trees and alternatives are absolutely horrid especially in comparison.

oynqr 3y ago
Device trees aren't an alternative to UEFI, but to ACPI.
- Avamander 3y ago
  True, I skipped a step in my comment. My assumption is that ACPI and UEFI/BIOS usually exist together. Without UEFI you have to find an alternative to both, and neither DTs and the (bootloader) alternatives are pleasant.
  - mschuster91 3y ago
    What's so wrong with u-boot? Most of the trouble people have with it is "thanks" to chipset vendors who forked their version somewhere 10-ish years ago and completely mutilated it instead of putting in the effort to get their stuff upstreamed. The only major thing it can't boot to my knowledge is Windows, but it might be doable if you chain-load Grub.
    - surajrmal 3y ago
      uboot needs to be modified to run a given operating system if it wasn't already supported (or a shim pretending to be one of the supported operating systems needs to be used). UEFI provides a way to support all operating systems through a standardized interface. uboot implementing UEFI interface provides the best of both worlds.
      - stragies 3y ago
        "implement just enough UEFI to boot stuff, not the whole kitchen sink" I believe is the target of the uboot project
  - structural 3y ago
    ACPI table issues are just as unpleasant as devicetrees if not moreso. What makes x86 feel nicer is that most of the peripherals fall into two categories: 1) Standardized for the arch, so their configuration can be assumed and hardcoded, or 2) Attached to a bus that can be dynamically enumerated (i.e. USB, PCI, etc.) This generally makes the per-system configuration relatively simple. Embedded systems are not like this. Each SoC is effectively its own system architecture that just happens to share a CPU instruction set with other systems, and the devicetree ends up being the description of this architecture. So it looks gross and ugly and complex by comparison, but the complexity of defining peripherals for a system has to exist somewhere! The messy bits are, of course, that both the OS and bootloader need access to subsets of this data, and you'd like to ship the tables with the bootloader for a SoC (so the OS can be gneeric and not care), but really, the bootloader only needs a little bit of this, and the OS needs almost all of it... and this leads to coupling between the two being tighter than it should be.
  - oynqr 3y ago
    Coreboot does ACPI just fine.
mananaysiempre 3y ago
> Device Trees [...] are absolutely horrid especially in comparison. Care to elaborate? I only have a passing interest in the ACPI / UEFI / Open Firmware / device trees / etc. story, but I haven’t encountered anything particularly awful about device trees, or (until you) anybody saying there was.
- jeroenhd 3y ago
  Device trees are what you get if you don't implement ACPI. While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64. ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured. With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/qcom https://github.com/torvalds/linux/tree/master/arch/arm64/boo... On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows. ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,
  - oneshtein 3y ago
    Device Tree can be compiled to a separate file, then loaded by boot loader and kernel. When device tree is available and all drivers are present for a device, then it's easy to boot it.
  - rcxdude 3y ago
temac 3y ago
I'm not a huge fan of DT, but I've also reversed an UEFI bios once and I absolutely detest that hot pile of garbage. Obvious insane MS influence, with e.g. too many GUID everywhere for no reason. Overall astronaut architecture with gratuitous phases. Humongous abstraction layers that are not even optimized out at compile time and replaces a single "out" instruction by object oriented crap with virtual layers probably involving GUID. Scope insanely large. Insane vulns over and over again with some that completely break the PC security model for years, AND hinder maintainability at the same time. Berk. That's one of the reason that makes me want to use Macs everywhere (well maybe it is just because I don't know enough how their bootloader is designed and it is actually worse)
- kayodelycaon 3y ago
  M1 Macs don’t have UEFI, just a very limited system that can boot macOS from the SSD. The boot menu is macOS. The initial firmware has no drivers beyond the SSD. That’s why there is such a long delay between power on and the screen displaying the logo. And why there are no keyboard shortcuts. And why it doesn’t support external boot discs. https://news.ycombinator.com/item?id=26114417 https://news.ycombinator.com/item?id=26114417 https://support.apple.com/guide/security/boot-process-secac71d5623/web https://support.apple.com/guide/security/boot-process-secac7...

oynqr 3y ago

Device trees aren't an alternative to UEFI, but to ACPI.

Avamander 3y ago
True, I skipped a step in my comment. My assumption is that ACPI and UEFI/BIOS usually exist together. Without UEFI you have to find an alternative to both, and neither DTs and the (bootloader) alternatives are pleasant.
- mschuster91 3y ago
  What's so wrong with u-boot? Most of the trouble people have with it is "thanks" to chipset vendors who forked their version somewhere 10-ish years ago and completely mutilated it instead of putting in the effort to get their stuff upstreamed. The only major thing it can't boot to my knowledge is Windows, but it might be doable if you chain-load Grub.
  - surajrmal 3y ago
    uboot needs to be modified to run a given operating system if it wasn't already supported (or a shim pretending to be one of the supported operating systems needs to be used). UEFI provides a way to support all operating systems through a standardized interface. uboot implementing UEFI interface provides the best of both worlds.
    - stragies 3y ago
      "implement just enough UEFI to boot stuff, not the whole kitchen sink" I believe is the target of the uboot project
- structural 3y ago
  ACPI table issues are just as unpleasant as devicetrees if not moreso. What makes x86 feel nicer is that most of the peripherals fall into two categories: 1) Standardized for the arch, so their configuration can be assumed and hardcoded, or 2) Attached to a bus that can be dynamically enumerated (i.e. USB, PCI, etc.) This generally makes the per-system configuration relatively simple. Embedded systems are not like this. Each SoC is effectively its own system architecture that just happens to share a CPU instruction set with other systems, and the devicetree ends up being the description of this architecture. So it looks gross and ugly and complex by comparison, but the complexity of defining peripherals for a system has to exist somewhere! The messy bits are, of course, that both the OS and bootloader need access to subsets of this data, and you'd like to ship the tables with the bootloader for a SoC (so the OS can be gneeric and not care), but really, the bootloader only needs a little bit of this, and the OS needs almost all of it... and this leads to coupling between the two being tighter than it should be.
- oynqr 3y ago
  Coreboot does ACPI just fine.

mananaysiempre 3y ago

> Device Trees [...] are absolutely horrid especially in comparison. Care to elaborate? I only have a passing interest in the ACPI / UEFI / Open Firmware / device trees / etc. story, but I haven’t encountered anything particularly awful about device trees, or (until you) anybody saying there was.

jeroenhd 3y ago
Device trees are what you get if you don't implement ACPI. While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64. ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured. With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boot/dts/qcom https://github.com/torvalds/linux/tree/master/arch/arm64/boo... On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows. ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,
- oneshtein 3y ago
  Device Tree can be compiled to a separate file, then loaded by boot loader and kernel. When device tree is available and all drivers are present for a device, then it's easy to boot it.
- rcxdude 3y ago

temac 3y ago

I'm not a huge fan of DT, but I've also reversed an UEFI bios once and I absolutely detest that hot pile of garbage. Obvious insane MS influence, with e.g. too many GUID everywhere for no reason. Overall astronaut architecture with gratuitous phases. Humongous abstraction layers that are not even optimized out at compile time and replaces a single "out" instruction by object oriented crap with virtual layers probably involving GUID. Scope insanely large. Insane vulns over and over again with some that completely break the PC security model for years, AND hinder maintainability at the same time. Berk. That's one of the reason that makes me want to use Macs everywhere (well maybe it is just because I don't know enough how their bootloader is designed and it is actually worse)

kayodelycaon 3y ago
M1 Macs don’t have UEFI, just a very limited system that can boot macOS from the SSD. The boot menu is macOS. The initial firmware has no drivers beyond the SSD. That’s why there is such a long delay between power on and the screen displaying the logo. And why there are no keyboard shortcuts. And why it doesn’t support external boot discs. https://news.ycombinator.com/item?id=26114417 https://news.ycombinator.com/item?id=26114417 https://support.apple.com/guide/security/boot-process-secac71d5623/web https://support.apple.com/guide/security/boot-process-secac7...