On 9/8/25 17:59, Simon Glass wrote:
Hi Casey,On Thu, 4 Sept 2025 at 10:38, Casey Connolly <casey.conno...@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.conno...@linaro.org> wrote:On 03/09/2025 23:24, Simon Glass wrote:Hi, On Tue, 2 Sept 2025 at 16:48, Casey Connolly <casey.conno...@linaro.org> wrote:On 01/09/2025 19:56, Heinrich Schuchardt wrote:Casey Connolly <casey.conno...@linaro.org <mailto:casey.conno...@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/conc...@u-boot.org/thread/GS4ELHIF726PHMI63MJYNK5MNSURR2EV/ Basically it provides a way for U-Boot to get a compatible string from SMBIOS tables. That is enough to boot the kernel with the rightIsn'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 aHow 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. - SimonKind regards,- SImonKind regards,>Presumably it could be expanded to provide a stringlist, if needed? - SimonKind 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- le...@lists.linaro.org <mailto:boot-architecture-le...@lists.linaro.org>-- // Casey (she/her) _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@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]; }; };
_______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
