On 9/2/25 3:50 AM, Vincent Stehlé wrote:
On Mon, Sep 01, 2025 at 06:23:04PM +0200, Casey Connolly wrote:
Hi all,
Sorry for the inactivity on this one, I'm hoping we can find some
agreeable solution.
We had some discussion on the GitHub PR [1] where Krzysztof suggested
that this property is duplicating the compatible property, while I wish
this were the case it is not true that the DT file names follow any kind
of scheme that can be reliably derived from the root compatible property.
## Problem description
I guess before trying to decide on solutions we should be able to agree
on the problem, for which we need to agree on some facts:
Fact 1: The kernel and devicetree are not always forwards/backwards
compatible with each other
Fact 2: Not all ARM platforms ship with a usable firmware-provided
devicetree
Fact 3: Users expect to be able to install their favourite Linux distro
with minimal effort
Given (2) and (3) we need to provide a mechanism to load the correct
devicetree and overlays with minimal/trivial user intervention.
Given (1) we should always try to load the DT and overlays that were
shipped with the kernel even if the platform provides its own (while
there may be a case where this is undesirable for some reason I would
argue that this would be an exception and not the rule and is not
directly relevant here).
Hi Casey,
I understand the problem that you are facing, and that you are looking
for a practical solution.
In the long run, I believe that we can address this by:
- Validating firmware-provided Devicetrees.
I'm not sure what this solves. The Devicetree provided by firmware is
almost always just one from the Linux kernel at some specific point in
time, (usually the vendor's LTS kernel when the firmware was built).
So not sure what "validating" does here, it will be a valid DT for,
let's say Linux v5.15, but maybe not necessarily valid for an earlier
or later kernel.
- Making sure that newer OSes are backward compatibles with older
Devicetrees.
A nice goal to work towards, but this has not been the reality in
practice, nor do I think it will be in the near future.
DTBs have bugs too, so it is not just that an old DT might not be
"compatible" with a new OS, it might also be buggy. Fixups and quarks
in kernel can help, but since updated DTs are shipped with updated
kernel, why prefer the firmware provided one when we can use an
updated one meant for the specific OS and version we are booting.
There is also not just backwards compat, but forward compat. For
instance if I update my firmware, it now provides the latest DT,
which may not be compatible with the slightly older kernel I was
using before the update.
Andrew
If the OS wants to use another Devicetree than the firmware-provided
one, that is fine, too.
## Potential solutions
Assuming that we can agree on the above, there is clearly the need for a
distro-agnostic mechanism to handle loading the right DT and overlays
for the device and kernel version that will be booted.
Since there is no standard path for the DTB files on the ESP, and the
EFI firmware doesn't know which kernel version will be booted this task
can't be handled by the firmware itself (and even then, it would be
difficult to drive adoption particularly for boards already in production).
This leaves us with the following high level options:
Option 1: Create some kind of EFI driver/shim to load the DTB and rely
on the user to keep it up to date.
Option 2: Engage with systemd-boot/GRUB developers and improve the DTB
loading experience, e.g. by retrieving the (relative) DTB path
(qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb
dir (typically tied to the kernel version being selected)
Option 1 has been attempted already with dtbloader[2] which has seen
some very minor adoption, it also causes problems with secureboot and
other potential compatibility issues.
## My proposal
Thus I propose Option 2, specifically introducing a devicetree-directory
config option to the UAPI group BLS (Boot Loader Specification) that
would specify the dtbs directory which the dtb path would be appended
to, hopefully with a similar option added to GRUB.
This still leaves the issue of identifying the path to the DTB file (and
potentially overlays). If there is a firmware provided DTB the root
compatible property SOMETIMES is enough to derive the path, but often is
not.
When the information in the Devicetree is not enough to compute the path
you need unambiguously, do you think the firmware-provided informations
at large (SMBIOS, etc.) or even hardware-provided informations are not
enough, or is this rather the OS-specific bits, which are missing?
Best regards,
Vincent Stehlé
System Architect - Arm
So what it all boils down to is that we still need a way for the user to
manually enter the DTB path, but at least it should only be necessary to
do it once. Ideally we can get this implemented in systemd-boot and GRUB
so that the file can be specified once and is then stored in an EFI
variable, so if the user boots another distro or something then the
variable is used.
## The devicetree-path chosen property
Lastly, and the motivation for my DT schema PR, is further optimising
this process so that the requirement for user intervention is minimised
where possible. My proposal would allow bootloader like U-Boot to embed
the DTB path into the DT itself at build time, then at runtime it would
be able to set the EFI variable so that no user intervention is
required. This is done rather than embedding the path into the U-Boot
binary itself since some U-Boot targets are generic across multiple boards.
The only viable alternative to adding a property like this would be to
actually enforce that the DTB path and compatible property encode the
same information so that the path can be derived at runtime, this would
require huge changes on the kernel side which I don't feel is justified
since it wouldn't even fully solve the underlying issue.
I hope this email clarifies the issue at hand and my stance on this
topic, it definitely makes me realise there's no reason not to push
forwards with my suggest OS loader changes.
[1]: https://github.com/devicetree-org/dt-schema/pull/167
Kind regards,
--
// Casey (she/her)
_______________________________________________
boot-architecture mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
boot-architecture mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
boot-architecture mailing list -- [email protected]
To unsubscribe send an email to [email protected]
