| |
| ▲ | M95D 4 days ago | parent | next [-] | | 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. | | |
| ▲ | pjmlp 3 days ago | parent [-] | | IBM PC is the exception here, because how clones came to be, actually. So ARM did what everyone else has always have done. |
| |
| ▲ | jdub 4 days ago | parent | prev | next [-] | | Take a look at how modern PCs enumerate all of their non-PCI hardware. I'll put a bucket over here. | | | |
| ▲ | M95D 4 days ago | parent | prev | next [-] | | > 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? | | |
| ▲ | yjftsjthsd-h 4 days ago | parent [-] | | Many years of x86_64 PCs would seem to imply that it empirically has better outcomes. | | |
| ▲ | M95D 3 days ago | parent [-] | | 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 |
|
| |
| ▲ | M95D 4 days ago | parent | prev [-] | | 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)? |
|
