On 20-08-2022 12:15, Pavel Shlyak wrote: > I do not think I can agree that «a relevant code could check what the hardware is» as it’s not hardware-defined, but also user-defined. It’s not just about detection, it’s also about choice. The same system definition I have on RPI4, for example, can boot both with kernel-provided FDT (loaded with uboot) and bootloader-provided FDT (loaded with RPI bootloader). If the user really wants to choose a different DT, they can customise their kernel by overriding the sourcce. If the bootloader DT is more precise than the kernel DT (or the kernel DT is missing), why not submit the bootloader DT to the kernel? Then everyone can benefit, not only people using the 'RPI bootloader.' Between an inferior and a superior DT, I do not see the point of providing an option in Guix for selecting the inferior one. Likewise, if they are equivalent, I don't see the point either. 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? > There are also a lot of different devices out there on the market and there’s no common way to know how OS definition is written for it. If you have ideas - you’re welcome to propose your way to do it. The kernel has multiple DTs. I assume that, somehow, the kernel can figure out which one. If you must go for this work-around, you could try porting the logic that the kernel uses to figure out the right DT, and extend it for the device that required the patch. > It does not appear to «be simply a kernel bug» to me. Kernel does not pass configuration to the bootloader and we’re configuring a bootloader entry here. It’s simple as that: bootloader entry may include or not include that line and that’s user-defined. AFAIK, device tree information is used by the kernel, not the bootloader. AFAIK, at most the bootloader passes a DT to the kernel.  We could just not support overriding the DT in Guix in the bootloader entry? I don't see the point if updating the DT in the kernel appears to be sufficient. Greetings, Maxime.