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).
## 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.
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,