[bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 4909 bytes --]


On 22-08-2022 21:19, Pavel Shlyak wrote:
> Subject:
> Re: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
> From:
> Pavel Shlyak <p.shlyak@pantherx.org>
> Date:
> 22-08-2022 21:19
>
> To:
> Maxime Devos <maximedevos@telenet.be>
> CC:
> 57070@debbugs.gnu.org, vagrant@debian.org, Tobias Geerinckx-Rice 
> <me@tobias.gr>
>
>
>> 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 resulthttps://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.

>> DTs are a kernel thing, e.g. the Linux documentationhttps://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.
I did search for it, figuring out an _appropriate_ query and finding 
relevant results is another matter.
>   Google
No. It has monopoly and privacy problems.
>   «device tree raspberry bootloader», the first link is about bootloader forming the device treehttps://forums.raspberrypi.com/viewtopic.php?t=329799.
Generating the DT is a different matter from loading the DT.  It's also 
about firmware, not the bootloader.
>   Google «uboot device tree»https://u-boot.readthedocs.io/en/latest/usage/fdt_overlays.html  to know how uboot manipulates them.
These overlays look rather manual, to be done by the user for individual 
models, I don't see the relevancy.
> Moreover, Raspberry PI uboot uses DTB to boot on the board as inhttps://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.)
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.
>> bootloaders don't magically have access to more information than kernels
> They do, if they are run on a separate core on the SOC that linux or arm core has no access to.  Checkhttps://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.

Was this (i.e. "they are run on a separate core on the SOC ...") the 
case for the Raspberry device you are trying to support?

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 thehttp://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.

Greetings,
Maxime

[-- Attachment #1.1.1.2: Type: text/html, Size: 12394 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]