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

Hi folks, Adding Rob Herring to the thread, as he covers the DTB side in the Linux kernel.

From the distros side, I am terrified at the prospect of requiring that dtbs be embedded into the distros as a pre-requisite for a board to function. It would represent a combinatorial mess (many platforms, many distros, many versions) that would just hurt everyone in the long-term. Have I misunderstood the intent of this proposal?

Cheers, -- Steve Capper

From: Heinrich Schuchardt heinrich.schuchardt@canonical.com Date: Thursday, 2 May 2024 at 10:07 To: Pere Garcia Pere.Garcia@arm.com Cc: Humphreys, Jonathan j-humphreys@ti.com, boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org, Vincent Stehle Vincent.Stehle@arm.com Subject: Re: OS provided DT proposal On 02.05.24 09:18, Pere Garcia wrote:

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

Device-trees are a mixture of hardware description and operating instructions for the kernel (e.g. baudrate of the UART, driver or host operating mode of a USB port).

Device-tree overlays may be needed for optional hardware (e.g. Raspberry hats).

Linux device-trees evolve over time. Full board support cannot be expected with an outdated device-tree provided by firmware. Furthermore both backward and forward incompatibilities occur from time to time.

Using the device-tree matching the booted kernel typically provides the best user experience.

Best regards

Heinrich _______________________________________________ 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.

W dniu 2.05.2024 o 09:18, Pere Garcia pisze:

SystemReady IR owner here at ATG.

SystemReady SR fan here.

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?

VendorX releases DeviceY in 2024 with DTB working with Linux 6.6, OpenBSD 7.5 versions. During next year goes out of business and updates for DeviceY stop.

Two years later some small fix to DT is needed to get it working properly with some OS.

Users are left with options:

- make own firmware updates to put fixed DT in firmware - use DT overlays - use OS provided DTB

3rd option is the easiest to go.

Pere Garcia Pere.Garcia@arm.com writes:

Ok, back and forth compatibility ... we have had this discussion internally a few times already and this is difficult one to fix if there's a fix. An OS DTB could break platform-OS interoperability, if not limited, that's why this thread caught my eye 😊

I would say that to preserve the interoperability between platforms and OSes, the DT must sit wherever the data being represented belongs. If data structure (DT in this case) is relative to platform then it belongs within the platform FW, if data presented is relative to the OS then it belongs within the OS.

That is the problem with DT, it sits with both. It obviously belongs to the platform because it describes it, but the description is really an abstraction of the hardware created by the OS drivers, so sits with the OS.

I would say the OS DTB is a point-to-point solution potentially breaking the interoperability principles, and opening Pandora's box ... Perhaps a better approach would be for the OSVs to provide a DT overlay to fix specific OS compatibilities, thus maintaining interoperability without compromising the underlying principles. A FW DT always must exist to enable interoperability and an optional OS DTB overlay would be allowed to help addressing backwards compatibility but just as an overlay on top of the FW one.

I argue the opposite. Allowing the OS to provide a matching DT would improve interoperability because it would ensure the 'just works' experience, whereas the overlays that the OS would provide may need to be specific to particular firmware DT versions.

But I agree that the design of how we allow an OS to use a matching DT needs to be carefully thought out to make sure it doesn't harm interoperability.

As said, this just caught my eye but definitely a good topic for discussion within the EBBR forum ... BR Pere

-----Original Message----- From: Marcin Juszkiewicz marcin.juszkiewicz@linaro.org Sent: Thursday, May 2, 2024 10:09 AM To: boot-architecture@lists.linaro.org Subject: Re: OS provided DT proposal

W dniu 2.05.2024 o 09:18, Pere Garcia pisze:

...

SystemReady IR owner here at ATG.

SystemReady SR fan here.

...

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?

VendorX releases DeviceY in 2024 with DTB working with Linux 6.6, OpenBSD 7.5 versions. During next year goes out of business and updates for DeviceY stop.

Two years later some small fix to DT is needed to get it working properly with some OS.

