logoalt Hacker News

rwmjyesterday at 10:32 AM4 repliesview on HN

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.)


Replies

M95Dyesterday at 11:48 AM

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.

jdubyesterday at 10:49 AM

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

show 1 reply
M95Dyesterday at 1:01 PM

> 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?

show 1 reply
M95Dyesterday at 12:06 PM

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)?