Hi Summit, Here are additional elements that you may want to consider.
This topic should be thought of with « who provides what » question in mind. For quite a long time, one single entity was providing secure firmware, firmware, boot loader (I think of Grub when I use this overloaded term), and OS. This explains why the Linux kernel community has been maintaining DT (not justifying it is now still a good model). For Software Defined Vehicle and many other scenarios this supply chain is not working. In the context of this separation, OS/Hypervisor supplying any DTB is a non-sense. (Translated in real life: as a French driver, my DTB description of a car is that the steering wheel is on the left hand side. If I get on a UK car, I will complain that my hardware description does not match reality. Conclusion: better use DTB given from the platform!). If I am not mistaken Fedora IOT 39 does not come with any DTBs: that was a theme hinted by Peter Robinson a while ago (Peter you may want to comment on this). My understanding is that SystemReady was proposed and developed to address such a different supply chain where: - the OS may be supplied by a party not controlling the underlying layers - have standard contract between OS and previous entities - The entity controlling the hardware is not an OS but a type-1 hypervisor In all this context, the DT should be consumed by OSes (Linux, Zephyr, Eclipse ThreadX (donated by Microsoft), commercial ones…) and hypervisors. The "DT » passed to a Linux (be it equivalent to Dom0) may not be the definitive vision of the whole platform. You may want to talk with the System Device Tree folks. So there is no such a thing as « THE » device tree of the platform. There can be a DT for BL33 firmware, a DT for OS/Hypervisor, a DT for TrustZone (highly decorated with clocks and power nodes that are often irrelevant to BL33 and OS/Hypervisor). The BL33 and OS/Hypervisor DTs location is not defined by EBBR but my view is that the OS/Hypervisor DT can be located in the HW_CONFIG section of a FIP (this section is made for holding the OS DT). The FIP can come from the SoC vendor, later updated by the Board vendor: fiptool --hw-config <OS-DTB> With a separate signing key. So, you should take into account which markets are targeted by the SoC for which you posted your message. If it is traditional embedded, one-entity provides all. You can surely choose any scheme you want. If it is automotive and other markets where there will be separation in the firmware/OS/Hypervisor supply chain, then you should clearly attach the DT to Secure Firmware. Cheers FF PS1: I see an analogy with Google project Trebble which set clear responsibilities in who can provide/modify what. Before it, it was the jungle and pushing a security fix required months of delays. Now a Google security fix can make its way to smartphones in matter of days. Constraining a little bit the Linux driver developers to what should they focus on (nice drivers and not hardware description) will just make things better. Failure to do so will just push for ACPI and its horrible complex, fragile virtual machine to push out DT from those markets... PS2: By « nice" drivers I mean, for instance, drivers that do not assume they are alone in the world and can do whatever they want with clocks that feed the device: they should use proper clock control such as SCMI (trouble for device assignment to a VM for instance). Le 4 déc. 2023 à 06:32, Sumit Garg <sumit.g...@linaro.org> a écrit : + Linux kernel DT bindings maintainers, EBBR ML On Thu, 30 Nov 2023 at 20:05, Tom Rini <tr...@konsulko.com> wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: On Wed, 29 Nov 2023 at 22:06, Neil Armstrong <neil.armstr...@linaro.org> wrote: On 29/11/2023 16:34, Caleb Connolly wrote: On 23/11/2023 07:04, Sumit Garg wrote: On Wed, 22 Nov 2023 at 21:34, Caleb Connolly <caleb.conno...@linaro.org> wrote: On 22/11/2023 14:27, Tom Rini wrote: On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: On Wed, 22 Nov 2023 at 19:31, Tom Rini <tr...@konsulko.com> wrote: On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: Hi Caleb, On Tue, 21 Nov 2023 at 22:39, Caleb Connolly <caleb.conno...@linaro.org> wrote: [snip] == DT loading == Previously, boards used the FDT blob embedded into U-Boot (via OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary bootloader, so we can instead rely on the first-stage bootloader to populate some useful FDT properties for us (notably the /memory node and KASLR seed) and fetch the DTB that it provides. Combined with the memory map changes above, this let's us entirely avoid configuring the memory map explicitly. Since with this change, we don't need to embed FDT blob in the u-boot binary, so I was thinking if we really need to import DTs from Linux for different platforms and then play a catchup game? For now, yes. But why? Is there any value added by larger u-boot specific DT (most of the nodes being unused by u-boot) than what currently u-boot supports? The more important part is to get alignment with Linux DT bindings. If you need to have memory/reserved-memory nodes in u-boot DT for generalization purposes then you should import those particular nodes only. I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here. The value is in preventing any of the existing bindings from regressing, That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews. I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets. Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained). But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files. @DT bindings maintainers, Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in. [1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema -Sumit -- Tom _______________________________________________ boot-architecture mailing list -- boot-architect...@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
