On 2022-08-22, Pavel Shlyak wrote:
>> Could you point me at the documentation or code that claims or does
>> that? I am not finding any evidence that device trees are generated
>> at boot.

I don't know exactly where in the code off the top of my head, but
u-boot definitely has support for modifying the device-tree it passes to
the kernel, and in some cases (e.g. memory layout, framebuffer)
*requires* modifying the device-tree that is passed to the kernel. FWIW,
I say this as someone who's maintained u-boot in debian (and to some
degree guix) for years...

Also, for some virtual platforms (qemu-riscv64?) the device-tree is
created on-the-fly when bootstrapping the virtual machine; in these
cases you have to rely on the device-tree passed via the boot "firmware"
as you shouldn't need to recompile the kernel just to pass a different
set of qemu arguments!

There are cases where the kernel cannot possibly track the combinatorial
explosion of potential add-on hardware modules (rpi hats, beagleboard
capes, etc.) that need to be represented in the device-tree in order to
work, sometimes before the kernel is even booted. There is some support
for device-tree overlays both in-kernel and in u-boot (and plausibly
other bootloaders) kernel to handle this, but in many cases, a simpler
and more reliable method is to provide a single custom device-tree.


> And for other devices that behave the same way? You’re literally
> promoting making GUIX not bootable on all devices alike.
>
>> DTs are a kernel thing, e.g. the Linux documentation
>> https://www.kernel.org/doc/html/latest/devicetree/usage-model.html
>> mentions DT, also, Linux.

Yes and no. Device-trees are used in, by and for both bootloaders and
kernels alike. There is long-standing debate around device-tree should
being treated as a boot firmware thing rather than a kernel thing. There
are some pretty simple questions:

You don't see ACPI tables for every supported x86 board in the kernel,
why should boards using device-tree be any different?

Why is the linux kernel the source of device-trees for, say, the Hurd,
*BSD, etc.?

So yes, it is de-facto where most device-trees come from at the end of
the day, but ... that doesn't necessarily mean it *should* be.


>> I could not find any information on bootloaders loading DTs.

Well, that's what the FDTDIR and FDT settings for extlinux do; it tells
the bootloader (e.g. u-boot) to load a device-tree. Grub also has a
devicetree option, though no correlary to FDTDIR. If grub isn't passed a
devicetree argument, it passes whatever devicetree that was passed from
the boot firmware, as I understand it.


>> My point is that supporting more devices would be nice, but this patch isn't the way to do it.
>
> Well, there is no other way to support devices that require DTB not to be loaded with uboot. The solutions you suggest are not possible.
>
> Moreover, keep in mind FDTDIR is not in the http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ specification and making is permanent we basically violate it. 

Hrm, that's unfortunate. I daresay supporting FDTDIR is a good thing, as
it allows you to use the same boot media to boot multiple different
devices, presuming they all have a .dtb present for the relevent boards.


Booting arm systems have come a long way from you need a specifically
compiled kernel for every different board, but it is still a horrible
mess.

Sometimes things are implemented in kernel, sometimes in the bootloader,
sometimes in the boot firmware, with possibly 3-4 different boot
firmware layers... and exactly where may be specific to a particular
board. There are arguments that any particular thing might be better
implemented at any of those layers, and maybe there is a convincing
reason to move something from one layer to another...

At the end of the day, the reality is that board support for some
platforms (e.g. arm* and possibly riscv*) is a mess of inconsistancy and
the usually you need to support multiple different ways of doing
seemingly the same things.

I think this tends to be hidden from view for x86 as quirks are just
worked around in the kernel, whereas with some platforms where more of
the boot firmware is free software it is possible to fix it in a more
appropriate layer... or whatever layer the someone just happens to get
it to work at first!


If adding an option to drop the FDTDIR extlinux configuration allows
booting more platforms, I see no fundamental reason why it is wrong, as
long as it doesn't break existing platforms... the implementation
details, I'll leave to people more savvy with scheme. :)


live well,
  vagrant