On 02/09/2025 09:22, ff wrote: > 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.
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 >> <[email protected]> wrote: >> >> Casey Connolly <[email protected]> schrieb am Mo., 1. Sept. 2025, >> 18:25: >> >>> Hi all, >>> >>> Sorry for the inactivity on this one, I'm hoping we can find some >>> agreeable solution. >>> >>> We had some discussion on the GitHub PR [1] where Krzysztof suggested >>> that this property is duplicating the compatible property, while I wish >>> this were the case it is not true that the DT file names follow any kind >>> of scheme that can be reliably derived from the root compatible property. >>> >>> ## Problem description >>> >>> I guess before trying to decide on solutions we should be able to agree >>> on the problem, for which we need to agree on some facts: >>> >>> Fact 1: The kernel and devicetree are not always forwards/backwards >>> compatible with each other >>> Fact 2: Not all ARM platforms ship with a usable firmware-provided >>> devicetree >>> Fact 3: Users expect to be able to install their favourite Linux distro >>> with minimal effort >>> >>> Given (2) and (3) we need to provide a mechanism to load the correct >>> devicetree and overlays with minimal/trivial user intervention. >>> >>> Given (1) we should always try to load the DT and overlays that were >>> shipped with the kernel even if the platform provides its own (while >>> there may be a case where this is undesirable for some reason I would >>> argue that this would be an exception and not the rule and is not >>> directly relevant here). >>> >>> ## Potential solutions >>> >>> Assuming that we can agree on the above, there is clearly the need for a >>> distro-agnostic mechanism to handle loading the right DT and overlays >>> for the device and kernel version that will be booted. >>> >>> Since there is no standard path for the DTB files on the ESP, and the >>> EFI firmware doesn't know which kernel version will be booted this task >>> can't be handled by the firmware itself (and even then, it would be >>> difficult to drive adoption particularly for boards already in >>> production). >>> >>> This leaves us with the following high level options: >>> >>> Option 1: Create some kind of EFI driver/shim to load the DTB and rely >>> on the user to keep it up to date. >>> >>> Option 2: Engage with systemd-boot/GRUB developers and improve the DTB >>> loading experience, e.g. by retrieving the (relative) DTB path >>> (qcom/qcs6490-rb3gen2.dtb) and appending it to the distro-specific dtb >>> dir (typically tied to the kernel version being selected) >>> >>> Option 1 has been attempted already with dtbloader[2] which has seen >>> some very minor adoption, it also causes problems with secureboot and >>> other potential compatibility issues. >>> >>> ## My proposal >>> >>> Thus I propose Option 2, specifically introducing a devicetree-directory >>> config option to the UAPI group BLS (Boot Loader Specification) that >>> would specify the dtbs directory which the dtb path would be appended >>> to, hopefully with a similar option added to GRUB. >>> >>> This still leaves the issue of identifying the path to the DTB file (and >>> potentially overlays). If there is a firmware provided DTB the root >>> compatible property SOMETIMES is enough to derive the path, but often is >>> not. >>> >>> So what it all boils down to is that we still need a way for the user to >>> manually enter the DTB path, but at least it should only be necessary to >>> do it once. Ideally we can get this >> >> >> It is unclear here if you mean the directory path to all device-trees >> for a >> given kernel or a specific dtb file. >> >> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ >> boot-architecture mailing list -- [email protected] >> To unsubscribe send an email to [email protected] -- // Casey (she/her) _______________________________________________ boot-architecture mailing list -- [email protected] To unsubscribe send an email to [email protected]
