> * the x86 world resolves around standards such as ACPI, BIOSes and general-purpose dynamic buses.
> * ACPI normalises every single piece of hardware from the perspective of most low-level peripherals.
> * the BIOS also helps in that normalisation. DOS INT33 is the classic one i remember.
> * the general-purpose dynamic buses include:
- USB and its speed variants (self-describing peripherals)
- PCI and its derivatives (self-describing peripherals)
- SATA and its speed variants (self-describing peripherals)
> exceptions to the above include i2c (unusual, and taken care of by i2c-sensors, which uses good heuristics to "probe" devices from userspace) and the ISA bus and its derivatives such as Compact Flash and IDE. even PCMCIA got sufficient advances to auto-identify devices from userspace at runtime.
> so as a general rule, supporting a new x86-based piece of hardware is a piece of piss. get datasheet or reverse-engineer, drop it in, it's got BIOS, ACPI, USB, PCIe, SATA, wow big deal, job done. also as a general rule, hardware that conforms to x86-motherboard-like layouts such as the various powerpc architectures are along the same lines.
> so here, device tree is a real easy thing to add, and to some extent a "nice-to-have". i.e. it's not really essential to have device tree on top of something where 99% of the peripherals can describe themselves dynamically over their bus architecture when they're plugged in!
> now let's look at the ARM world.
> * is there a BIOS? no. so all the boot-up procedures including ultra-low-level stuff like DDR3 RAM timings initialisation, which is normally the job of the BIOS - must be taken care of BY YOU (usually in u-boot) and it must be done SPECIFICALLY CUSTOMISED EACH AND EVERY SINGLE TIME FOR EVERY SINGLE SPECIFIC HARDWARE COMBINATION.
> * is there ACPI present? no. so anything related to power
management, fans (if there are any), temperature detection (if there is any), all of that must be taken care of BY YOU.
> * what about the devices? here's where it becomes absolute hell on earth as far as attempting to "streamline" the linux kernel into a "one size fits all" monolithic package.
> the classic example i give here is the HTC Universal, which was a device that, after 3 years of dedicated reverse-engineering, finally had fully-working hardware with the exception of write to its on-board NAND. the reason for the complexity is in the hardware design, where not even 110 GPIO pins of the PXA270 were enough to cover all of the peripherals, so they had to use a custom ASIC with an additional 64 GPIO pins. it turned out that that wasn't enough either, so in desperation the designers used the 16 GPIO pins of the Ericsson 3G Radio ROM, in order to do basic things like switch on the camera flash LED.
> the point is: each device that's designed using an ARM processor is COMPLETELY AND UTTERLY DIFFERENT from any other device in the world.
https://lists.debian.org/debian-arm/2013/05/msg00009.html