Users are left with options:

• make own firmware updates to put fixed DT in firmware
• use DT overlays
• use OS provided DTB

3rd option is the easiest to go. _______________________________________________ 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

Daniel Thompson daniel.thompson@linaro.org writes:

On Wed, May 01, 2024 at 09:18:01PM +0000, Humphreys, Jonathan wrote:

...

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.

<hoisted the footnote> > [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.

I say that the firmware already passes on such an identifier, in the form of the compatible string in the root node.

I don't think any standard is explicit on the level of detail root node compatible strings should provide but it's certainly idiomatic for these strings to be very detailed already.

...

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.

The pleasing thing about using the devicetree compatible string is that not much else needs to change.

1. An OS can continue to assume that DT is a firmware problem and expect the firmware to be updated when the board vendor wants it to support new features or fix bugs.

2. An OS that wishes to maintain a collection of DTs can run an EFI application to examine the compatible strings to select and install an alternative DT.

I like this approach. It is straightforward, and it solves the problem of deciding which method to use (firware provided DT or OS) because the firmware always passes its DTB, and the OS loader has the choice of loading a matching DTB based on the root compatible string.

One could argue that this is just an OS QoI issue. However the value of avoiding fragmentation and promoting interoperability advocates for standardizing an approach as a recommendation in the EBBR.

One thing I'm unclear about is whether there are any generic operating systems that are willing to ship a collection of DTs and to implement the changes to their bootflow to adopt them automatically (rather than through post-install tuning).

They already do.

https://rpmfind.net/linux/RPM/fedora/devel/rawhide/aarch64/k/kernel-core-6.9... https://packages.debian.org/sid/arm64/linux-image-6.7.12-arm64/filelist#:~:t...

I think that is important and is needed to resolve the [long standing EFI_DT_FIXUP_PROTOCOL ticket][1]. IMHO vendor-specific operating systems don't really count here since, if they want to, they can already use the fixup protocol to do exactly the above without any changes to the EBBR spec.

Daniel.

---

boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org

Rob Herring robherring2@gmail.com writes:

On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan j-humphreys@ti.com wrote:

...

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

I really would like specific cases of these where compatibility is broken highlighted. The tooling and reviewing to identify these cases has gotten much better. I've been prototyping a tool which will compare 2 versions of binding schemas and spit out incompatible changes for example. Those aren't the only types of changes as you point out, but if we can eliminate a whole class of issues I think the situation would be much better.

...

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.

Nothing prevents an OS from using its own DTB already. The OS does know what hardware it runs on because we tell it with the DTB.

...

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.
• The OS knows what version of DTBs matches it's kernel, but does not know which specific device tree to use.

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.

If the firmware can't know which version of DTB, how can it know whether to pass a DTB vs. an identifier? The OS might be perfectly fine with firmware's DTB.

...

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.

Agreed, but that contradicts what you said above unless you mean we define 2 ways to operate with some platforms working one standard way and other platforms working the other standard way.

yes, we would allow either way. I think Daniel's suggestion would address this and the above points.

...

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

I agree with Daniel that we should use the root node compatible for this. We discussed this a while back on this list (or u-boot?). To summarize, both using the filename or root node compatible were proposed. Several folks (myself included) don't like making the filename an ABI. However, there are some cases where the filename is more unique than the root node compatible. We should fix those root node compatibles in that case IMO.

Rob _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org

On Mon, May 6, 2024 at 7:37 AM Ahmad Fatoum a.fatoum@pengutronix.de wrote:

Hello Jonathan, Hello Rob,

Thanks for bringing this topic to discussion. I think the status quo is an obvious shortcoming that needs to be addressed.

On 02.05.24 16:00, Rob Herring wrote:

...

On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan j-humphreys@ti.com wrote:

...

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

I really would like specific cases of these where compatibility is broken highlighted.

Screening for backwards-compatibility of new kernels (or their bindings) with old DTs is not enough. When an A/B system fails to boot and does a fallback, you can run into the inverse situation, namely: An old kernel is presented with a new device tree as bootloader updates are often not rolled back.

I'm interested in both cases. Indeed, I think this problem is harder than backwards compatibility. There's not much we can do if say a platform was missing some provider (e.g. a clock controller) and then you add one. The old OS is not going to know what to do with the clock controller and all its 'clocks' property references as it lacks a driver. We mitigated this somewhat in Linux to make some dependencies optional or timeout. For example, if a platform booted without pinctrl before, then any pinctrl added should be optional (unless the firmware also stopped doing pin setup when it moved into the DT).

This seems unavoidable and the solution we have for that is to ship device trees along with kernel updates and load both together.

...

The tooling and reviewing to identify these cases has gotten much better.

barebox has been pulling in kernel device trees for many years and it's a frequent cause of regressions. Here are some recent fixes found with $(git log --grep="^Fixes:.*dts: update"):

Thanks for the pointers. Some analysis below...

• "aiodev: imx_thermal: fix breakage after device tree sync" https://github.com/barebox/barebox/commit/451c25b60e

Removing a required property is something I check. Would not have helped here as it got moved from required to deprecated in 2017. Required and deprecated should be orthogonal. For the DTS, what should have happened here is the 'fsl,tempmon-data" property should have been kept with the nvmem properties added.

• "pinctrl: stm32: Remove check for pins-are-numbered" https://github.com/barebox/barebox/commit/38ff8dad11

Another case of removing a required property.

• "ARM: dts: i.MX8MP: snps,dis-u2-freeclk-exists-quirk" https://github.com/barebox/barebox/commit/db01bf84cf

Should have kept the existing property and made the new property incremental meaning on top of it. Yet another reason for me to dislike the dozens of quirk properties we have on this binding. We push back on them a lot more now and instead push that quirks are implied from SoC specific compatible strings unless they are board specific.

I don't think the binding comparison I'm working on could catch this. For this we probably need to compare DTBs looking for removed properties. I think dtx_diff already can do that.

• "clk: imx8mp: add USB suspend clock" https://github.com/barebox/barebox/commit/d86bbaed71

Changing the number of entries is something I check.

• "ARM: i.MX8MN: assume USBOTG power domains to be powered" https://github.com/barebox/barebox/commit/7b62fbc632

That's the problem of new providers added. I don't know about barebox design, but I think you'd be able to handle that better than the Linux kernel can. The biggest problem in Linux is we never know when all drivers have been loaded or dependencies have probed. A module could be loaded a week after boot to provide a dependency. I'd think bootloaders generally don't have that problem.

All of these bugs would have broken a newer Linux kernel being booted with an old device tree.

I'm not sure we can conclude that. Depends if Linux handles the old binding.

In practice, they didn't because normally barebox-built device trees are used for barebox and Linux-built device trees are shipped along with Linux, even if they might have been at identical some point.

...

I've been prototyping a tool which will compare 2 versions of binding schemas and spit out incompatible changes for example. Those aren't the only types of changes as you point out, but if we can eliminate a whole class of issues I think the situation would be much better.

I look forward to this. Would your tooling have detected any of the above regressions?

Fortunately, most of these issues are caught before a barebox release (features, unlike bug fixes, sit in master a month before making it into a monthly release), but some slip through and it introduces a lot of churn.

I'm sure you'd rather have a tool to find cases rather than having to find them testing every SoC/board. :)

