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.Google «device tree raspberry bootloader», 1st result https://forums.raspberrypi.com/viewtopic.php?t=329799
That web page does not claim that anywhere.
If the bootloader can, surely the kernel can.Bootloader runs on GPU on Raspberry. It cannot run kernel. Also, check m1n1 on Apple. It has docs.
I have never claimed that the GPU can run the kernel.
What does m1n1 have to do with anything here? m1n1 isn't extlinux and isn't packaged in Guix.
Bootloaders running on the GPU is something I'm not used to at
all, it's not something I had expected, see later.
I believe the kernel folks will appreciate a patch fixing the DT for RPI3b+ and Compute Module 4.And for other devices that behave the same way? You’re literally promoting making GUIX not bootable on all devices alike.
I literally never wrote such a thing. In what sentences did I
promote that?
Even if you meant 'implied' instead of 'literally', then that still doesn't make sense to me; I'm running Guix System, it's in my own interest to keep it bootable on my device.
I did search for it, figuring out an _appropriate_ query and finding relevant results is another matter.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. I could not find any information on bootloaders loading DTs.Because you didn’t search for it.
No. It has monopoly and privacy problems.
Generating the DT is a different matter from loading the DT. It's also about firmware, not the bootloader.«device tree raspberry bootloader», the first link is about bootloader forming the device tree https://forums.raspberrypi.com/viewtopic.php?t=329799.
These overlays look rather manual, to be done by the user for individual models, I don't see the relevancy.Google «uboot device tree» https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html to know how uboot manipulates them.
Going by the mention of 'defconfig' and 'arch/arm' and 'configs', this appears to be a patch to Linux, not uboot. As such, it appears that the device tree information is used by Linux here, there is no information there on whether it is used by U-Boot.Moreover, Raspberry PI uboot uses DTB to boot on the board as in https://patchwork.ozlabs.org/project/uboot/patch/20191106144104.28177-1-matthias.bgg@kernel.org/ (Instead of using the embedded DTB as done in RPi3 we use the devicetree provided by the firmware.)
bootloaders don't magically have access to more information than kernelsThey do, if they are run on a separate core on the SOC that linux or arm core has no access to. Check https://github.com/christinaa/rpi-open-firmware
That's a setup I would not have expected.
AFAIK nothing is stopping Linux from sending some code to the
separate core to figure out the relevant information and sending
it back to Linux. But given the unusual setup, I would consider it
plausible that Linux people want to delegate such responsibility
to the bootloader.
If so, figuring out the appropriate options to let U-boot pass
the device tree to Linux seems reasonable to me.
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.
And is this a bad thing, and if so, perhaps FDTDIR could be added to the specification? Guix being in violation of some specification is not in itself a bug, for example the store model of Guix is not 'Linux Standard Base'.
It might be a bad thing, but there's a step missing in your argument.
Since we’ve not come to any understanding here, I kindly invite Vagrant and Tobias to join the discussion. They seem to be familiar with the relevant parts of GUIX.
See the 'If so, figuring out the appropriate options ...' above.
Also, again, it's Guix, not GUIX. GUIX is a Microsoft thing.