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

[Dan Cross via TUHS]

On Mon, Apr 6, 2026 at 5:02 PM ron minnich via TUHS <tuhs at tuhs.org> wrote:
> I'm trying to refresh my memory on something.
>
> The first machines to have a device tree were, .. Sun 4/Power/Mac? Of
> these, which was first, first?

Sun, with OpenBoot, for sure.

> The intent of the device tree was to be embedded in a ROM (or writable ROM)
> such that a kernel could figure out properties of hardware, as I recall.

As I understood it, it was constructed in memory by the ROM monitor,
and the OS walked and parsed it, by reaching back into the PROM
monitor to get the actual data.

> Is this even vaguely correct? It seems to track with my current digging.

I think it served two purposes: 1) it provided some mechanism for the
machine to boot. If the OS was on a storage device that itself is on
the far side of an HBA that needs non-trivial support to get itself
going, what do you do? Answer: embed an interpreter for a small,
low-level language into your ROM monitor and have an option ROM on
each device that contains a program in that language with enough
smarts to load a real OS from it. Sun chose Forth, but UEFI went a
different route. 2) provide an accounting of the machine that the OS
could absorb so that it didn't have to (re)probe everything.
Presumably the PROM monitor had already enumerated the SBus or PCI; in
that case, having the OS do it again feels like busy-work.

I think now days we mostly use it for the latter, and the former has
been more or less lost.

> The reason I ask: somehow, the device tree is now something that gets
> packaged with the kernel, which seems a violation of its purpose.

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.

> But, for
> example, linux kexec on risc-v will fail (EINVAL) if it is not passed a
> device tree. The Image struct for arm and riscv usually has a device tree
> at the front. And the risc-v linux source includes a bunch of device trees.
> For some boards, there is more than one choice, and if you pick the wrong
> one, you get a brick.
>
> Was the device tree a Mitch Bradley thing?