...

...

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.

Yes. My first experience with EBBR was AFAIR a system that didn't boot, because an up-to-date Debian kernel failed to handle the old device tree provided by the firmware. At least updating the EFI firmware with a USB stick worked well.

Was that SystemReady IR compliant too? Unfortunately, IR 1.x doesn't do much for DT checking, but 2.x does and should help a bit. It's testing with schemas from relatively recent kernel trees and OS kernels of various versions have to boot. So there's at least some implicit mismatching.

...

...

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. If the firmware can't know which version of DTB, how can it know whether to pass a DTB vs. an identifier? The OS might be perfectly fine with firmware's DTB.

I think it's a fair assumption that if the kernel ships with a matching DTB, it would be fine booting with it instead of the firmware provided DTB.

Yes.

If we had a way to express this "shipped-with" relationship, we could thus have the EFI firmware just select the matching device tree and pass it along the exact way it's done now.

Some ways to describe this "shipped-with" relationship:

• a section in the image as UKIs do, see Jan's mail
• a fixed naming scheme in the EFI partition, e.g. \EFI\Debian\BOOTAA64.EFI -> \EFI\Debian\DTS-BOOTAA64.EFI/
• an EFI variable or protocol?

This is the EFI loader doing the selection directly, rather than grub or some next stage? That's quite a bit different of a problem to solve I think.

