Hacker News Reader

Comment by fragmede | Hacker News Reader

Fascinating! I've been running the laptop version-ish of this experiment with the 14M9610, and my major complaint is Device Tree sucks. It's been explained to me why all of ARM can't just enumerate devices like PCs do, but it still sucks. This means every ARM device starts off in custom kernel territory, which makes all sorts of hacks okay to begin with, since you need a custom kernel anyway.

View on HN

ACPI does exist for Aarch64, but is only really used for Windows client devices, and server hardware - though I think the Ampere hardware in the article would use ACPI not DT.

If you want to run Linux on one of the modern Qualcomm Windows laptops, you still generally end up needing to use device tree.

This is not completely true. You can use a generic kernel with a custom device tree.

The only problem is that distributions currently tend to package them together, but that shouldn't be obligatory.

You can't if the firmware provided DTB doesn't follow any upstream Linux approved bindings and instead uses some vendor kernel specific bindings.

Why would you combine mainline kernel with manufacturer device tree? Kernel includes its own device trees.

(S)he has a point. Sometimes the vendor dtb is all you have.

> my major complaint is Device Tree sucks

Why? Device tree is great. You can patch it yourself if something doesn't work, add overlays, etc.

It's a bad solution compared to having the hardware just enumerate itself like PCI does. (No one uses the firmware supplied DTs because they're usually broken.)

Take a look at how modern PCs enumerate all of their non-PCI hardware. I'll put a bucket over here.

All IBM PC clones had (or emulated) the same 8253 timer, 8259 PIC, 8237 DMA controller, 8042 keyboard controller, CMOS RTC, 8250/16550 serial port, standard IDE/PATA, standard framebuffer addresses, standard PCI and ISA register addresses, FPU was always at IRQ13, mouse at IRQ12, RTC at IRQ8, LPT at 0x378, PC speaker at 0x61, etc.

All this doesn't require any enumeration and was still standard until BIOS/CSM was removed. PCs could use the same IDE driver for 30 years of hardware! All chipsets were compatible, from 386 to today's SATA in compatibility mode.

ARM made the mistake of not standardizing anything beside CPU instructions (and even those aren't always the same - see the mess armv7 created with thumb, thumb-ee, simd, neon, crypto acceleration, etc.). Of course it needs enumeration. But x86 is now catching up with the mess. Just wait...

Enumeration instead of standardized hw is bad, but I prefer the least worse device tree.

IBM PC is the exception here, because how clones came to be, actually.

So ARM did what everyone else has always have done.

But ARM has PCI, including it's enumeration. For the many other devices (timer, uart, I2c, PCI controller itself) no enumeration is possible - you can't enumerate searching for a timer without having a working timer - only a hardware description stored somewhere is possible. The device tree is the most logical, easy to understand, fixable, updateable and extendable way to describe hardware. It doesn't have executable code like ACPI does, and that's also one of the good things.

Let's take an example. Raspberry Pi doesn't have a RTC, but it has GPIO header. You add a RTC module on that header, one of several models of RTCs.

With the device tree, you load an overlay with some parameters and a kernel driver module. And it works.

How do you do that with ACPI? Ask the manufacturer for a UEFI update that scans for dozens of RTC types on each I2c bus? Good luck with that! What happens 5 years later when the board is long abandoned (not Raspberry's case, but think of an ordinary chinese manufacturer)?

> No one uses the firmware supplied DTs because they're usually broken.

Oh, and an even more complex UEFI+ACPI solution won't be broken?

Many years of x86_64 PCs would seem to imply that it empirically has better outcomes.

My own experience is the opposite. Since ~2006 when I fist started using Linux, all systems had ACPI errors in Linux, sometimes making some hw components completely unusable in Linux. Device tree boards either just worked (Raspberry) or I patched them until they did (Asus, Radxa).

And you don't have to belive me. See what Linus said[1] about ACPI:

> [...] ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry [...]

[1] https://lkml.iu.edu/hypermail/linux/kernel/0507.3/2331.html

Reply on news.ycombinator.com