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. - Making sure that newer OSes are backward compatibles with older Devicetrees. 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 -- boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
