Posting to boot-architecture list for more visibility.
---------- Forwarded message --------- From: Casey Connolly notifications@github.com Date: Mon, Jun 30, 2025 at 12:33 PM Subject: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167) To: devicetree-org/dt-schema dt-schema@noreply.github.com Cc: Subscribed subscribed@noreply.github.com
Background
With more and more laptops, dev boards, and other products shipping with both an EFI capable bootloader and relying on devicetree, there is an increasing problem with trying to ensure that a devicetree is loaded and that it will work with the kernel/OS version being booted.
This is less of an issue on vertically integrated embedded platforms, but with ARM SystemReady gaining prevalence and the abundance of cheap dev boards there is a growing desire to boot generic OS installer/disk images on these devices.
In some cases the platform doesn't see many devicetree changes and works well with a range of kernel versions, the board can just provide it's own devicetree in firmware and it will work just fine. However there are many platforms where this is not the case, unintentional breaking changes can be made to drivers or DT, or new features being enabled can break compatibility with older kernels.
In these cases, the best way to maximise the chance that the generic OS image will boot is if it can load the devicetree blob which was installed alongside the kernel (something most mainstream distros do).
To enable this there has to be a consistent way to determine which dtb (and overlays) were embedded into the firmware provided devicetree.
This new property enables exactly this usecase by making it possible to embed the information into the dtb itself at build time. A proposed implementation of this for U-Boot is available here 1.
The devicetree paths are all appended to some versioned prefix (typically the kernel version) which would be known by the OS loader when you choose a version to boot.
Prior effort
Previous attempts have been made to work around the issue of DTB loading, U-Boot attempts to search some well-known (unversioned) paths on the ESP using it's internal fdtfile variable (which has to be constructed in a platform specific way, see below). This has mixed results and doesn't work on distros like Fedora and Debian which install dtbs to version-specific subdirectories.
On the EFI laptop side (where they don't provide any DTB) the dtbloader EFI driver effectively implements the same logic as U-Boot, guessing generic paths and using an internal unreliable map of SMBIOS hardware IDs to file paths, this has been the go-to for many folks for a while now but it's clear that it doesn't scale and that distros won't be keep to ship it. It gets more complicated when you consider secureboot as well which would require signing the driver.
File path as API
This proposed solution does have a potential stumbling block, as it effectively cements the idea that the dtb path is API.
I believe this is a bridge that was already crossed long ago when extlinux and later GRUB and systemd-boot gained a way to specify a devicetree blob to load, since all distros use the upstream file naming, any renames already potentially cause devices to become unbootable after a kernel upgrade...
That being said, it's clear that the current way files are named is often arbitrary and definitely inconsistent. I would propose a solution like enforcing a way to convert between the root compatible property and the file path, this provides consistency and removes the need to store this arbitrary additional data needed to locate the dtb on the ESP during boot.
An ugly attempt to best-effort this conversion for Qualcomm boards today can be found at 2.
Why not store this data elsewhere?
There are quite a few benefits to putting this in the DTB itself.
It makes it possible to have a generic bootloader binary which gets the DTB in an implementation-specific way, it avoids having to hard-code the data. On devices that have an EFI which doesn't provide a DTB, a driver can be installed once on the ESP which installs a stub DT just containing these properties, so that the OS loader can use them. It isn't EFI specific, extlinux or other boot methods can make use of this. This is metadata which belongs with the DTB, it can be inserted at build time or at runtime, or even augmented to add additional overlays at runtime should the implementation require that.
All in all, a generic mechanism for bootloaders and OS loaders to load a dtb and overlays from the ESP (or other arbitrary storage mechanism) is needed, and there doesn't seem to be another place to put it.
Why not FIT?
The FIT format has it's uses in embedded applications, but the only way it could be applied here would be to use it as the way to index /all/ of the available DTBs, in a generic ARM64 Fedora or Debian image there are thousands of these. In addition, while matching by compatible property may work for the base DTB, it doesn't work for overlays.
And of course, using FIT for this would require changing how DTBs are installed and packaged, this would be hugely disruptive and introduce a myriad of additional problems.
cc @poettering @apalos
________________________________
You can view, comment on, or merge this pull request online at:
https://github.com/devicetree-org/dt-schema/pull/167
Commit Summary
bb9677f schemas: chosen: document devicetree-path property
File Changes (1 file)
M dtschema/schemas/chosen.yaml (22)
Patch Links:
https://github.com/devicetree-org/dt-schema/pull/167.patch https://github.com/devicetree-org/dt-schema/pull/167.diff
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: devicetree-org/dt-schema/pull/167@github.com
Hi,
On Mon, 30 Jun 2025 at 11:48, Rob Herring robh@kernel.org wrote:
Posting to boot-architecture list for more visibility.
---------- Forwarded message --------- From: Casey Connolly notifications@github.com Date: Mon, Jun 30, 2025 at 12:33 PM Subject: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167) To: devicetree-org/dt-schema dt-schema@noreply.github.com Cc: Subscribed subscribed@noreply.github.com
Background
With more and more laptops, dev boards, and other products shipping with both an EFI capable bootloader and relying on devicetree, there is an increasing problem with trying to ensure that a devicetree is loaded and that it will work with the kernel/OS version being booted.
This is less of an issue on vertically integrated embedded platforms, but with ARM SystemReady gaining prevalence and the abundance of cheap dev boards there is a growing desire to boot generic OS installer/disk images on these devices.
In some cases the platform doesn't see many devicetree changes and works well with a range of kernel versions, the board can just provide it's own devicetree in firmware and it will work just fine. However there are many platforms where this is not the case, unintentional breaking changes can be made to drivers or DT, or new features being enabled can break compatibility with older kernels.
In these cases, the best way to maximise the chance that the generic OS image will boot is if it can load the devicetree blob which was installed alongside the kernel (something most mainstream distros do).
To enable this there has to be a consistent way to determine which dtb (and overlays) were embedded into the firmware provided devicetree.
This new property enables exactly this usecase by making it possible to embed the information into the dtb itself at build time. A proposed implementation of this for U-Boot is available here 1.
The devicetree paths are all appended to some versioned prefix (typically the kernel version) which would be known by the OS loader when you choose a version to boot.
Prior effort
Previous attempts have been made to work around the issue of DTB loading, U-Boot attempts to search some well-known (unversioned) paths on the ESP using it's internal fdtfile variable (which has to be constructed in a platform specific way, see below). This has mixed results and doesn't work on distros like Fedora and Debian which install dtbs to version-specific subdirectories.
On the EFI laptop side (where they don't provide any DTB) the dtbloader EFI driver effectively implements the same logic as U-Boot, guessing generic paths and using an internal unreliable map of SMBIOS hardware IDs to file paths, this has been the go-to for many folks for a while now but it's clear that it doesn't scale and that distros won't be keep to ship it. It gets more complicated when you consider secureboot as well which would require signing the driver.
The above seems reasonable to me as a summary of where things are.
File path as API
This proposed solution does have a potential stumbling block, as it effectively cements the idea that the dtb path is API.
I believe this is a bridge that was already crossed long ago when extlinux and later GRUB and systemd-boot gained a way to specify a devicetree blob to load, since all distros use the upstream file naming, any renames already potentially cause devices to become unbootable after a kernel upgrade...
That being said, it's clear that the current way files are named is often arbitrary and definitely inconsistent. I would propose a solution like enforcing a way to convert between the root compatible property and the file path, this provides consistency and removes the need to store this arbitrary additional data needed to locate the dtb on the ESP during boot.
An ugly attempt to best-effort this conversion for Qualcomm boards today can be found at 2.
Why not store this data elsewhere?
There are quite a few benefits to putting this in the DTB itself.
It makes it possible to have a generic bootloader binary which gets the DTB in an implementation-specific way, it avoids having to hard-code the data. On devices that have an EFI which doesn't provide a DTB, a driver can be installed once on the ESP which installs a stub DT just containing these properties, so that the OS loader can use them. It isn't EFI specific, extlinux or other boot methods can make use of this. This is metadata which belongs with the DTB, it can be inserted at build time or at runtime, or even augmented to add additional overlays at runtime should the implementation require that.
All in all, a generic mechanism for bootloaders and OS loaders to load a dtb and overlays from the ESP (or other arbitrary storage mechanism) is needed, and there doesn't seem to be another place to put it.
I don't believe the filename is useful for anything, actually. What is it about the filename which is so attractive?
Why not FIT?
The FIT format has it's uses in embedded applications, but the only way it could be applied here would be to use it as the way to index /all/ of the available DTBs, in a generic ARM64 Fedora or Debian image there are thousands of these.
Why is that? You should be able to create a FIT with just the devicetrees you want.
In addition, while matching by compatible property may work for the base DTB, it doesn't work for overlays.
Can you explain a bit more what is missing here?
And of course, using FIT for this would require changing how DTBs are installed and packaged, this would be hugely disruptive and introduce a myriad of additional problems.
Actually I am coming to the view that we should use FIT for devicetree regardless of whether the kernel (or EFI app?) is packaged there. I'l looking at how best to do that in an EFI app. Looking at UKI, it adopts a similar approach to FIT, doesn't it?
- Simon
cc @poettering @apalos
You can view, comment on, or merge this pull request online at:
https://github.com/devicetree-org/dt-schema/pull/167
Commit Summary
bb9677f schemas: chosen: document devicetree-path property
File Changes (1 file)
M dtschema/schemas/chosen.yaml (22)
Patch Links:
https://github.com/devicetree-org/dt-schema/pull/167.patch https://github.com/devicetree-org/dt-schema/pull/167.diff
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: devicetree-org/dt-schema/pull/167@github.com _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
boot-architecture@lists.linaro.org
-
Rob Herring -
Simon Glass