Fwd: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167)
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
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,
Casey Connolly casey.connolly@linaro.org 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.
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.
In a secureboot environment a bootloader like GRUB should never load an unsigned device-tree.
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.
This solution works without any modification of firmware, shim, GRUB, or the kernel and does not need any new EFI variables.
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.
Kind regards,
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Hi
Two unrelated point of views:
1) In the case of FPGA boards such as the Chameleon96 (96boards) some of the overlays may have to be handled before memory is up, that is with TFA or U-Boot SPL. For instance the FPGA may be used to define a DRM solution which could change the RAM split between normal/secure, have special clock constraints, rely on S-EL0 app and need to expose EL1 driver stuff. It may be good that SystemReady IR describes good practices and solutions for all cases, including the ones where overlays are handled by secure firmware (pre + post memory), non secure firmware (U-Boot), boot loader (grub).
2) for the U-Boot led DT handling Ilias@Linaro proposed an efi protocol where grub/kernel could ask « give me my DT » to the firmware. That approach allowed to handle the cases where the files are not on Linux reachable storage (say Emmc only usable by u-boot). This is now upstream. Seems more flexible than a directory.
On 1 Sep 2025, at 19:57, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
Casey Connolly casey.connolly@linaro.org 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.
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.
In a secureboot environment a bootloader like GRUB should never load an unsigned device-tree.
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.
This solution works without any modification of firmware, shim, GRUB, or the kernel and does not need any new EFI variables.
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
Kind regards,
-- // Casey (she/her)
_______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
_______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 02/09/2025 09:22, ff wrote:
Hi
Two unrelated point of views:
- In the case of FPGA boards such as the Chameleon96 (96boards) some of
the overlays may have to be handled before memory is up, that is with TFA or U-Boot SPL. For instance the FPGA may be used to define a DRM solution which could change the RAM split between normal/secure, have special clock constraints, rely on S-EL0 app and need to expose EL1 driver stuff. It may be good that SystemReady IR describes good practices and solutions for all cases, including the ones where overlays are handled by secure firmware (pre + post memory), non secure firmware (U-Boot), boot loader (grub).
- for the U-Boot led DT handling Ilias@Linaro proposed an efi protocol
where grub/kernel could ask « give me my DT » to the firmware. That approach allowed to handle the cases where the files are not on Linux reachable storage (say Emmc only usable by u-boot). This is now upstream. Seems more flexible than a directory.
Please read my email, this problem applies to a wide range of devices including Snapdragon laptops which ship with windows and ACPI but no firmware provided DT.>
On 1 Sep 2025, at 19:57, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
Casey Connolly casey.connolly@linaro.org 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.
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.
In a secureboot environment a bootloader like GRUB should never load an unsigned device-tree.
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.
This solution works without any modification of firmware, shim, GRUB, or the kernel and does not need any new EFI variables.
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.
Kind regards,
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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.
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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:
https://lists.u-boot.org/archives/list/concept@u-boot.org/thread/GS4ELHIF726...
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 devicetree. We should try to avoid worrying about filenames.
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 03/09/2025 23:24, Simon Glass wrote:
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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/concept@u-boot.org/thread/GS4ELHIF726...
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Hi Casey,
On Thu, 4 Sept 2025 at 05:20, Casey Connolly casey.connolly@linaro.org wrote:
On 03/09/2025 23:24, Simon Glass wrote:
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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/concept@u-boot.org/thread/GS4ELHIF726...
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)?
Yes.
But more importantly this seems to be how we should be figuring out the devicetree compatible stringlist when the firmware doesn't provide one. Microsoft has gone to the trouble of defining an CHID as a way of identifying computers. fwupd uses it as well, so it seems reasonable that we should follow along. A good follow-up would be to ask OEMs to add a compatible stringlist to the firmware and provide it in an EFI table, I suppose.
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.
The reason I think you are talking about filenames is that you wrote "by retrieving the (relative) DTB path (qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb dir".
Are few comments on things I saw in this thread:
1. "what if two DTBs have the same compatible"
They are not allowed to have exactly the same compatible stringlist. Then, for example, 'make fit' in Linux won't boot predictably on certain hardware. Devicetree uses the compatible string to distinguish devices. I don't believe Linux enforces uniqueness, but it probably should, for the vendors' sake.
2. "any attempts to use it or other hardware identifiers to pick a devicetree automatically are simply best-effort"
The main identifiers on an EFI machine are SMBIOS tables (some might argue ACPI strayed into this area), so they are basically defined to be correct. Is there another way for Windows to identify the machine?
3. 'scanning all the dtbs? This can be pretty slow, there are thousands of them'.
Yes, there are around 1300. I actually benchmarked this a while back on a RK3399 machine at around 8ms, reading from a FIT. I suspect a UKI would be similar in this respect. Of course in practice we don't package all the devicetrees, so it should be faster than that.
Back to your problem, though. It seems reasonable to prompt the user for a compatible string though, as a way of potentially booting something. Even writing that into an EFI variable seems OK to me. It's just the filename that's going in the wrong direction.
- SImon
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
-- // Casey (she/her)
On 04/09/2025 18:19, Simon Glass wrote:
Hi Casey,
On Thu, 4 Sept 2025 at 05:20, Casey Connolly casey.connolly@linaro.org wrote:
On 03/09/2025 23:24, Simon Glass wrote:
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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/concept@u-boot.org/thread/GS4ELHIF726...
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)?
Yes.
But more importantly this seems to be how we should be figuring out the devicetree compatible stringlist when the firmware doesn't provide one. Microsoft has gone to the trouble of defining an CHID as a way of identifying computers. fwupd uses it as well, so it seems reasonable that we should follow along. A good follow-up would be to ask OEMs to add a compatible stringlist to the firmware and provide it in an EFI table, I suppose.
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.
The reason I think you are talking about filenames is that you wrote "by retrieving the (relative) DTB path (qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb dir".
Are few comments on things I saw in this thread:
- "what if two DTBs have the same compatible"
They are not allowed to have exactly the same compatible stringlist. Then, for example, 'make fit' in Linux won't boot predictably on certain hardware. Devicetree uses the compatible string to distinguish devices. I don't believe Linux enforces uniqueness, but it probably should, for the vendors' sake.
- "any attempts to use it or other hardware identifiers to pick a
devicetree automatically are simply best-effort"
The main identifiers on an EFI machine are SMBIOS tables (some might argue ACPI strayed into this area), so they are basically defined to be correct. Is there another way for Windows to identify the machine?
- 'scanning all the dtbs? This can be pretty slow, there are
thousands of them'.
Yes, there are around 1300. I actually benchmarked this a while back on a RK3399 machine at around 8ms, reading from a FIT. I suspect a
How would that compare to reading the first few bytes (is that possible?) of each file as dtbs are installed today on e.g. fedora?
UKI would be similar in this respect. Of course in practice we don't package all the devicetrees, so it should be faster than that.
Back to your problem, though. It seems reasonable to prompt the user for a compatible string though, as a way of potentially booting something. Even writing that into an EFI variable seems OK to me. It's just the filename that's going in the wrong direction.
My colleague had an interesting proposal to just add the HWIDs to the DTB itself, between that and the compatible a lot of situations would be handled as long as scanning isn't painfully slow (on whatever EDK2 these laptops ship as well).
Even then, it's less convenient from a user persective and a scripting perspective to deal with "compatible stringlists" rather than just the path to the file in question.
Kind regards,
- SImon
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
-- // Casey (she/her)
Hi Casey,
On Thu, 4 Sept 2025 at 10:38, Casey Connolly casey.connolly@linaro.org wrote:
On 04/09/2025 18:19, Simon Glass wrote:
Hi Casey,
On Thu, 4 Sept 2025 at 05:20, Casey Connolly casey.connolly@linaro.org wrote:
On 03/09/2025 23:24, Simon Glass wrote:
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote:
Casey Connolly <casey.connolly@linaro.org mailto:casey.connolly@linaro.org> 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 thisIt 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/concept@u-boot.org/thread/GS4ELHIF726...
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)?
Yes.
But more importantly this seems to be how we should be figuring out the devicetree compatible stringlist when the firmware doesn't provide one. Microsoft has gone to the trouble of defining an CHID as a way of identifying computers. fwupd uses it as well, so it seems reasonable that we should follow along. A good follow-up would be to ask OEMs to add a compatible stringlist to the firmware and provide it in an EFI table, I suppose.
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.
The reason I think you are talking about filenames is that you wrote "by retrieving the (relative) DTB path (qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb dir".
Are few comments on things I saw in this thread:
- "what if two DTBs have the same compatible"
They are not allowed to have exactly the same compatible stringlist. Then, for example, 'make fit' in Linux won't boot predictably on certain hardware. Devicetree uses the compatible string to distinguish devices. I don't believe Linux enforces uniqueness, but it probably should, for the vendors' sake.
- "any attempts to use it or other hardware identifiers to pick a
devicetree automatically are simply best-effort"
The main identifiers on an EFI machine are SMBIOS tables (some might argue ACPI strayed into this area), so they are basically defined to be correct. Is there another way for Windows to identify the machine?
- 'scanning all the dtbs? This can be pretty slow, there are
thousands of them'.
Yes, there are around 1300. I actually benchmarked this a while back on a RK3399 machine at around 8ms, reading from a FIT. I suspect a
How would that compare to reading the first few bytes (is that possible?) of each file as dtbs are installed today on e.g. fedora?
I've not tried it, but I'm sure it would be more than 8ms. For one thing, there is a filesystem overhead. If distros wish to package the OS as hundreds of small files, there will be losses. It would be better to use a FIT, IMO.
UKI would be similar in this respect. Of course in practice we don't package all the devicetrees, so it should be faster than that.
Back to your problem, though. It seems reasonable to prompt the user for a compatible string though, as a way of potentially booting something. Even writing that into an EFI variable seems OK to me. It's just the filename that's going in the wrong direction.
My colleague had an interesting proposal to just add the HWIDs to the DTB itself, between that and the compatible a lot of situations would be handled as long as scanning isn't painfully slow (on whatever EDK2 these laptops ship as well).
Yes, that is how it is implemented - see [1] below.
Even then, it's less convenient from a user persective and a scripting perspective to deal with "compatible stringlists" rather than just the path to the file in question.
I don't believe that's correct. In fact, the user doesn't know or care about the filename. It is the compatible string which matches the hardware. In the future there may not be any filenames, if we can tidy up packaging of the kernel somewhat.
- Simon
Kind regards,
- SImon
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 -- boot-architecture@lists.linaro.org <mailto:boot-architecture@lists.linaro.org> To unsubscribe send an email to boot-architecture- leave@lists.linaro.org <mailto:boot-architecture-leave@lists.linaro.org>-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
-- // Casey (she/her)
-- // Casey (she/her)
[1] // SPDX-License-Identifier: GPL-2.0+
// Computer Hardware IDs for multiple boards // Generated from /scratch/sglass/cosarm/src/third_party/u-boot/files/board/efi/efi-arm_app/hwids
/ { chid: chid {}; };
&chid { msm8998-lenovo-miix-630-81f1 { compatible = "lenovo,miix-630";
// SMBIOS Computer Information bios-vendor = "LENOVO"; bios-version = "8WCN25WW"; manufacturer = "LENOVO"; family = "Miix 630"; product-name = "81F1"; product-sku = "LENOVO_MT_81F1_BU_idea_FM_Miix 630"; enclosure-kind = <0x32>; baseboard-manufacturer = "LENOVO"; baseboard-product = "LNVNB161216";
// Hardware IDs (CHIDs)
hardware-id-03 { // HardwareID-03 variant = <3>; fields = <0x3f>; chid = [16 a5 54 46 eb a9 5f 97 80 e3 5e 39 d8 20 9b c3]; };
hardware-id-04 { // HardwareID-04 variant = <4>; fields = <0xf>; chid = [c4 c9 a6 be 53 83 5d e7 af 35 c2 de 50 5e de c8]; };
hardware-id-05 { // HardwareID-05 variant = <5>; fields = <0x7>; chid = [14 f5 81 d2 d0 59 5c b2 9f 8b 56 d8 be 79 32 c9]; };
hardware-id-06 { // HardwareID-06 variant = <6>; fields = <0x39>; chid = [a5 10 54 fb 5e ef 59 4a a5 a0 cd 87 63 2d 0a ea]; };
hardware-id-07 { // HardwareID-07 variant = <7>; fields = <0x9>; chid = [30 7a b3 58 ed 84 57 fe bf 05 e9 19 5a 28 19 8d]; };
hardware-id-08 { // HardwareID-08 variant = <8>; fields = <0x35>; chid = [7e 61 35 74 54 45 57 97 95 67 2d 0e d8 6e 6f fa]; };
hardware-id-09 { // HardwareID-09 variant = <9>; fields = <0x5>; chid = [b0 f4 46 3c f8 51 5e c3 b0 31 2c cb 87 3a 60 9a]; };
hardware-id-10 { // HardwareID-10 variant = <10>; fields = <0x33>; chid = [08 b7 5d 1f 66 43 52 a1 9b dd 07 10 52 86 0b 33]; };
hardware-id-11 { // HardwareID-11 variant = <11>; fields = <0x3>; chid = [da cf 4a 59 8e 87 55 c5 8b 93 69 12 de d6 bf 7f]; };
hardware-id-12 { // HardwareID-12 variant = <12>; fields = <0x401>; chid = [d0 a8 de b1 4c b5 50 cd bd da 59 5c fc 13 23 0c]; };
hardware-id-13 { // HardwareID-13 variant = <13>; fields = <0x31>; chid = [71 d8 6d 4d 02 f8 55 66 a7 a1 52 9c ef 18 4b 7e]; };
hardware-id-14 { // HardwareID-14 variant = <14>; fields = <0x1>; chid = [6d e5 d9 51 d7 55 57 6b bd 09 c5 cf 66 b2 72 34]; };
extra-0 { // unknown variant fields = <0x4f>; chid = [34 df 58 d6 b6 05 50 aa 93 13 9b 34 f5 c4 b6 fc]; };
extra-1 { // unknown variant fields = <0x47>; chid = [e0 a9 66 96 f0 a6 54 66 a6 db 20 7f be 8b ae 3c]; };
extra-2 { // unknown variant fields = <0x41>; chid = [99 43 1f 53 09 a1 58 69 be 79 65 e2 fa 3f 34 1d]; }; };
sc7180-acer-aspire1 { compatible = "acer,aspire1";
// SMBIOS Computer Information bios-vendor = "Phoenix"; bios-version = "V1.13"; bios-major-release = <1>; bios-minor-release = <13>; firmware-major-release = <01>; firmware-minor-release = <07>; manufacturer = "Acer"; family = "Aspire 1"; product-name = "Aspire A114-61"; product-sku = ""; enclosure-kind = <0xa>; baseboard-manufacturer = "S7C"; baseboard-product = "Daisy_7C";
// Hardware IDs (CHIDs)
hardware-id-00 { // HardwareID-00 variant = <0>; fields = <0x3cf>; chid = [45 d3 7d be 40 fb 57 bd a2 57 55 f4 22 d4 dc 0a]; };
hardware-id-01 { // HardwareID-01 variant = <1>; fields = <0x3c7>; chid = [37 3b fd e5 ff aa 50 4c 84 f3 f8 f5 35 7d fc 29]; };
hardware-id-02 { // HardwareID-02 variant = <2>; fields = <0x3c5>; chid = [e1 25 21 bf 0e d8 54 06 af 87 ad ad 81 2c 57 c5]; };
hardware-id-03 { // HardwareID-03 variant = <3>; fields = <0x3f>; chid = [fa a1 2e d4 bd 49 54 71 8f 74 75 c2 26 7c 3b 46]; };
hardware-id-04 { // HardwareID-04 variant = <4>; fields = <0xf>; chid = [96 5e 36 81 de 3b 5e 39 bb 62 7d 49 17 d7 e3 6f]; };
hardware-id-05 { // HardwareID-05 variant = <5>; fields = <0x7>; chid = [82 fe 18 69 36 1c 56 b2 b8 53 63 17 47 e6 4a a7]; };
hardware-id-06 { // HardwareID-06 variant = <6>; fields = <0x39>; chid = [7e 15 f4 9e 04 b4 5d 56 a5 67 e7 a1 5b a2 ac a1]; };
hardware-id-07 { // HardwareID-07 variant = <7>; fields = <0x9>; chid = [7c 10 7a 7f 2d 77 51 aa ae f8 8d 77 7e 26 ff bc]; };
hardware-id-08 { // HardwareID-08 variant = <8>; fields = <0x35>; chid = [68 b3 8f ff aa dc 51 2c 93 7b 99 d9 c1 3e b4 84]; };
hardware-id-09 { // HardwareID-09 variant = <9>; fields = <0x5>; chid = [26 01 92 d4 06 d4 51 24 ab 46 ba 21 0f 4c 14 d7]; };
hardware-id-10 { // HardwareID-10 variant = <10>; fields = <0x33>; chid = [17 5f 00 0b 3d 05 5c 01 ae dd 81 7b 1a 14 1f 93]; };
hardware-id-11 { // HardwareID-11 variant = <11>; fields = <0x3>; chid = [24 27 7a 94 70 64 50 0f 98 54 52 64 f2 0c fa 99]; };
hardware-id-12 { // HardwareID-12 variant = <12>; fields = <0x401>; chid = [92 dc c9 4d 48 f7 5e e8 b9 ec a6 39 3f b7 a4 84]; };
hardware-id-13 { // HardwareID-13 variant = <13>; fields = <0x31>; chid = [d2 34 a9 17 df 0b 54 53 a3 d9 f2 7c 06 30 73 95]; };
hardware-id-14 { // HardwareID-14 variant = <14>; fields = <0x1>; chid = [1e 30 17 34 5d 49 5d f4 9e d2 aa 1c 0a 9d dd da]; }; };
On 9/8/25 17:59, Simon Glass wrote:
Hi Casey,
On Thu, 4 Sept 2025 at 10:38, Casey Connolly casey.connolly@linaro.org wrote:
On 04/09/2025 18:19, Simon Glass wrote:
Hi Casey,
On Thu, 4 Sept 2025 at 05:20, Casey Connolly casey.connolly@linaro.org wrote:
On 03/09/2025 23:24, Simon Glass wrote:
Hi,
On Tue, 2 Sept 2025 at 16:48, Casey Connolly casey.connolly@linaro.org wrote:
On 01/09/2025 19:56, Heinrich Schuchardt wrote: > > > Casey Connolly <casey.connolly@linaro.org > mailto:casey.connolly@linaro.org> 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/concept@u-boot.org/thread/GS4ELHIF726...
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)?
Yes.
But more importantly this seems to be how we should be figuring out the devicetree compatible stringlist when the firmware doesn't provide one. Microsoft has gone to the trouble of defining an CHID as a way of identifying computers. fwupd uses it as well, so it seems reasonable that we should follow along. A good follow-up would be to ask OEMs to add a compatible stringlist to the firmware and provide it in an EFI table, I suppose.
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.
The reason I think you are talking about filenames is that you wrote "by retrieving the (relative) DTB path (qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb dir".
Are few comments on things I saw in this thread:
- "what if two DTBs have the same compatible"
They are not allowed to have exactly the same compatible stringlist. Then, for example, 'make fit' in Linux won't boot predictably on certain hardware. Devicetree uses the compatible string to distinguish devices. I don't believe Linux enforces uniqueness, but it probably should, for the vendors' sake.
- "any attempts to use it or other hardware identifiers to pick a
devicetree automatically are simply best-effort"
The main identifiers on an EFI machine are SMBIOS tables (some might argue ACPI strayed into this area), so they are basically defined to be correct. Is there another way for Windows to identify the machine?
- 'scanning all the dtbs? This can be pretty slow, there are
thousands of them'.
Yes, there are around 1300. I actually benchmarked this a while back on a RK3399 machine at around 8ms, reading from a FIT. I suspect a
How would that compare to reading the first few bytes (is that possible?) of each file as dtbs are installed today on e.g. fedora?
I've not tried it, but I'm sure it would be more than 8ms. For one thing, there is a filesystem overhead. If distros wish to package the OS as hundreds of small files, there will be losses. It would be better to use a FIT, IMO.
Except for first boot the scanning of files could be moved to updating grub.cfg or some equivalent file but still be based on the compatible string.
But that would not solve the device-tree signing problem. Reading an unsigned device-tree does not fit into secure-boot. This is where packaging all relevant device-trees into a signed image together with the kernel (be it ukify, stubble, or a FIT image) shines.
Best regards
Heinrich
UKI would be similar in this respect. Of course in practice we don't package all the devicetrees, so it should be faster than that.
Back to your problem, though. It seems reasonable to prompt the user for a compatible string though, as a way of potentially booting something. Even writing that into an EFI variable seems OK to me. It's just the filename that's going in the wrong direction.
My colleague had an interesting proposal to just add the HWIDs to the DTB itself, between that and the compatible a lot of situations would be handled as long as scanning isn't painfully slow (on whatever EDK2 these laptops ship as well).
Yes, that is how it is implemented - see [1] below.
Even then, it's less convenient from a user persective and a scripting perspective to deal with "compatible stringlists" rather than just the path to the file in question.
I don't believe that's correct. In fact, the user doesn't know or care about the filename. It is the compatible string which matches the hardware. In the future there may not be any filenames, if we can tidy up packaging of the kernel somewhat.
- Simon
Kind regards,
- SImon
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 -- boot-architecture@lists.linaro.org > mailto:boot-architecture@lists.linaro.org > To unsubscribe send an email to boot-architecture- > leave@lists.linaro.org mailto:boot-architecture-leave@lists.linaro.org >
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
-- // Casey (she/her)
-- // Casey (she/her)
[1] // SPDX-License-Identifier: GPL-2.0+
// Computer Hardware IDs for multiple boards // Generated from /scratch/sglass/cosarm/src/third_party/u-boot/files/board/efi/efi-arm_app/hwids
/ { chid: chid {}; };
&chid { msm8998-lenovo-miix-630-81f1 { compatible = "lenovo,miix-630";
// SMBIOS Computer Information bios-vendor = "LENOVO"; bios-version = "8WCN25WW"; manufacturer = "LENOVO"; family = "Miix 630"; product-name = "81F1"; product-sku = "LENOVO_MT_81F1_BU_idea_FM_Miix 630"; enclosure-kind = <0x32>; baseboard-manufacturer = "LENOVO"; baseboard-product = "LNVNB161216"; // Hardware IDs (CHIDs) hardware-id-03 { // HardwareID-03 variant = <3>; fields = <0x3f>; chid = [16 a5 54 46 eb a9 5f 97 80 e3 5e 39 d8 20 9b c3]; }; hardware-id-04 { // HardwareID-04 variant = <4>; fields = <0xf>; chid = [c4 c9 a6 be 53 83 5d e7 af 35 c2 de 50 5e de c8]; }; hardware-id-05 { // HardwareID-05 variant = <5>; fields = <0x7>; chid = [14 f5 81 d2 d0 59 5c b2 9f 8b 56 d8 be 79 32 c9]; }; hardware-id-06 { // HardwareID-06 variant = <6>; fields = <0x39>; chid = [a5 10 54 fb 5e ef 59 4a a5 a0 cd 87 63 2d 0a ea]; }; hardware-id-07 { // HardwareID-07 variant = <7>; fields = <0x9>; chid = [30 7a b3 58 ed 84 57 fe bf 05 e9 19 5a 28 19 8d]; }; hardware-id-08 { // HardwareID-08 variant = <8>; fields = <0x35>; chid = [7e 61 35 74 54 45 57 97 95 67 2d 0e d8 6e 6f fa]; }; hardware-id-09 { // HardwareID-09 variant = <9>; fields = <0x5>; chid = [b0 f4 46 3c f8 51 5e c3 b0 31 2c cb 87 3a 60 9a]; }; hardware-id-10 { // HardwareID-10 variant = <10>; fields = <0x33>; chid = [08 b7 5d 1f 66 43 52 a1 9b dd 07 10 52 86 0b 33]; }; hardware-id-11 { // HardwareID-11 variant = <11>; fields = <0x3>; chid = [da cf 4a 59 8e 87 55 c5 8b 93 69 12 de d6 bf 7f]; }; hardware-id-12 { // HardwareID-12 variant = <12>; fields = <0x401>; chid = [d0 a8 de b1 4c b5 50 cd bd da 59 5c fc 13 23 0c]; }; hardware-id-13 { // HardwareID-13 variant = <13>; fields = <0x31>; chid = [71 d8 6d 4d 02 f8 55 66 a7 a1 52 9c ef 18 4b 7e]; }; hardware-id-14 { // HardwareID-14 variant = <14>; fields = <0x1>; chid = [6d e5 d9 51 d7 55 57 6b bd 09 c5 cf 66 b2 72 34]; }; extra-0 { // unknown variant fields = <0x4f>; chid = [34 df 58 d6 b6 05 50 aa 93 13 9b 34 f5 c4 b6 fc]; }; extra-1 { // unknown variant fields = <0x47>; chid = [e0 a9 66 96 f0 a6 54 66 a6 db 20 7f be 8b ae 3c]; }; extra-2 { // unknown variant fields = <0x41>; chid = [99 43 1f 53 09 a1 58 69 be 79 65 e2 fa 3f 34 1d]; }; }; sc7180-acer-aspire1 { compatible = "acer,aspire1"; // SMBIOS Computer Information bios-vendor = "Phoenix"; bios-version = "V1.13"; bios-major-release = <1>; bios-minor-release = <13>; firmware-major-release = <01>; firmware-minor-release = <07>; manufacturer = "Acer"; family = "Aspire 1"; product-name = "Aspire A114-61"; product-sku = ""; enclosure-kind = <0xa>; baseboard-manufacturer = "S7C"; baseboard-product = "Daisy_7C"; // Hardware IDs (CHIDs) hardware-id-00 { // HardwareID-00 variant = <0>; fields = <0x3cf>; chid = [45 d3 7d be 40 fb 57 bd a2 57 55 f4 22 d4 dc 0a]; }; hardware-id-01 { // HardwareID-01 variant = <1>; fields = <0x3c7>; chid = [37 3b fd e5 ff aa 50 4c 84 f3 f8 f5 35 7d fc 29]; }; hardware-id-02 { // HardwareID-02 variant = <2>; fields = <0x3c5>; chid = [e1 25 21 bf 0e d8 54 06 af 87 ad ad 81 2c 57 c5]; }; hardware-id-03 { // HardwareID-03 variant = <3>; fields = <0x3f>; chid = [fa a1 2e d4 bd 49 54 71 8f 74 75 c2 26 7c 3b 46]; }; hardware-id-04 { // HardwareID-04 variant = <4>; fields = <0xf>; chid = [96 5e 36 81 de 3b 5e 39 bb 62 7d 49 17 d7 e3 6f]; }; hardware-id-05 { // HardwareID-05 variant = <5>; fields = <0x7>; chid = [82 fe 18 69 36 1c 56 b2 b8 53 63 17 47 e6 4a a7]; }; hardware-id-06 { // HardwareID-06 variant = <6>; fields = <0x39>; chid = [7e 15 f4 9e 04 b4 5d 56 a5 67 e7 a1 5b a2 ac a1]; }; hardware-id-07 { // HardwareID-07 variant = <7>; fields = <0x9>; chid = [7c 10 7a 7f 2d 77 51 aa ae f8 8d 77 7e 26 ff bc]; }; hardware-id-08 { // HardwareID-08 variant = <8>; fields = <0x35>; chid = [68 b3 8f ff aa dc 51 2c 93 7b 99 d9 c1 3e b4 84]; }; hardware-id-09 { // HardwareID-09 variant = <9>; fields = <0x5>; chid = [26 01 92 d4 06 d4 51 24 ab 46 ba 21 0f 4c 14 d7]; }; hardware-id-10 { // HardwareID-10 variant = <10>; fields = <0x33>; chid = [17 5f 00 0b 3d 05 5c 01 ae dd 81 7b 1a 14 1f 93]; }; hardware-id-11 { // HardwareID-11 variant = <11>; fields = <0x3>; chid = [24 27 7a 94 70 64 50 0f 98 54 52 64 f2 0c fa 99]; }; hardware-id-12 { // HardwareID-12 variant = <12>; fields = <0x401>; chid = [92 dc c9 4d 48 f7 5e e8 b9 ec a6 39 3f b7 a4 84]; }; hardware-id-13 { // HardwareID-13 variant = <13>; fields = <0x31>; chid = [d2 34 a9 17 df 0b 54 53 a3 d9 f2 7c 06 30 73 95]; }; hardware-id-14 { // HardwareID-14 variant = <14>; fields = <0x1>; chid = [1e 30 17 34 5d 49 5d f4 9e d2 aa 1c 0a 9d dd da]; }; };
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.
Kind regards,
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On 9/2/25 3:50 AM, Vincent Stehlé wrote:
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.
I'm not sure what this solves. The Devicetree provided by firmware is almost always just one from the Linux kernel at some specific point in time, (usually the vendor's LTS kernel when the firmware was built). So not sure what "validating" does here, it will be a valid DT for, let's say Linux v5.15, but maybe not necessarily valid for an earlier or later kernel.
- Making sure that newer OSes are backward compatibles with older Devicetrees.
A nice goal to work towards, but this has not been the reality in practice, nor do I think it will be in the near future.
DTBs have bugs too, so it is not just that an old DT might not be "compatible" with a new OS, it might also be buggy. Fixups and quarks in kernel can help, but since updated DTs are shipped with updated kernel, why prefer the firmware provided one when we can use an updated one meant for the specific OS and version we are booting.
There is also not just backwards compat, but forward compat. For instance if I update my firmware, it now provides the latest DT, which may not be compatible with the slightly older kernel I was using before the update.
Andrew
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.
Kind regards,
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Hi Vincent, Andrew,
On 03/09/2025 00:29, Andrew Davis wrote:
On 9/2/25 3:50 AM, Vincent Stehlé wrote:
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.
I'm not sure what this solves. The Devicetree provided by firmware is almost always just one from the Linux kernel at some specific point in time, (usually the vendor's LTS kernel when the firmware was built). So not sure what "validating" does here, it will be a valid DT for, let's say Linux v5.15, but maybe not necessarily valid for an earlier or later kernel.
Try taking a look at the firmware provided FDT for e.g. the rb3gen2, it might be valid for some "vendor kernel" - and to its credit mainline will /kinda/ boot, but it includes a lot of very downstream stuff, you wont' get a working GPU for example because it has DT nodes for their downstream GPU stack.
With that in mind (that vendors want to support their "value add" downstream kernel as well as mainline) we end up with this terrible idea of "why not ship a mainline friendly fdt and a downstream one and let the user configure it" which hey, may kinda work, but when there is some kind of regression or bug and we consider that the firmware providing this fdt doesn't get updates from LVFS or anything nice the user will inevitably want to just use the DT that came with their kernel, and they will have to hack up the systemd-boot or GRUB config to load it.
That is the situation I want to improve, I want to solve the worst case scenario so that there is a friendly and well documented fall-back. That doesn't mean I think it's the correct solution, I want there to be optimisations and stuff obviously, but we should have a safety net so that folks can just *get their damn laptop working*!.>
- Making sure that newer OSes are backward compatibles with older
Devicetrees.
A nice goal to work towards, but this has not been the reality in practice, nor do I think it will be in the near future.
DTBs have bugs too, so it is not just that an old DT might not be "compatible" with a new OS, it might also be buggy. Fixups and quarks in kernel can help, but since updated DTs are shipped with updated kernel, why prefer the firmware provided one when we can use an updated one meant for the specific OS and version we are booting.
There is also not just backwards compat, but forward compat. For instance if I update my firmware, it now provides the latest DT, which may not be compatible with the slightly older kernel I was using before the update.
Andrew
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?
Assuming that there /is/ a firmware provided devicetree (which we absolutely can not assume), any attempts to use it or other hardware identifiers to pick a devicetree automatically are simply best-effort and I don't believe they should be relied on. As mentioned above (and explained in the paragraph below) I'm interested in solving the worst-case scenario FIRST before we start worrying about whatever fancy auto-detection stuff we want to implement, so that when the autodetection fails there is a sensible and well-documented fallback to simply let users specify the dtb manually.
Thanks for taking the time to have a read through, I appreciat ethe feedback.
Kind regards,>>
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.
Kind regards,
-- // Casey (she/her)
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
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].
## 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.
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.
Kind regards,
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.
Kind regards,
boot-architecture@lists.linaro.org
-
Andrew Davis -
Casey Connolly -
ff -
Heinrich Schuchardt -
Rob Herring -
Simon Glass -
Vincent Stehlé