Rob

(resending now that I can post to boot-architecture)

On Thu, May 02, 2024 at 09:00:47AM -0500, Rob Herring wrote:

On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan <j-humphreys(a)ti.com> wrote:

...

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

I agree with Daniel that we should use the root node compatible for this. We discussed this a while back on this list (or u-boot?). To summarize, both using the filename or root node compatible were proposed. Several folks (myself included) don't like making the filename an ABI. However, there are some cases where the filename is more unique than the root node compatible. We should fix those root node compatibles in that case IMO.

I think firmware-provided compatible string can cause headaches for both firmware and OS developers. I gave a talk about this at EOSS [1,2] and we've been posting some proposals [3,4] to introduce a board-id, which allows DTBs to have varying degrees of precision about describing what hardware they are applicable to.

Compatible strings should be a mapping of some identifier registers/storage into a string. Today, bootloader has to figure out that mapping and I understood Jon's proposal as wanting to get firmware to provide the compatible string. However, the compatible string for a DTB could need to describe only a subset of those identifiers (compatible string) to get a DTB that works. This would be especially true for DT overlays, although there are other real and hypothetical situations where a DTB shouldn't/can't describe the complete set of identifiers. Firmware either needs to provide every possible combination of compatible string or knowledge needs to be baked into the OS about interpreting the compatible string. In simple terms, the proposal is to split out the identifers that are baked into the compatible string into separate "board-id" properties.

Thanks, Elliot

[1]: https://static.sched.com/hosted_files/eoss24/11/Shipping%20Multiple%20Device... [2]: https://www.youtube.com/watch?v=k-oxkdpChGk [3]: https://lore.kernel.org/all/1705749649-4708-1-git-send-email-quic_amrianan@q... [4]: https://lore.kernel.org/all/1710418312-6559-1-git-send-email-quic_amrianan@q...

On Fri, 2024-05-03 at 13:11 +0000, ecurtin@redhat.com wrote:

One thing I would like to point out is secure boot in the form of Android Boot Images and UKIs. These secure boot technologies combine kernel+cmdline+initramfs (and optionally a dtb, if the dtb is on the OS) into a secured binary blob to be delivered to the client device. If the dtb exists on the OS side, we must now provide a signed Android Boot Images and/or UKIs per device, this concept doesn't exists in package managers I know, at least in Fedora, CentOS Stream. If the kernel+cmdline+initramfs doesn't have a dtb, we can deliver a generic version that is secured for all devices.

Note that for UKIs, this issue was discussed here: https://github.com/uapi-group/specifications/pull/71 The outcome was to allow multiple DTB sections in a single UKI, without specifying a specific selection algorithm.

The implementation in the systemd EFI loader is ongoing here: https://github.com/systemd/systemd/pull/28959 https://github.com/systemd/systemd/pull/29726 https://github.com/systemd/systemd/pull/31466 https://github.com/systemd/systemd/pull/31467

Adding Máté Kukri, to hopefully have EBBR match the implementation. :)

Jan

On Mon, May 06, 2024 at 01:13:00PM +0200, Francesco Dolcini wrote:

Hello all,

On Wed, May 01, 2024 at 09:18:01PM +0000, Humphreys, Jonathan wrote:

