[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.
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, (continued)
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Maxime Devos, 2022/08/10
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Maxime Devos, 2022/08/10
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/10
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/10
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/20
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR,
Maxime Devos <=
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/22
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Maxime Devos, 2022/08/22
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/22
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Maxime Devos, 2022/08/22
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/22
- [bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Vagrant Cascadian, 2022/08/23
[bug#57070] [PATCH] bootloader: extlinux: support for optional FDTDIR, Pavel Shlyak, 2022/08/25