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. >>> >>> [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]