...

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. With this, a device tree could then be burned into the hardware's ROM to be queried by software for hardware discovery.

I would like to add another use case that I do not see mentioned here.

In case of SoM (System On Module) the system can be designed in such a way that the firmware does not really need to know the complete hardware description, but only the hardware subset relevant for booting and the initial hardware configuration is required.

However the operating system would need the complete hardware description, that is made of a SoM plus a carrier/base board, to properly work.

From a life cycle point of view the firmware of the SoM is going to be available and written to the board before the actual whole hardware is even existing and I would not expect to force the SoM user to update/customize the firmware.

FWIW, my expectation and experiences are the opposite. Using the firmware stack for the SoM unmodified and expecting the OS to get to and then use the correct device tree isn't likely. I'm sure there will be cases where it can (and does today) work, but that's not going to be the case every time.

On Tue, May 07, 2024 at 08:17:02PM +0200, Francesco Dolcini wrote:

On Mon, May 06, 2024 at 05:05:25PM -0600, Tom Rini wrote:

...

On Mon, May 06, 2024 at 01:13:00PM +0200, Francesco Dolcini wrote:

...

On Wed, May 01, 2024 at 09:18:01PM +0000, Humphreys, Jonathan wrote:

...

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. With this, a device tree could then be burned into the hardware's ROM to be queried by software for hardware discovery.

I would like to add another use case that I do not see mentioned here.

In case of SoM (System On Module) the system can be designed in such a way that the firmware does not really need to know the complete hardware description, but only the hardware subset relevant for booting and the initial hardware configuration is required.

However the operating system would need the complete hardware description, that is made of a SoM plus a carrier/base board, to properly work.

From a life cycle point of view the firmware of the SoM is going to be available and written to the board before the actual whole hardware is even existing and I would not expect to force the SoM user to update/customize the firmware.

FWIW, my expectation and experiences are the opposite. Using the firmware stack for the SoM unmodified and expecting the OS to get to and then use the correct device tree isn't likely. I'm sure there will be cases where it can (and does today) work, but that's not going to be the case every time.

I am not sure I was able to understand what you mean, or maybe I was not clear on my explanation, let me try to _exemplify_ this.

SOM hardware, let's assume this SOM is made of SOC/PMIC/RAM/FLASH, all the available pins/functionality are routed to some connector.

The boot firmware can be implemented with only the on-SOM functionality. It does not need anything else.

This SOM is then used in a complete system that is for example adding an ADC in some non-discoverable bus (I2C? SPI? ...), implemented in a base/carrier board.

Now the OS *needs* to be told about this ADC device, and in this context this means DT.

My experience is that the firmware is not going to be modified to handle this need, however in some way we need to provide the DT blob to the OS.

The fact that we have DT overlays available as an implementation building block is not solving the issue there, since they need to come from somewhere, and in my example here, it would not be the firmware.

IMO this is a very important use case for SOM vendors and I do not know how this would be addressed within the EBBR framework.

In EBBR terms there *is* only firmware and OS. One of these is required know something about the baseboard the SoM has been mounted in. Given we want to support generic OSs that are not tied to a specific board then the knowledge of what baseboard is connected *must* be the firmware[1].

However, EBBR does not require the firmware to be monolithic, only that the firmware passes a DT to the OS.

That means that a firmware implementation for a SoM can be designed to allow alternative DTs to be provisioned when different baseboards are connected. For example, it could be configured to load the DT from a small firmware-specific filesystem that can be provisioned by the baseboard designer.

However I'd be inclined to view this as an implementation decision rather than something that needs to be standardized for EBBR. When working with a SoM, I expect the SoM vendor to supply firmware sources so I can tweak the firmware to directly support the new baseboard.

Daniel.

[1]: Even if the generic OS contains mechanisms to augment or load an alternative DT it still requires the firmware to tell it what baseboard is connected somehow (elsewhere in this thread we talk about using the DT root node compatible string for that).