[TUHS] the device tree, hardware, and kernels.

[Dan Cross via TUHS]

On Mon, Apr 6, 2026 at 7:12 PM segaloco via TUHS <tuhs at tuhs.org> wrote:
> On Monday, April 6th, 2026 at 15:50, Dan Cross via TUHS <tuhs at tuhs.org> wrote:
> > I can kind of see it.  For a small SBC where devices are physically
> > soldered onto the board, there's not a lot of expansion to be done:
> > the device tree itself is pretty much static.  If you just plop it
> > into an flash device or something, you can skip the full PROM
> > monitor/Forth interpreter/option ROM thing.
> >
>
> Well and the prevailing SBC ecosystems aren't nearly as standardized as PC has historically been.  These devices don't have some least common denominator "I'm an 8086 with bus characteristics <xyz>" so the kernel needs a little more help.  DTB to me is better than having to go twiddling baked in kernel addresses at build time, then you really do need a kernel-per-machine rather than being able to spin a "defconfig" kernel that'll hopefully at least give you serial TTY on whatever you're messing with.  Plus, sometimes this means if you already have kernel support for device *xyz* in your current image and add one such device at some I/O address, you just have to rebuild your dtb rather than the kernel hiding all of that info deep inside.  Much lower risk to roll back a dtb than a whole kernel too.

Trust me, the PC world ain't that standard, either. :-D

UEFI has devolved as a way to paper over the differences between
systems at the mainboard level, and it serves a similar function as
OpenBoot: it gives the board vendors a place to do platform
enablement: initializing IO bridges and kicking off PCIe links
training, allocating physical address space for MMIO, etc; it also
bundles up a bunch of information about the system so that software,
specifically kernels and boot loaders, is reasonably decoupled from
the underlying hardware; and it solves the boot problem: vendors can
plug their device-specific code into a UEFI stack and ship it in flash
or on a ROM and it can start devices "enough" to load a boot loader or
OS. It also subsumes the traditional BIOS function of being a
least-common denominator for driving IO devices: it can implement USB,
for example, and provide simulation of PS/2 keyboards and mice for
OS's that don't know how to drive USB HID devices (the system trapping
through SMIs and SMM to reach into the UEFI layer, so the system is
none the wiser), for example.

But on balance, ACPI tables are like device trees in a lot of ways;
some would argue they're less expressive and overall the whole UEFI
stack is a lot less elegant than OpenBoot was. I would agree with
them.

> Annoyingly it makes provision of quality documentation on memory maps and bus architecture a little worse, seems like you just have to "trust the dts" in many cases these days...

Sadly, with very few exceptions, we generally "trust" that the ACPI
tables firmware leaves in memory adequately describe the system, too.
Nothing new under the Sun.... (Sorry for the terrible pun.)

        - Dan C.