[PATCH 00/21] Qualcomm generic board support

Mon Dec 4 11:06:41 CET 2023

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.garg at linaro.org> a écrit :

+ Linux kernel DT bindings maintainers, EBBR ML

On Thu, 30 Nov 2023 at 20:05, Tom Rini <trini at 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.armstrong at 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.connolly at 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 <trini at 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.connolly at 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-architecture at lists.linaro.org
To unsubscribe send an email to boot-architecture-leave at lists.linaro.org