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

[Maxime Devos <maximedevos@telenet.be>]

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

On 22-08-2022 12:52, Pavel Shlyak wrote:

> > If the user really wants to choose a different DT, they can 
> customise their kernel by overriding the sourcce.
> Yes, unless it’s generated by bootloader.
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.
> > why not submit the bootloader DT to the kernel?
> Because it passes board-specific parameters. We cannot submit DTs for 
> all board revisions, memory sizes etc.
If the bootloader can, surely the kernel can.
> > You write that the system definition can both boot with the 
> kernel-provided FDT and bootloader FDT, then why are you writing this 
> patch if things work?
> It can boot on RPI4b, but not on RPI3b+ or Compute Module 4
I believe the kernel folks will appreciate a patch fixing the DT for 
RPI3b+ and Compute Module 4.
> > The kernel has multiple DTs. I assume that, somehow, the kernel can 
> figure out which one.
> DTs are loaded by the bootloader. Kernel cannot figure anything out.

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.

> > If you must go for this work-around, you could try porting the logic 
> that the kernel
> No, kernel does not include this logic
The page 
https://www.kernel.org/doc/html/latest/devicetree/usage-model.html 
mentions various properties for specifying the model in the DT info, it 
has a section '2.2 Platform Identification' on how Linux decides which 
one is the right one. Plenty of logic there.
> > AFAIK, device tree information is used by the kernel, not the bootloader.
> Uboot uses DT on some platforms
OK. Is the board you are trying to support one of them, and does for 
that case the pre-patch behaviour suffice there (Linux will load its own 
DT later anyway?).

This response makes me wonder where the boot failed -- did it fail in 
the bootloader, or in the kernel startup?

> > I don't see the point if updating the DT in the kernel appears to be 
> sufficient.
> I hope dynamic DT with some data that only bootloader can know is 
> sufficient for you. 

It is neither sufficient nor insufficient for me -- it is you that is 
adding support for some boards, not me, GRUB+x86_64 works just nice here.

Besides, the bootloader/kernel distinction is just a matter of 
convention, bootloaders don't magically have access to more information 
than kernels. Anything a bootloader can determine, a kernel can as well, 
and vice-versa, they are both just software running on a CPU and various 
associated hardware.

> Again, this is how things work on Raspberry and some other boards on 
> any distro. We don’t support that - we don’t support these devices.

That's what I thought the patch was for -- adding support for some 
devices, turning the "it's not supported" into an "it's supported". 
Moving support from the bootloader to the kernel would accomplish that 
as well. Also, ad populum.

If you don't want to support new platforms, that's fine, but why are you 
sending a patch then?

> I personally don’t loose much as we can apply this patch directly on 
> pantherx channel, making pantherx richer in device support. However, I 
> do not quite like the idea of me answering «Install PantherX» to the 
> people who cannot get GUIX on their devices.

My point is that supporting more devices would be nice, but this patch 
isn't the way to do it.

Additionally, the proper capitalisation is Guix, GUIX is another thing.

Greetings,
Maxime.


[-- Attachment #1.1.1.2: Type: text/html, Size: 7301 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 --]