Whether it's UEFI or U-Boot loading the DeviceTree blob doesn't really matter, no? A correct DeviceTree matching the drivers which ship with a given kernel version is still necessary.
The big problems are when:
* The DeviceTree is incorrect but works anyway because the peripheral drivers are ignoring it.
* The DeviceTree is correct but the peripheral drivers had to be patched to work.
UEFI doesn't seem to do much here, no?
And even moving to ACPI doesn't really change anything - DeviceTree is just a simplified ACPI really, if the ACPI descriptors and what the peripheral drivers do don't match up, it still doesn't work.
Yes, and no. DT's as used by these arm boards are basically reflections of how the linux kernel works on a given platform. A device driver developer needs to make a decision, say about how fast to program a clock divisor, so they then need a clock driver, and a device specific set of attributes that match 1:1 with the code paths in the Linux kernel which are making platform dependent decisions. When another OS comes along the attributes change because the driver model is different. This is visible in linux as its own model evolves. The systemready/ACPI specs tend to require more self describing buses (pci/usb/etc) where the devices are more fully encapsulated behind the bus, and things like power/clock management are either standardized by the bus interface, or via the standardized ACPI methods. AKA, putting an ACPI device into a low power sleep state is the same across every single device/platform because ACPI can notify some other firmware/management entity to perform the work rather than trying to fine grain manage the process.
So, your right, DT is a subset of ACPI, but its only really capable of HW description. So all these platforms (like the rpi) end up with proprietary ways of getting their management (the GPU in the case of the rpi) engine to perform platform actions. And that's needed because all these arm SoCs now have processors/etc that aren't visible to Linux because the model is no longer just about a central CPU doing all the work.
It's more like, the device tree describes the parameters needed to load and run Linux drivers for the hardware, given the exact git revision of Linux including the dts file. For one particular hardware variant/revision, of course.
I suppose my comment is more about a culture shift rather than a technical suggestion, one supported by UEFI+ACPI :) Mainline Linux boots on pretty much all x86 hardware without needing explicit device trees, because the hardware is autodetected and initialized, and the hardware plays nice with the Linux driver (preferably mainline, but even that's not necessary). We could have that on ARM SBCs, if vendors were better.
> And even moving to ACPI doesn't really change anything - DeviceTree is just a simplified ACPI really, if the ACPI descriptors and what the peripheral drivers do don't match up, it still doesn't work.
I'm getting to the edges of my understanding of these things here, but wouldn't ACPI make it easier to support newer / mainline kernel versions without the vendor needing to supply a device tree specific to a kernel version they maintain?
It would be nice if there was enough of a standard one could download a Debian ARM64 image from Debian's main website, and it would just boot and work on an ARM SBC. Even brand new x86 hardware can usually at least _boot_ and provide basic and useful I/O on Debian stable, and work pretty well on Debian sid.
> It would be nice if there was enough of a standard one could download a Debian ARM64 image from Debian's main website, and it would just boot and work on an ARM SBC.
NetBSD has one image that will boot on all supported ARM64 systems, it just uses the device tree or ACPI table supplied by the firmware to configure the hardware, there is nothing stopping Linux from doing the same.
This is how Linux works too, the issue, as I pointed out, is just device tree <-> peripheral driver mismatch.
In the sense of "supported" where the peripheral drivers are upstreamed _and_ the Device Tree matches the code that was upstreamed, this is exactly how Linux works. It's just that as the article documents with Rock64, this is sometimes not an easy combination to find. I'd imagine that NetBSD actually has the same issue with respect to needing a "supported" Device Tree for a given "supported" hardware version - there are probably interim Device Trees that will not work at all.
The issue is that the Device Tree and kernel are both moving targets which often don't match, because fundamentally the Device Tree is just a configuration file for the peripheral drivers and the details of the interface contract between the Device Tree and peripheral driver can change at any time.
The same issue would exist for ACPI too - as several posters have pointed out, the issue is mostly cultural.
x86 has a "plug n play" culture - hardware is sold mix and match and has to work with generic CPU/motherboard/firmware combinations, so the platform needs to be able to enumerate devices and allocate resources on the fly. Drivers are written from the ground up to work with what bus enumeration gives them and not to make naive assumptions about the configuration of system memory. Plus, PCI devices all have a standards-constrained communication mechanism with the host, as opposed to ARM peripherals, which can be any given combination of register-mapped, memory-mapped, interrupt-mapped, or multiplexed through other hardware.
ARM systems culturally have never had this constraint, so many drivers rely on hardcoded assumptions that break when they are introduced to another SoC. And for ARM, this is only getting worse as instead of making peripheral drivers more generic, vendors are instead building blob-HALs. I'm not sure what the solution here is unless the buy side (OEM server integrators, phone vendors, set top box manufacturers, SBC vendors, etc.) start demanding improvement. In the case of the Pi, the Pi folks instead have been slowly chipping away at making this migration themselves (i.e. slowly replacing DispmanX FKMS with native KMS), which is An Approach but maybe not A Great Approach.
This is certainly the dream of DeviceTree, but I don't see how this can work, given that "Linux" generally requires a different device tree depending on both the kernel version and which specific drivers are employed. Perhaps for specific ARM boards with a very high degree of maturity this is possible, but for example even for Raspberry Pi, a completely different set of DT overlays are required depending on the specific graphics driver configuration which is desired (KMS/FKMS/proprietary VideoCore etc.).
The big problems are when:
* The DeviceTree is incorrect but works anyway because the peripheral drivers are ignoring it.
* The DeviceTree is correct but the peripheral drivers had to be patched to work.
UEFI doesn't seem to do much here, no?
And even moving to ACPI doesn't really change anything - DeviceTree is just a simplified ACPI really, if the ACPI descriptors and what the peripheral drivers do don't match up, it still doesn't work.