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.