[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Maxime Devos
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Mon, 22 Aug 2022 10:54:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

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.


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]