On 03/09/2025 23:24, Simon Glass wrote:
> Hi,
>
> On Tue, 2 Sept 2025 at 16:48, Casey Connolly <[email protected]>
> wrote:
>>
>>
>>
>> On 01/09/2025 19:56, Heinrich Schuchardt wrote:
>>>
>>>
>>> Casey Connolly <[email protected]
>>> <mailto:[email protected]>> schrieb am Mo., 1. Sept. 2025, 18:25:
>>>
>>> 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
>>>
>>>
>>> It is unclear here if you mean the directory path to all device-trees
>>> for a given kernel or a specific dtb file.
>>
>> I mean the specific DTB for the device, at a high level ignoring
>> implementation details this is the fundamental problem.>
>>> The directory is known when the kernel is installed. And the bootloader
>>> (e.g. GRUB) could identify the individual dtb file in that directory via
>>> the compatible property of the DT provided by the firmware.
>>
>> I assume you mean by scanning all the dtbs? This can be pretty slow,
>> there are thousands of them... I guess it could be optimised somewhat
>> but then what if two DTBs have the same compatible? At the end of the
>> day the user should be able to dictate which dtb is used with minimal
>> intervention -- that is what I propose in this mail. Methods to /avoid/
>> the user having to do this are great, but it's just bikeshedding if we
>> can't agree with the fundamental issue and a universal solution (even if
>> that solution is not optimal in many situations).>
>>> In a secureboot environment a bootloader like GRUB should never load an
>>> unsigned device-tree.
>>
>> Yes, but I would like to avoid bikeshedding on that too, we can get
>> around to solving that independently.>
>>> The best solution I have seen to date is packing all device-trees and
>>> the kernel into one signed EFI binary and let the EFI stub choose the
>>> right device-tree based on the compatibe string or on SMBIOS information
>>> where the firmware does not provide a device-tree.
>>>
>>> See for instance https://github.com/ubuntu/stubble <https://github.com/
>>> ubuntu/stubble>.
>>
>> See also: systemd ukify with .dtbauto sections (I have no clue why
>> Ubuntu reinvented the wheel on this one...).>
>>> This solution works without any modification of firmware, shim, GRUB, or
>>> the kernel and does not need any new EFI variables.
>>
>> But consider what happens when next gen laptops come out and start to
>> get support, even if the dtb is available in the kernel version you want
>> to boot you have to either jump through all these hoops to build a new
>> UKI with your dtb in (and figure out the correct hwid's to use) or
>> you're stuck waiting for your distro to "gain support".
>>
>> This is totally unnecessary if we just provided a way for users (who
>> disable secureboot!) to specify the DTB for their laptop.
>>
>> As an aside, I would also argue that the one-big-image solution with a
>> hwid table completely fails to scale up, the image will become huge and
>> the work to add new devices will never end.
>
> See also this:
Hi Simon,
>
> https://lists.u-boot.org/archives/list/[email protected]/thread/GS4ELHIF726PHMI63MJYNK5MNSURR2EV/
>
> Basically it provides a way for U-Boot to get a compatible string from
> SMBIOS tables. That is enough to boot the kernel with the right
Isn't this just the same idea as systemd-stub (and ubuntu stubble) but
where the logic lives in u-boot (in this case as an EFI app itself)?
> devicetree. We should try to avoid worrying about filenames.
The fundamental issue I'm trying to point out here has nothing to do
with filenames. I want a way for users of some newly supported laptop
(to describe the most common example) to be able to boot a distro (that
just packaged the dtb for their new laptop) with minimal intervention,
by either creating/modifying some text file to some specify the dtb that
should be used, or better: being prompted for it without having to
modify their bootable usb drive at all.
Kind regards,>
> Presumably it could be expanded to provide a stringlist, if needed?
>
> - Simon
>
>>
>> Kind regards,
>>
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>> 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 <https://
>>> github.com/devicetree-org/dt-schema/pull/167>
>>>
>>> Kind regards,
>>>
>>> --
>>> // Casey (she/her)
>>>
>>> _______________________________________________
>>> boot-architecture mailing list -- [email protected]
>>> <mailto:[email protected]>
>>> To unsubscribe send an email to boot-architecture-
>>> [email protected] <mailto:[email protected]>
>>>
>>
>> --
>> // Casey (she/her)
>>
>> _______________________________________________
>> boot-architecture mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
--
// Casey (she/her)
_______________________________________________
boot-architecture mailing list -- [email protected]
To unsubscribe send an email to [email protected]
