Jon and Pere,

Since I created my own hypervisor based SoC simulator, my vision of DT has changed...

I think Jon clearly lays out a problem that needs to be solved.

Nothing prevents a vendor to organise its boot flow as described, but I believe it is philosophically opposite to EBBR premise that the firmware shall not care about which OS is booted.

Is that right Pere?

So I’ll comment below...

Le 2 mai 2024 à 09:18, Pere Garcia Pere.Garcia@arm.com a écrit :

Hi Jon, SystemReady IR owner here at ATG. May I ask, what would be the purpose of DTB provided by the OS? The primary function (not only one) of DTB from a SystemReady perspective is for the Platform (fw) advertise to the OS what's in there, there are other secondary functions and some vendors use DTB to store FW-only information or proprietary data structures that do not break the interoperability to OSes. Is such OS DTB containing platform information, or is this DTB containing data useful for the OS or meaningful to be originated from the OS ? can you please elaborate a bit?

Thanks in advance, Pere

-----Original Message----- From: Humphreys, Jonathan j-humphreys@ti.com Sent: Wednesday, May 1, 2024 10:18 PM To: boot-architecture@lists.linaro.org; Vincent Stehle Vincent.Stehle@arm.com Subject: OS provided DT proposal

Hi all. Several EBBR meetings ago, I introduced the need for allowing OS provided device trees [1]. Please find below the proposal I am delinquent on sending.

Hopefully, we can discuss this in the next meeting.

Thanks

Jon

[1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.02.12

Problem statement:

Device trees are in theory a pure description of the hardware, and since the hardware doesn't change, the device tree describing the hardware likewise never changes.

It sounds like it does not precisely describe hardware but rather describe what a driver would need to know about the device. For instance: - the interrupt information found in many device descriptors is actually the result of the interrupt infrastructure programming done by the OS. (The board maker may populate the suggested programming as is found in SoC/board data sheets but that should be all) - there is no information about power and clock hierarchies which are important to decide if you can change the power/clock without jeopardising another device

If we dig into interrupts, some hardware know how to trigger unique interrupts per SATA disk connected to a controller, but current Linux only know how to handle a single interrupt per controller. So why limiting interrupt information in DT to what current Linux could do? The information in DT shall allow Linux and its future versions to use the hardware to the best of its capabilities.

With this, a device tree could then be burned into the hardware's ROM to be queried by software for hardware discovery. In practice, though, device trees evolve over time. They evolve for many reasons, including

• support for previously unsupported hardware
• device driver improvements that require additional hardware information
• bug fixes

Linux's device tree source is maintained with the kernel source, and kernel builds include building the device trees too. This ensures that the device tree matching the kernel's usage is always kept in sync. Often, embedded distros will include the matching device tree blobs.

The EBBR mandates that the device tree blob is provided by the firmware.

Thus it is likely that the device tree provided by the firmware and given to the operating system is not the matching device tree blob for that kernel. This can cause hardware to be missing, buggy, or non-functional.

Proposal:

A key goal of the EBBR is to define the contract between the firmware and the OS so that the OS doesn't need to be built specifically for the hardware, and the firmware can boot any compliant OS. Thus, any solution that requires the OS to know specifics about the hardware beyond the EBBR contract would violate the EBBR goals. This precludes any solution where the OS, having the matching DTBs, would pick the DTB, because this requires the OS to know what hardware it is being run on. Likewise, any solution where the firmware is aware of the OS matching DTBs would require the firmware to be aware of the particular OS it is booting.

What can be known:

• The firmware knows what board it is running on, and thus knows what device

tree to use. But it doesn't know what version of the device tree to use, because it doesn't know what OS is being booted.

I think that is a founding value of EBBR: the firmware shall not care about which OS is booting (Linux, QNX, unikernel, toy OS…). There is certainly a side effect here: with EBBR, the OS booting parameters are obtained through UEFI boot options and DT boot parameters are ignored.

The initramfs can be provided with a smart use of UEFI boot options and in essence the kernel can ask the firmware "give me my initramfs ». Could the mechanism be changed to cover: « give me my DTB? »

• The OS knows what version of DTBs matches it's kernel, but does not know which

specific device tree to use.

That is because drivers considers the DTB as a driver configuration file. Can the information be supplied as a driver parameter in a /etc/modules.d file?

This proposal then has the firmware choose the device tree by name, or some other identifier that can be used to match the device tree for the board [1]. It has the OS-provided OS loader select the location of the matching versions of DTBs for it.

The firmware would pass the device tree filename/id to the OS loader, instead of the DTB itself. The OS loader would determine the location of the matching DTBs based on the chosen OS to boot, load the matching DTB from that location, and pass to the kernel.

Considerations:

• often a DTB requires fixups. The EFI_DT_FIXUP_PROTOCOL could be utilized.
• device tree overlays could be indicated with a scheme using the device tree ID

passed to the OS loader

• authenticating the DTB would be the responsibility of the OS distribution and

handled in the same way as the kernel itself is authenticated. The OS is the entity responsible for signing the DTB, as it should be.

This proposal should be in addition to supporting the standard way of passing in a firmware-provided DT, in cases where the OS doesn't provide or have a need to provide a matching DT.

[1] Rather than using the device tree source filename, to have more flexibility, one can conceive an ID or compatible string that the OS could then scan the DTBs to find a match.

---

boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org