From: Maxime Devos <maximedevos@telenet.be>
To: Pavel Shlyak <p.shlyak@pantherx.org>, 57070@debbugs.gnu.org
Subject: [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR
Date: Mon, 22 Aug 2022 10:54:06 +0200 [thread overview]
Message-ID: <85904cd4-576d-81d0-2cfc-05ff0ab802a6@telenet.be> (raw)
In-Reply-To: <483BAA4D-ADDE-43C2-B1E3-BADAD7C43E7D@pantherx.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2183 bytes --]
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.
[-- 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 --]
next prev parent reply other threads:[~2022-08-22 8:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-09 10:27 [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR Reza Alizadeh Majd
2022-08-09 10:30 ` Reza Alizadeh Majd
2022-08-15 9:27 ` Mathieu Othacehe
2022-08-16 18:10 ` Reza Alizadeh Majd
2022-08-25 17:35 ` Mathieu Othacehe
2022-08-28 8:19 ` Reza Alizadeh Majd
2022-08-28 15:49 ` Mathieu Othacehe
2022-08-29 18:17 ` Reza Alizadeh Majd
2022-08-30 6:53 ` bug#57070: " Mathieu Othacehe
2022-08-10 9:31 ` [bug#57070] " Maxime Devos
2022-08-15 10:57 ` Tobias Geerinckx-Rice via Guix-patches via
2022-08-10 9:32 ` Maxime Devos
2022-08-16 17:08 ` Reza Alizadeh Majd
2022-08-16 18:44 ` Maxime Devos
2022-08-10 14:37 ` Pavel Shlyak
2022-08-11 10:00 ` Maxime Devos
2022-08-11 11:13 ` Pavel Shlyak
2022-08-10 14:46 ` Pavel Shlyak
2022-08-20 10:15 ` Pavel Shlyak
2022-08-22 8:54 ` Maxime Devos [this message]
2022-08-22 10:52 ` Pavel Shlyak
2022-08-22 18:57 ` Maxime Devos
2022-08-22 19:19 ` Pavel Shlyak
2022-08-22 21:17 ` Maxime Devos
2022-08-22 21:29 ` Pavel Shlyak
2022-08-23 18:11 ` Vagrant Cascadian
2022-08-25 19:16 ` Pavel Shlyak
2022-08-30 6:52 ` Mathieu Othacehe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85904cd4-576d-81d0-2cfc-05ff0ab802a6@telenet.be \
--to=maximedevos@telenet.be \
--cc=57070@debbugs.gnu.org \
--cc=p.shlyak@pantherx.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).