Ryan Brueryanabx@mastodon.social
Oct 5, 2026, 1:31 AMyeap, after searching the mailing list, I'm of course not the first one to come up with this idea @cas
https://lore.kernel.org/all/20231009-caleb-notch-example-v1-1-9e0a43ae233c@linaro.org/
Replies
Oct 5, 2026, 1:34 AM@ryanabx Describing things in DeviceTree comes with serious pain, since DTs are unstandardized documents. The format can and does change across Linux releases, and there is no guarantee that a driver is always used with a DT or that a DT has that information. What do you do in scenarios like that?
(Also, it is starting to look like even Android phones will move toward UEFI, though what that looks like is unknown at this time...)
ellyelly@donotsta.reOct 5, 2026, 2:01 AM@neal Objection!
There is a devicetree specification and (compared to ACPI) is a pleasure to work with, problem is that people just can’t agree on something that works for everyone and is provided by the firmware. Technically Linux has a policy of backwards-compatibility but in practice… good luck, have fun.
Hardware vendors f**k up ACPI all the time, and that’s how you get thousands of ACPI workarounds in the drivers:
[ 6.281665] nvidia 0000:01:00.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=none:owns=none [ 6.325599] NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64 595.104.02 Release Build (portage@localhost) Sun 4 Oct 05:00:27 CEST 2026 [ 6.362771] nvidia-gpu 0000:01:00.3: i2c timeout error e0000000 [ 6.363667] ucsi_ccg 1-0008: i2c_transfer failed -110 [ 6.364232] ucsi_ccg 1-0008: ucsi_ccg_init failed - -110 [ 6.364945] ucsi_ccg 1-0008: probe with driver ucsi_ccg failed with error -110 [ 6.853449] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (20260408/exoparg2-393) [ 6.853999] ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (20260408/psparse-543) [ 6.854608] ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (20260408/psparse-543) [ 6.856895] hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not supported" [ 7.288320] amdgpu: vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle…and yet people still claim ACPI > DT for some reason :akko_shrug:
Qualcomm phones have been using UEFI since Snapdragon 820(?) when they introduced XBL, but ABL (which is an UEFI application) calls ExitBootServices prior to loading the Linux kernel from boot.img. Other ARM vendors do it differently (MediaTek uses LK2, Google also uses LK2, Unisoc uses U-Boot apparently?) but they need to conform to Google’s spec, which is why ABL exists.
UEFI-booting Android is news to me, “Googlebooks” (awful and cringeworthy name, ew) that just dropped use coreboot + new branch of depthcharge (at least according to initial analysis) so no “UEFI” to be found here either.
- Oct 5, 2026, 11:19 AM
@elly The biggest mistake about the DeviceTree spec as it currently stands is that it's part of the Linux kernel project. That screwed it over. And DT effectively requires full reverse engineering to support a device. That's way worse than what we have to do for ACPI. ASL/AML isn't *fun* by any means, but at least ACPI *forces* the hardware vendor to be responsible for preboot initialization.
Google announced the move to UEFI at LPC last year. It's the "Generic Bootloader" in Android parlance.
Oct 5, 2026, 12:38 PM@neal @elly last i heard there is interest in moving dt out of linux. it is already used by other projects (u-boot, *BSDs) and in practice this has been pretty solid, the dt-rebasing project is a start in this regard
full reverse engineering?? not really? the level of HW knowledge depends way more on the architecture and doesn't have much to do with dt vs acpi
neither does "preboot initialisation" for that matter, unless the implication is that acpi systems just work and totally don't need driver changes which we already know is untrue.
- Oct 5, 2026, 1:09 PM
@cas @elly There has been interest in moving DT out of Linux for many years. It hasn't happened yet and I doubt it will anytime soon.
To support completely new hardware, you have to write the definition almost entirely from scratch. The reason we don't have to do that with ACPI is because it's not really allowed to do OS-provided ACPI definitions (that was an APM thing and it was a bad idea).
I'm saying that DT is way more work, and hardware support over the long term is much harder.
- Oct 5, 2026, 1:34 PM
@neal @elly we'll have to agree to disagree. my experience working with devicetree has only reconfirmed the reasons it was adopted in the first place -- it's a very simple concept. in 2026 a lot of the earlier architectural issues have been figured out. Bringing up a new platform is not that bad actually??
we also are in a much better place to write DT in a way that allows us to make backwards compatible changes as we describe the hardware in more detail. with ACPI you're just screwed when sayyy a vendor doesn't bother to model your type-c port as dual role capable even though it is, you lose out on hardware features that your device actually has!
nevermind the hellish issues with EC quirks and all the driver workarounds that are needed due to bad firmware
it's perfectly fine to have a preference here but i don't buy this "it's so much harder" line especially from someone who afaik hasn't had to do bring up or long term development on DT platforms. I'd take it any day over ACPI if it means not having to deal with a fw blob of unknown quality that might have deranged bugs
- Oct 5, 2026, 1:43 PM
Cassandrichdalias@hachyderm.ioOct 5, 2026, 1:57 PM@neal @cas @elly Are you talking about moving the DTS files out of Linux kernel repo, or something else?
DT used correctly belongs in the bootloader firmware of the board passed to the kernel by the bootloader, with the possibility to patch it there if needed to fix bugs or under-expressiveness in how it shipped. The Linux folks' idea of shipping DT stuff alongside the kernel is totally missing the point.
Oct 5, 2026, 2:10 PM- Cassandrichdalias@hachyderm.ioOct 5, 2026, 2:11 PM
- Oct 5, 2026, 3:29 PM
- Oct 5, 2026, 4:39 PM@neal @dalias @elly @cas Well EDKII, at least on Honeycomb LX2K, has a toggle between ACPI and DeviceTree.
And IIRC (noticed a bad ram address it something like 6 months ago, haven't booted it since) in-spi u-boot on the VisionFive2 also provides it's DeviceTree to the kernel.
And I guess on RockPro64 where you can have in-spi u-boot, it could be provided in the same way if not already the case (as there's even the tow-boot project providing pre-built u-boot images to be flashed). - Oct 5, 2026, 12:40 PM
@ryanabx i still think it's the right approach and could make it but i didn't have the time to finish it
the ability to easily understand occlusions in a bootloader for example to shift text out the way, but have pixel perfect knowledge in the OS would be great