On 03/09/2025 01:27, Andrew Davis wrote:
> On 9/1/25 11:23 AM, 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).
>>
>
> These facts were brought up by a colleague of mine at Linaro Connect
> last year, relevant part starting at 16:30, good summary of this
> whole topic IMHO[0].
Oh thanks for the link! I wasn't aware of this but I'm glad to see
there's more awareness of this issue.
>
>> ## 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.
>>
>
> At some point U-Boot knows the DTB path, whether detected at runtime for
> multi-board support[1], or embedded at build-time, the end result is the
> same, U-Boot knows the (non-versioned) DTB path. How it gets the path isn't
> really an issue, how to pass this off to the next stage is the focus.
>
> Anyway, to break down the problem, the kernel loader(systemd-boot/GRUB)
> knows what kernel it is booting and knows where to find that specific
> kernel's DTB directory. It doesn't know *which* DTB though. The firmware
> (or whatever comes before the loader), knows the DTB's filename, but not
> the OS/version specific directory path to find the right DTB with that
> name.
> Allowing this filename to be passed from the first to the second using a
> chosen node "devicetree-path" property in passed DTB (for systems passing
> DTB between stages), seems like the obvious solution to me. An EFI variable
> also works for systems not starting with U-Boot. For systems that do
> have it,
> the "devicetree-path" property could populate that EFI variable so that
> both types of systems end up using the same variable in the end.
Yeah, that's a good summary of the issue I think. Although a new config
option would be needed for systemd-boot to know where the versions dtbs
dir is, since the exact layout can vary between distros.
The next steps then for me would be to confirm with the systemd folks
and look into implementing this, I would add the devicetree-directory
property I described above and support for a DTBPath EFI variable (plus
perhaps a mechanism to set that EFI variable somehow so there's a path
for the Snapdragon laptop users without having to drop to an EFI shell).
I really appreciate your input on this!
Kind regards,
>
> Andrew
>
> [0] https://www.youtube.com/watch?v=a1DaNV9ngSw&t=989s
>
>> 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
