undefined | Better HN

0 pointstmzt29d ago0 comments

While it's true that early Linux ARM devices where embedded and generally only supported a single configuration, they didn't actually use devicetree.

Originally, embedded Linux ARM devices used a board file with a platform bus and hard-coded device metadata. The bootloader had to pass a machine id which told the kernel which hardware you were running on and which board file to use.

You can see remenants of this in the kernel still, though it's quickly being removed. I'm actually working on a hybrid kernel with the goal of bringing modern Linux support (on an lts branch) to old MSM7x300 devices, like the Evo 4G Shift I intent to use a tmux console/cyberdeck.

On another note, ACPI/UEFI doesn't always give you a clean abstract surface to work with either. ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies to it about what OS is running.

0 comments

bri3d28d ago

I remember that era (and it's still present on some other architectures) - devicetrees were at least a huge improvement over compile-time board config!

> ACPI/UEFI doesn't always give you a clean abstract surface to work with either.

That's putting it lightly. I think the best abstraction would probably land somewhere inside the big gap in the board config headers -> devicetree --------------> ACPI complexity continuum, but I'm not sure it's possible to do that at this point in the game as both sides are so entrenched.

> ACPI is notorious for building in OS checks into it's compiled bytecode to the point that Linux often lies

The problem with ACPI in this dimension is that there's a bidirectional errata game: the bytecode tries to work around the OS and the OS tries to work around the bytecode.

Unfortunately, there was never a real version standard for the Linux firmware interface early on (the _OSI("Linux") debacle), so the only testable versioned ACPI interface is Windows. This means that Linux is basically forced to become a Windows ACPI emulator. I think there are political reasons for this (obviously the 90s and 2000s were a bad time for Linux/Microsoft coexistence) but also just some decisions that look like big engineering mistakes in hindsight - the historic allergy of Linux maintainers to any kind of specified or versioned interface aimed at anything but user land definitely strikes again here.

I think that the versioning/errata issue and the native code trapdoor are the two biggest issues with ACPI (and admittedly both are large enough to drive a bus through); otherwise it's a kind of nasty thing but it fills in nicely for a lot of much nastier ideas and covers a really broad problem space reasonably well.

j / k navigate · click thread line to collapse