4 ms·

> Device Trees [...] are absolutely horrid especially in comparison. Care to elaborate? I only have a passing interest in the ACPI / UEFI / Open Firmware / dev

> 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
  Devicetree is in effect doing the same thing as ACPI tables. It actually usually is passed into the kernel by the bootloader. The main thing that prevents having one vanilla kernel that works on most ARM SBCs (where the vendor only provides a devicetree like they provide ACPI tables) is the fact that most of them don't have full upstream support so you need to run a custom kernel anyway. (Secondly, because it tends to be used primarily on systems where you are building your own patched kernel anyway, most devicetrees are not so much a generic description of a device as initialisation data for a specific driver)
  - surajrmal 3y ago
    Lack of peripheral standardization is a big piece too. You're not going to include every possible arm peripheral driver in your image. There are far fewer drivers necessary to include on PC by comparison (and they are often less space constrained anyways so including those drivers isn't a big deal).
    - rcxdude 3y ago
      It's not much different. PC linux distros already bundle basically all the device drivers for not just the PC box itself but all the peripherals you might plug into it. The ARM ecosystem if anything has fewer peripherals, it's just not upstream.
  - AshamedCaptain 3y ago
    There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.
    - trelane 3y ago
      ACPI is executable code. "Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1] And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2] [1] https://en.wikipedia.org/wiki/ACPI https://en.wikipedia.org/wiki/ACPI [2] https://issuepedia.org/1999/01/24/ACPI_extensions https://issuepedia.org/1999/01/24/ACPI_extensions
nfriedly 3y ago
I think device tree, as opposed to something that can enumerate whatever hardware is present, is part of the reason that you have separate ROMs for every single Android phone. (Whereas a single Linux ISO can run on just about any PC out there.)
- temac 3y ago
  The DT is actually there to avoid recompiling the kernel for each specific device. But probably tons of vendor do not understand the purpose.
- londons_explore 3y ago
  It's definitely only part of the reason. If it were the only reason, it would be easy enough for a 'unified' ROM to contain config/devicetrees for a few thousand models of phone, and auto-select which one to use at boot time depending, for example, on a commandline flag.
- tremon 3y ago
  That's not the reason. Have you seen the size of the average kernel that can boot on just about any PC out there? It's 10MB kernel code and easily 100MB initramfs, depending on how many video card firmwares you intend to support. And that's on a relatively "standardized" PC platform, with generic ACPI/PCIe/SATA device abstractions in the hardware. ARM has none of that: no standardized platform, no device discovery through bus enumeration, no standard VESA graphics implementation. Device tree is a consequence of the non-standardization of ARM devices, not the cause. You could easily have the devicetree in the phone's ROM (just like ACPI, but without the executable code vector) and have the kernel read that data on startup. But you would need a kernel of at least the same size as the PC kernel+initramfs; and unlike on PC's, on phones people still (somewhat) care about code size and performance.

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
Devicetree is in effect doing the same thing as ACPI tables. It actually usually is passed into the kernel by the bootloader. The main thing that prevents having one vanilla kernel that works on most ARM SBCs (where the vendor only provides a devicetree like they provide ACPI tables) is the fact that most of them don't have full upstream support so you need to run a custom kernel anyway. (Secondly, because it tends to be used primarily on systems where you are building your own patched kernel anyway, most devicetrees are not so much a generic description of a device as initialisation data for a specific driver)
- surajrmal 3y ago
  Lack of peripheral standardization is a big piece too. You're not going to include every possible arm peripheral driver in your image. There are far fewer drivers necessary to include on PC by comparison (and they are often less space constrained anyways so including those drivers isn't a big deal).
  - rcxdude 3y ago
    It's not much different. PC linux distros already bundle basically all the device drivers for not just the PC box itself but all the peripherals you might plug into it. The ARM ecosystem if anything has fewer peripherals, it's just not upstream.
- AshamedCaptain 3y ago
  There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.
  - trelane 3y ago
    ACPI is executable code. "Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1] And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2] [1] https://en.wikipedia.org/wiki/ACPI https://en.wikipedia.org/wiki/ACPI [2] https://issuepedia.org/1999/01/24/ACPI_extensions https://issuepedia.org/1999/01/24/ACPI_extensions

nfriedly 3y ago

I think device tree, as opposed to something that can enumerate whatever hardware is present, is part of the reason that you have separate ROMs for every single Android phone. (Whereas a single Linux ISO can run on just about any PC out there.)

temac 3y ago
The DT is actually there to avoid recompiling the kernel for each specific device. But probably tons of vendor do not understand the purpose.
londons_explore 3y ago
It's definitely only part of the reason. If it were the only reason, it would be easy enough for a 'unified' ROM to contain config/devicetrees for a few thousand models of phone, and auto-select which one to use at boot time depending, for example, on a commandline flag.
tremon 3y ago
That's not the reason. Have you seen the size of the average kernel that can boot on just about any PC out there? It's 10MB kernel code and easily 100MB initramfs, depending on how many video card firmwares you intend to support. And that's on a relatively "standardized" PC platform, with generic ACPI/PCIe/SATA device abstractions in the hardware. ARM has none of that: no standardized platform, no device discovery through bus enumeration, no standard VESA graphics implementation. Device tree is a consequence of the non-standardization of ARM devices, not the cause. You could easily have the devicetree in the phone's ROM (just like ACPI, but without the executable code vector) and have the kernel read that data on startup. But you would need a kernel of at least the same size as the PC kernel+initramfs; and unlike on PC's, on phones people still (somewhat) care about code size and performance.