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

[ron minnich via TUHS]

in linux, there are 236 files in the riscv part of the tree, for 60 boards.
Riscv kexec is pretty insistent on having a dts for kernels it boots.

There are 2821 files fitting this pattern: "dts$" in the tree. They seem to
each apply to one board; in some cases, there are DTS for different
versions of the same board (I'm seeing this with some risc-v boards).

 I think my notions of where the DTS lives are pretty much obsolete :-)

Anyway, thanks all, and especially Tom for getting Mitch here, and to Mitch
for his reply :-)



On Mon, Apr 6, 2026 at 3:12 PM segaloco via TUHS <tuhs at tuhs.org> wrote:

> On Monday, April 6th, 2026 at 14:02, ron minnich via TUHS <tuhs at tuhs.org>
> wrote:
>
> > The reason I ask: somehow, the device tree is now something that gets
> > packaged with the kernel, which seems a violation of its purpose.
>
> Somewhat, you get a DTB in your boot partition (usually FAT to appease
> UEFI these days afaik) but this boot partition may be loading a kernel
> directly on some systems, dropping in a uboot loader on others, but the DTB
> gets loaded usually pretty darn early, in my experience prior to jumping
> into the actual kernel bootstrap, much like how PCs dump a bunch of
> information in a know memory location ala BIOS for the bootstrap to
> inspect.  Granted the sources that become DTBs I see distributed as DTSs
> with i.e. the Linux kernel.  I don't know DTB holistically, if there is
> some upstream that feeds the penguins or if they run the show on their DTB
> stuff.
>
> > The Image struct for arm and riscv usually has a device tree
> > at the front.
>
> This is not my experience on Raspberry Pi and RISC-V distros of Linux and
> FreeBSD I've used.  They all had a directory of DTBs in their boot
> partition that were selected from by whatever bootloader stage straps in
> the kernel, initramfs, etc.  The kernel Image file, initrd, and dtb are
> transferred as separate BLOBs, so could exist independently of one another.
>
> - Matt G.
>