GNU bug report logs - #57070
[PATCH] bootloader: extlinux: support for optional FDTDIR

Previous Next

Full log

View this message in rfc822 format

From: Maxime Devos <maximedevos <at> telenet.be>
To: Pavel Shlyak <p.shlyak <at> pantherx.org>, 57070 <at> debbugs.gnu.org
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Mon, 22 Aug 2022 10:54:06 +0200

[Message part 1 (text/plain, inline)]

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.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.