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
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. - 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. 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.
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. 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. - 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. 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.
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
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
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.
Steve Capper Steve.Capper@arm.com writes:
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?
In this proposal, I'm not requiring it. Now a more extreme version of the proposal would require that the OS provide the DT. The argument for this is that if EBBR doesn't require it, an OS may not provide it, and thus breakages may be experienced by the user. This is bad for 'just works', so force it.
But my proposal is taking the middle ground of requiring the firmware to provide a DT, but also specifying a standard mechanism whereby an OS can provide a more up to date / matching DT.
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. _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
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.
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.
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.
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.
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
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.
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).
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.
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.
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.
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
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.
[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
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
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.
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"):
* "aiodev: imx_thermal: fix breakage after device tree sync" https://github.com/barebox/barebox/commit/451c25b60e
* "pinctrl: stm32: Remove check for pins-are-numbered" https://github.com/barebox/barebox/commit/38ff8dad11
* "ARM: dts: i.MX8MP: snps,dis-u2-freeclk-exists-quirk" https://github.com/barebox/barebox/commit/db01bf84cf
* "clk: imx8mp: add USB suspend clock" https://github.com/barebox/barebox/commit/d86bbaed71
* "ARM: i.MX8MN: assume USBOTG power domains to be powered" https://github.com/barebox/barebox/commit/7b62fbc632
All of these bugs would have broken a newer Linux kernel being booted with an old device tree. 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.
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.
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.
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 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.
I agree that an OS-provided DT should be an alternative, not a replacement for the firmware-provided DT.
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.
Agreed.
Cheers, Ahmad
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
Hi Rob et al,
First of all, for clarity I have been a supporter of the firmware provided devicetree as you can see from my recent talk [1] at EOSS24. But I also do recognise the current DT ABI stability challenges faced by the embedded community leading to this OS provided DT proposal. This proposal may allow embedded systems to just work but won't solve the DT fragmentation problem in the longer run. Maybe as a side effect it can give people a reason to not care about DT ABI stability issues? Or maybe I am a bit too optimistic about the possibility of improving DT ABI stability?
DT ABI stability is also important to the other DT consumers as well like U-Boot, barebox, other OSes etc. So we should keep them under consideration too.
On Wed, 8 May 2024 at 04:13, Rob Herring robherring2@gmail.com wrote: <snip>
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.
Current DT checking as you have highlighted above seems like a cumbersome effort to me. Testing against DT bindings/schemas coming from mainline kernel and other OS kernels can be difficult especially if those schema versions regress each other. Also, I suppose this DT checking happens for a single firmware version supporting the current DTS at that point. But what happens if we want to do firmware updates with a newer DTS version (new features)? Do we still have some DT checking mechanism for those? Also, what if the list of supported OS kernels expands in future?
IMHO, the DT checking should be part of the firmware build process. And having a single canonical set of requirements to check against would greatly simplify DT checking. IOW, if we can have only a single version of DT bindings/schemas which is supported by all DT consumers.
Currently we do have core DT schemas maintained here [2] and on similar grounds we should be able to decouple device specific bindings/schema files from the Linux kernel to the DT schema [2] repo. Although this is something that has been discussed in the past here [3], I still think it can be a good step for DT ABI checking tools to be effective and incorporated into the firmware build process which in turn will improve confidence in firmware provided DTB.
[1] https://youtu.be/0Rw58lP3zPA [2] https://github.com/devicetree-org/dt-schema/tree/main/dtschema/schemas [3] https://lore.kernel.org/all/CAFA6WYPYfKU9hHh5CCbgcb6FEDX7ivGO=tGv4N2dAX6_gAG...
-Sumit
(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...
Hi Elliot,
On Wed, 8 May 2024 at 18:28, Elliot Berman quic_eberman@quicinc.com wrote:
(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.
Thank you for the info and link.
I believe the compatible string is still the best approach. It has a number of benefits:
1. It is in fact the purpose of compatible strings to match hardware with a driver 2. It is already widely used in U-Boot 3. It is the foundation for FIT (Flat Image Tree) which is widely supported in bootloaders 4. Linux now has a 'make fit' target which uses this information, allowing bootloaders to automatically boot a Linux kernel with the correct dtb. 5. It allows vendors to decide their own naming of the different boards, without needing anything to change in U-Boot or LInux
The problems mentioned with compatible strings have already been solved, so far as I can tell. In all of arm64 / Linux I believe there is only 1 board with a problem (or is it 2?) where the compatible string is not unique.
The parsing code we are talking about is not large...about 100 lines of code which seems much easier than creating an entirely new way of doing things. The slides in [1] are certainly an interesting idea, but I struggle to see the need.
Adding things like the display panel to the top-level compatible string seems unnecessary. Can you not add nodes for each one and select the correct driver at runtime? Or, since presumably the bootloader knows which display is being used, it can do any necessary fix-ups? This is widely done in U-Boot.
The one area which I think could be improved is dealing with minor board variants, sometimes called SKUs. There is a ChromiumOS proposal on this which has been used for some years, though [5]
Regards, Simon
[5] https://www.kernel.org/doc/html/v6.2/arm/googl.e/chromebook-boot-flow.html
Thanks, Elliot
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
Hi Elliot,
On Wed, 8 May 2024 at 18:28, Elliot Berman quic_eberman@quicinc.com wrote:
(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.
Thank you for the info and link.
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
- It is already widely used in U-Boot
There are more bootloaders than U-Boot :)
I think U-boot's best fit matching algorithm has a flaw:
Root compatible strings (almost?) always describe the specific board compatible string as well as a compatible or two for the SoC family or other attributes.
Example picked at random: arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dahlia.dts: "toradex,verdin-am62-wifi-dahlia", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dev.dts: "toradex,verdin-am62-wifi-dev", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
The DT spec says that compatible string matching should be done like this:
Example: compatible = "fsl,mpc8641", "ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.
There is a problem right away with compatible string matching: what if OS's DTB package doesn't contain the particular board but *does* contain another board with that SoC? How do you ensure the other board isn't picked based off the SoC compatible? This is quite a different problem from compatible strings in the rest of the devicetree. If you fall back to a different compatible in the case of a device node, the device should still generally work. If you fall back in the root node case, you could be loading wrong DTB and have random system instability.
My interpretation of U-boot's best match algorithm could pick a configuration that matches the SoC compatible only. IMO, this would lead to undefined behavior as no one tests what happens when you boot board A DTB on board B, even if they have the same SoC.
- It is the foundation for FIT (Flat Image Tree) which is widely
supported in bootloaders
I don't think board-id isn't incompatible with FIT, although additions to the spec are needed to allow for the properties.
- Linux now has a 'make fit' target which uses this information,
allowing bootloaders to automatically boot a Linux kernel with the correct dtb.
- It allows vendors to decide their own naming of the different
boards, without needing anything to change in U-Boot or LInux
board-id has the same benefit, I think. I have a v3 of board-id based more on my slides which I can send out tomorrow. I've included the selection algorithm and some tests to demo how it could work.
The problems mentioned with compatible strings have already been solved, so far as I can tell. In all of arm64 / Linux I believe there is only 1 board with a problem (or is it 2?) where the compatible string is not unique.
I'm not sure they are all solved yet. depthcharge and u-boot have different algorithms to match the DTBs. Compatible strings and DT fixups are an ideal solution, but I think there are corner cases which need to be considered. Can Chromebooks switch to u-boot's best match algorithm?
The parsing code we are talking about is not large...about 100 lines of code which seems much easier than creating an entirely new way of doing things. The slides in [1] are certainly an interesting idea, but I struggle to see the need.
For what its worth, the board-id matching can also be done in <100 lines of code in the bootloader and should also be simple for firmware to implement.
Adding things like the display panel to the top-level compatible string seems unnecessary. Can you not add nodes for each one and select the correct driver at runtime? Or, since presumably the bootloader knows which display is being used, it can do any necessary fix-ups? This is widely done in U-Boot.
Display panel may not be the greatest example because it's mostly a leaf node. Different PMIC might be a better example since there are references to regulators throughout the DT which would need fixups.
The one area which I think could be improved is dealing with minor board variants, sometimes called SKUs. There is a ChromiumOS proposal on this which has been used for some years, though [5]
Depthcharge is ChromiumOS specific and I don't know how to make it more generic. Really, board-id is just QuIC's msm-id made a generic. I'm not glued to board-id, but I think it's a clean solution for Jonathan's original problem statement. I'd like to help review/improve a compatible string-based matching algorithm; hope my feedback on the u-boot approach can be considered.
Thanks, Elliot
[5] https://www.kernel.org/doc/html/v6.2/arm/google/chromebook-boot-flow.html
Hi Elliot,
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
Hi Elliot,
On Wed, 8 May 2024 at 18:28, Elliot Berman quic_eberman@quicinc.com wrote:
(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.
Thank you for the info and link.
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
- It is already widely used in U-Boot
There are more bootloaders than U-Boot :)
U-Boot is the main bootloader on embedded ARM devices. It is where most development has taken place over many years. Importantly, it has produced the FIT standard [6].
I think U-boot's best fit matching algorithm has a flaw:
Root compatible strings (almost?) always describe the specific board compatible string as well as a compatible or two for the SoC family or other attributes.
Example picked at random: arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dahlia.dts: "toradex,verdin-am62-wifi-dahlia", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dev.dts: "toradex,verdin-am62-wifi-dev", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
The DT spec says that compatible string matching should be done like this:
Example: compatible = "fsl,mpc8641", "ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.
There is a problem right away with compatible string matching: what if OS's DTB package doesn't contain the particular board but *does* contain another board with that SoC? How do you ensure the other board isn't picked based off the SoC compatible? This is quite a different problem from compatible strings in the rest of the devicetree. If you fall back to a different compatible in the case of a device node, the device should still generally work. If you fall back in the root node case, you could be loading wrong DTB and have random system instability.
My interpretation of U-boot's best match algorithm could pick a configuration that matches the SoC compatible only. IMO, this would lead to undefined behavior as no one tests what happens when you boot board A DTB on board B, even if they have the same SoC.
'U-Boot', BTW
The U-Boot best-fit mechanism has been used for years over a huge variety of boards and manufacturers. It seems to work very well.
Are you worried about the case where there is no DT for the board in question? In that case, the best match will indeed not be ideal. The solution is to provide a suitable DT.
- It is the foundation for FIT (Flat Image Tree) which is widely
supported in bootloaders
I don't think board-id isn't incompatible with FIT, although additions to the spec are needed to allow for the properties.
- Linux now has a 'make fit' target which uses this information,
allowing bootloaders to automatically boot a Linux kernel with the correct dtb.
- It allows vendors to decide their own naming of the different
boards, without needing anything to change in U-Boot or LInux
board-id has the same benefit, I think. I have a v3 of board-id based more on my slides which I can send out tomorrow. I've included the selection algorithm and some tests to demo how it could work.
Since we already have a solution, we should be careful about throwing it away and creating a whole new solution.
The problems mentioned with compatible strings have already been solved, so far as I can tell. In all of arm64 / Linux I believe there is only 1 board with a problem (or is it 2?) where the compatible string is not unique.
I'm not sure they are all solved yet. depthcharge and u-boot have different algorithms to match the DTBs. Compatible strings and DT fixups are an ideal solution, but I think there are corner cases which need to be considered. Can Chromebooks switch to u-boot's best match algorithm?
I actually thing some tweaks are needed, specifically:
- define exactly what the algorithm does - provide support for board revisions as with Chromebooks
Then, yes, we can unify these two approaches.
The parsing code we are talking about is not large...about 100 lines of code which seems much easier than creating an entirely new way of doing things. The slides in [1] are certainly an interesting idea, but I struggle to see the need.
For what its worth, the board-id matching can also be done in <100 lines of code in the bootloader and should also be simple for firmware to implement.
Yes, but your objection was about implementing the best-match algorithm in firmware, which is why I pointed out that it is quite easy.
Adding things like the display panel to the top-level compatible string seems unnecessary. Can you not add nodes for each one and select the correct driver at runtime? Or, since presumably the bootloader knows which display is being used, it can do any necessary fix-ups? This is widely done in U-Boot.
Display panel may not be the greatest example because it's mostly a leaf node. Different PMIC might be a better example since there are references to regulators throughout the DT which would need fixups.
OK
The one area which I think could be improved is dealing with minor board variants, sometimes called SKUs. There is a ChromiumOS proposal on this which has been used for some years, though [5]
Depthcharge is ChromiumOS specific and I don't know how to make it more generic. Really, board-id is just QuIC's msm-id made a generic. I'm not glued to board-id, but I think it's a clean solution for Jonathan's original problem statement. I'd like to help review/improve a compatible string-based matching algorithm; hope my feedback on the u-boot approach can be considered.
I'd be happy to work on that. The ChromiumOS piece is a pretty tweak to the U-Boot / FIT algorithm. I will spend some time looking at an update to the FIT spec which can cover this. Once I have a PR for you to consider, I will reply here.
Regards, Simon
[6] https://github.com/open-source-firmware/flat-image-tree
[5] https://www.kernel.org/doc/html/v6.2/arm/google/chromebook-boot-flow.html
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
Hi Elliot,
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
Hi Elliot,
On Wed, 8 May 2024 at 18:28, Elliot Berman quic_eberman@quicinc.com wrote:
(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.
Thank you for the info and link.
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
[1]: https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3
- It is already widely used in U-Boot
There are more bootloaders than U-Boot :)
U-Boot is the main bootloader on embedded ARM devices. It is where most development has taken place over many years. Importantly, it has produced the FIT standard [6].
I think U-boot's best fit matching algorithm has a flaw:
Root compatible strings (almost?) always describe the specific board compatible string as well as a compatible or two for the SoC family or other attributes.
Example picked at random: arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dahlia.dts: "toradex,verdin-am62-wifi-dahlia", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dev.dts: "toradex,verdin-am62-wifi-dev", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
The DT spec says that compatible string matching should be done like this:
Example: compatible = "fsl,mpc8641", "ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.
There is a problem right away with compatible string matching: what if OS's DTB package doesn't contain the particular board but *does* contain another board with that SoC? How do you ensure the other board isn't picked based off the SoC compatible? This is quite a different problem from compatible strings in the rest of the devicetree. If you fall back to a different compatible in the case of a device node, the device should still generally work. If you fall back in the root node case, you could be loading wrong DTB and have random system instability.
My interpretation of U-boot's best match algorithm could pick a configuration that matches the SoC compatible only. IMO, this would lead to undefined behavior as no one tests what happens when you boot board A DTB on board B, even if they have the same SoC.
'U-Boot', BTW
The U-Boot best-fit mechanism has been used for years over a huge variety of boards and manufacturers. It seems to work very well.
Are you worried about the case where there is no DT for the board in question? In that case, the best match will indeed not be ideal. The solution is to provide a suitable DT.
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
Hi Elliot,
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
Hi Elliot,
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
Hi Elliot,
On Wed, 8 May 2024 at 18:28, Elliot Berman quic_eberman@quicinc.com wrote:
(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.
Thank you for the info and link.
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
- It is already widely used in U-Boot
There are more bootloaders than U-Boot :)
U-Boot is the main bootloader on embedded ARM devices. It is where most development has taken place over many years. Importantly, it has produced the FIT standard [6].
I think U-boot's best fit matching algorithm has a flaw:
Root compatible strings (almost?) always describe the specific board compatible string as well as a compatible or two for the SoC family or other attributes.
Example picked at random: arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dahlia.dts: "toradex,verdin-am62-wifi-dahlia", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dev.dts: "toradex,verdin-am62-wifi-dev", "toradex,verdin-am62-wifi", "toradex,verdin-am62", "ti,am625"
The DT spec says that compatible string matching should be done like this:
Example: compatible = "fsl,mpc8641", "ns16550"; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.
There is a problem right away with compatible string matching: what if OS's DTB package doesn't contain the particular board but *does* contain another board with that SoC? How do you ensure the other board isn't picked based off the SoC compatible? This is quite a different problem from compatible strings in the rest of the devicetree. If you fall back to a different compatible in the case of a device node, the device should still generally work. If you fall back in the root node case, you could be loading wrong DTB and have random system instability.
My interpretation of U-boot's best match algorithm could pick a configuration that matches the SoC compatible only. IMO, this would lead to undefined behavior as no one tests what happens when you boot board A DTB on board B, even if they have the same SoC.
'U-Boot', BTW
The U-Boot best-fit mechanism has been used for years over a huge variety of boards and manufacturers. It seems to work very well.
Are you worried about the case where there is no DT for the board in question? In that case, the best match will indeed not be ideal. The solution is to provide a suitable DT.
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
At least with U-Boot, even when the DTB is packaged with the OS, it is located and provided to the OS by the firmware, just as the OS is.
Here is my current proposal:
https://github.com/open-source-firmware/flat-image-tree/pull/10/commits
Regards, Simon
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
- Elliot
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote:
I believe the compatible string is still the best approach. It has a number of benefits:
- It is in fact the purpose of compatible strings to match hardware
with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Regards, Simon
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote:
On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: > I believe the compatible string is still the best approach. It has a > number of benefits: > > 1. It is in fact the purpose of compatible strings to match hardware > with a driver
Agreed. Compatible string matching works great for the rest of the device tree, but I think matching the root node compatible has different challenges that the rest of DT doesn't have.
I'm open to use compatible strings, but we (EBBR) should describe how OSes should pick the DTB based on the compatible strings given by firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
Best regards
Heinrich
On 6/6/24 11:03 AM, Heinrich Schuchardt wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: > On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >> I believe the compatible string is still the best approach. It has a >> number of benefits: >> >> 1. It is in fact the purpose of compatible strings to match hardware >> with a driver > > Agreed. Compatible string matching works great for the rest of the > device tree, but I think matching the root node compatible has different > challenges that the rest of DT doesn't have. > > I'm open to use compatible strings, but we (EBBR) should describe how > OSes should pick the DTB based on the compatible strings given by > firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
The thing is the "devicetree" command still needs the DTB name hard-coded which makes the OS image *not* perfectly generic (and building a menu entry for each possible board is a bit nonsensical).
The top level solution proposed here *was* to pass that name in from firmware instead (or find the top level compatible string in the firmware provided DT and then search for an OS provided DT with the same compatible). But Elliot's ID system seems like it could allow for an even better way.
What we would need extra is to have a file similar to the modalias file for modules, but for DT. A lookup table generated from DT IDs that maps from a provided ID to a set (as in a base DT plus overlays) of DT files to load for the given ID.
Firmware provides a base DT with enough info to run the bootloader, then the bootloader uses the ID to quickly find and load the OS provided DT if available (falling back to just passing the simple firmware provided DT on to the OS if needed).
Is that a fair summary?
Andrew
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
Best regards
Heinrich _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Andrew Davis afd@ti.com schrieb am Do., 6. Juni 2024, 18:39:
On 6/6/24 11:03 AM, Heinrich Schuchardt wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com
wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com
wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: > On Mon, 20 May 2024 at 18:27, Elliot Berman <
quic_eberman@quicinc.com> wrote:
>> On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >>> I believe the compatible string is still the best approach. It
has a
>>> number of benefits: >>> >>> 1. It is in fact the purpose of compatible strings to match
hardware
>>> with a driver >> >> Agreed. Compatible string matching works great for the rest of the >> device tree, but I think matching the root node compatible has
different
>> challenges that the rest of DT doesn't have. >> >> I'm open to use compatible strings, but we (EBBR) should describe
how
>> OSes should pick the DTB based on the compatible strings given by >> firmware so that there is consistency. > > Yes, agreed. Do you have a proposal for this? >
AMD did some work based off regex strings, maybe this could be
expanded
and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and
the
OS provides its own. Firmware has to provide enough information that
OS
can pick the DTB and also OS need to be able to detect that it
doesn't
have a DTB for the platform and should fallback to the
firmware-provided
DT.
Maybe the scenario I think about isn't valid -- in that case, we
should
make sure that the spec says something about how "if OS wants to
provide
own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the
device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
The thing is the "devicetree" command still needs the DTB name hard-coded which makes the OS image *not* perfectly generic (and building a menu entry for each possible board is a bit nonsensical).
The current solution is as follows:
On the installer image put all device-trees of the installer kernel into directory /dtb of the ESP.
U-Boot installs the device-tree matching the board as EFI configuration table.
After booting the compatible and model properties are available in /proc/device-tree
Now update-grub can write the correct devicetree commands for each installed kernel based on these properties into grub.cfg.
The top level solution proposed here *was* to pass that name in from firmware instead (or find the top level compatible string in the firmware provided DT and then search for an OS provided DT with the same compatible). But Elliot's ID system seems like it could allow for an even better way.
That ID system seems to add complexity and is not needed for the solution described above.
What we would need extra is to have a file similar to the modalias file for modules, but for DT. A lookup table generated from DT IDs that maps from a provided ID to a set (as in a base DT plus overlays) of DT files to load for the given ID.
Have a look at all.db in Debian's package flash-kernel. It maps the model property to the device-tree file name.
A similar lookup table could be integrated into grub.cfg if grub could write a property of the installed device-tree into a variable.
Best regards
Heinrich
Firmware provides a base DT with enough info to run the bootloader, then the bootloader uses the ID to quickly find and load the OS provided DT if available (falling back to just passing the simple firmware provided DT on to the OS if needed).
Is that a fair summary?
Andrew
Systemd-boot also provides device-trees and uses the
EFI_DT_FIXUP_PROTOCOL.
Best regards
Heinrich _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Thu, Jun 06, 2024 at 11:39:06AM -0500, Andrew Davis wrote:
On 6/6/24 11:03 AM, Heinrich Schuchardt wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: > On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: > > On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: > > > I believe the compatible string is still the best approach. It has a > > > number of benefits: > > > > > > 1. It is in fact the purpose of compatible strings to match hardware > > > with a driver > > > > Agreed. Compatible string matching works great for the rest of the > > device tree, but I think matching the root node compatible has different > > challenges that the rest of DT doesn't have. > > > > I'm open to use compatible strings, but we (EBBR) should describe how > > OSes should pick the DTB based on the compatible strings given by > > firmware so that there is consistency. > > Yes, agreed. Do you have a proposal for this? >
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
The thing is the "devicetree" command still needs the DTB name hard-coded which makes the OS image *not* perfectly generic (and building a menu entry for each possible board is a bit nonsensical).
The top level solution proposed here *was* to pass that name in from firmware instead (or find the top level compatible string in the firmware provided DT and then search for an OS provided DT with the same compatible). But Elliot's ID system seems like it could allow for an even better way.
What we would need extra is to have a file similar to the modalias file for modules, but for DT. A lookup table generated from DT IDs that maps from a provided ID to a set (as in a base DT plus overlays) of DT files to load for the given ID.
Firmware provides a base DT with enough info to run the bootloader, then the bootloader uses the ID to quickly find and load the OS provided DT if available (falling back to just passing the simple firmware provided DT on to the OS if needed).
Is that a fair summary?
This, frankly, sounds like a very round-about way of constructing the top-level compatible, again, for a platform and then loading the correct filename. Why not just a modalias type file that says compatible,X is file-y.dtb ?
On Thu, Jun 06, 2024 at 06:03:51PM +0200, Heinrich Schuchardt wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: > On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: > > I believe the compatible string is still the best approach. It has a > > number of benefits: > > > > 1. It is in fact the purpose of compatible strings to match hardware > > with a driver > > Agreed. Compatible string matching works great for the rest of the > device tree, but I think matching the root node compatible has different > challenges that the rest of DT doesn't have. > > I'm open to use compatible strings, but we (EBBR) should describe how > OSes should pick the DTB based on the compatible strings given by > firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
I'm sorry but that seems like a distinction without a difference. Simon said "/bootloader" and GRUB/systemd-boot are very much "bootloader".
And anyhow, what are both of those cases going to be doing with a UKI, which is much more like what dealing with a FIT is, with FIT having already defined "find the right device tree" whereas I do not know if UKI has moved past "implementation dependent" or so there.
Hi Heinrich,
On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote:
On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: > On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >> I believe the compatible string is still the best approach. It has a >> number of benefits: >> >> 1. It is in fact the purpose of compatible strings to match hardware >> with a driver > > Agreed. Compatible string matching works great for the rest of the > device tree, but I think matching the root node compatible has different > challenges that the rest of DT doesn't have. > > I'm open to use compatible strings, but we (EBBR) should describe how > OSes should pick the DTB based on the compatible strings given by > firmware so that there is consistency.
Yes, agreed. Do you have a proposal for this?
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
I was considering grub to be a bootloader, though. The OS doesn't find the file itself, right?
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
OK.
Regards, SImon
On 10.06.24 15:52, Simon Glass wrote:
Hi Heinrich,
On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote:
On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: > On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: >> On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >>> I believe the compatible string is still the best approach. It has a >>> number of benefits: >>> >>> 1. It is in fact the purpose of compatible strings to match hardware >>> with a driver >> >> Agreed. Compatible string matching works great for the rest of the >> device tree, but I think matching the root node compatible has different >> challenges that the rest of DT doesn't have. >> >> I'm open to use compatible strings, but we (EBBR) should describe how >> OSes should pick the DTB based on the compatible strings given by >> firmware so that there is consistency. > > Yes, agreed. Do you have a proposal for this? >
AMD did some work based off regex strings, maybe this could be expanded and made part of the EBBR and DT spec [1].
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
The scenario I like to think about is where OS wants to run on many boards/platforms and wants to override DTB for only some of those boards/platforms. Perhaps the firmware-provided DTB on most of the boards is good for the OS, but not good enough for couple boards and the OS provides its own. Firmware has to provide enough information that OS can pick the DTB and also OS need to be able to detect that it doesn't have a DTB for the platform and should fallback to the firmware-provided DT.
Maybe the scenario I think about isn't valid -- in that case, we should make sure that the spec says something about how "if OS wants to provide own DTB, it must have DTBs for all the boards the OS could run on".
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
I was considering grub to be a bootloader, though. The OS doesn't find the file itself, right?
The Linux kernel does not scan for device-trees. It requires that the correct device-tree or ACPI tables are installed as EFI configuration table. This can be done by firmware or by the bootloader provided by the OS.
Best regards
Heinrich
Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
OK.
Regards, SImon
Hi Heinrich,
On Mon, 10 Jun 2024 at 08:13, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 10.06.24 15:52, Simon Glass wrote:
Hi Heinrich,
On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote:
On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote: > On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: >> On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: >>> On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >>>> I believe the compatible string is still the best approach. It has a >>>> number of benefits: >>>> >>>> 1. It is in fact the purpose of compatible strings to match hardware >>>> with a driver >>> >>> Agreed. Compatible string matching works great for the rest of the >>> device tree, but I think matching the root node compatible has different >>> challenges that the rest of DT doesn't have. >>> >>> I'm open to use compatible strings, but we (EBBR) should describe how >>> OSes should pick the DTB based on the compatible strings given by >>> firmware so that there is consistency. >> >> Yes, agreed. Do you have a proposal for this? >> > > AMD did some work based off regex strings, maybe this could be expanded > and made part of the EBBR and DT spec [1]. > > [1]: https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3
OK, thanks. Note that I consider this a vendor-specific addition to U-Boot, similar to the 'hat' approach used by Beaglebone. The actual mechanism is using overlays, from what I can tell, with the DT modified in Linux by applying overlays. Is that right? If so, it doesn't seem relevant to what you propose here.
I think you should take a look at how far you can get with just compatible strings, so we can see what is actually missing.
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
> > The scenario I like to think about is where OS wants to run on many > boards/platforms and wants to override DTB for only some of those > boards/platforms. Perhaps the firmware-provided DTB on most of the > boards is good for the OS, but not good enough for couple boards and the > OS provides its own. Firmware has to provide enough information that OS > can pick the DTB and also OS need to be able to detect that it doesn't > have a DTB for the platform and should fallback to the firmware-provided > DT. > > Maybe the scenario I think about isn't valid -- in that case, we should > make sure that the spec says something about how "if OS wants to provide > own DTB, it must have DTBs for all the boards the OS could run on". >
I don't know of an OS that can find its own DTB. Which particular OS are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
I was considering grub to be a bootloader, though. The OS doesn't find the file itself, right?
The Linux kernel does not scan for device-trees. It requires that the correct device-tree or ACPI tables are installed as EFI configuration table. This can be done by firmware or by the bootloader provided by the OS.
Right, so I believe we should use the best-match mechanism in U-Boot to locate the correct DT and provide it. Is that possible?
Regards, Simon
On 10.06.24 17:02, Simon Glass wrote:
Hi Heinrich,
On Mon, 10 Jun 2024 at 08:13, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 10.06.24 15:52, Simon Glass wrote:
Hi Heinrich,
On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 06.06.24 17:57, Simon Glass wrote:
Hi Elliot,
On Wed, 5 Jun 2024 at 11:31, Elliot Berman quic_eberman@quicinc.com wrote:
Hi Simon,
On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote: > On Wed, 29 May 2024 at 11:02, Elliot Berman quic_eberman@quicinc.com wrote: >> On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: >>> On Mon, 20 May 2024 at 18:27, Elliot Berman quic_eberman@quicinc.com wrote: >>>> On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: >>>>> I believe the compatible string is still the best approach. It has a >>>>> number of benefits: >>>>> >>>>> 1. It is in fact the purpose of compatible strings to match hardware >>>>> with a driver >>>> >>>> Agreed. Compatible string matching works great for the rest of the >>>> device tree, but I think matching the root node compatible has different >>>> challenges that the rest of DT doesn't have. >>>> >>>> I'm open to use compatible strings, but we (EBBR) should describe how >>>> OSes should pick the DTB based on the compatible strings given by >>>> firmware so that there is consistency. >>> >>> Yes, agreed. Do you have a proposal for this? >>> >> >> AMD did some work based off regex strings, maybe this could be expanded >> and made part of the EBBR and DT spec [1]. >> >> [1]: https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 > > OK, thanks. Note that I consider this a vendor-specific addition to > U-Boot, similar to the 'hat' approach used by Beaglebone. The actual > mechanism is using overlays, from what I can tell, with the DT > modified in Linux by applying overlays. Is that right? If so, it > doesn't seem relevant to what you propose here. > > I think you should take a look at how far you can get with just > compatible strings, so we can see what is actually missing. >
The talk and slides I gave at EOSS covered the challenges we had in implementing a typical compatible string-based mechanism for DT selection.
I read through the slides a few weeks back and just looked again. I cannot quite see why the existing mechanism doesn't solve your problem.
The example of the hugely long string seems excessive to me, in that you should really be using the DT to describe some of that hardware, rather than putting it in the top-level compatible.
[snip]
>> >> The scenario I like to think about is where OS wants to run on many >> boards/platforms and wants to override DTB for only some of those >> boards/platforms. Perhaps the firmware-provided DTB on most of the >> boards is good for the OS, but not good enough for couple boards and the >> OS provides its own. Firmware has to provide enough information that OS >> can pick the DTB and also OS need to be able to detect that it doesn't >> have a DTB for the platform and should fallback to the firmware-provided >> DT. >> >> Maybe the scenario I think about isn't valid -- in that case, we should >> make sure that the spec says something about how "if OS wants to provide >> own DTB, it must have DTBs for all the boards the OS could run on". >> > > I don't know of an OS that can find its own DTB. Which particular OS > are you thinking of?
Aren't most devices doing that today? Relatively few devices are using firmware-provided DTs.
Oh I mean that the DT is included with the OS, but it is the firmware/bootloader that actually loads it and presents it to the OS. At least that is how supposed to work (if the OS wants its own). Most boards and distros I am aware of seem to do this.
Ubuntu does not. It uses GRUBs devicetree command to load the device-trees and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups.
I was considering grub to be a bootloader, though. The OS doesn't find the file itself, right?
The Linux kernel does not scan for device-trees. It requires that the correct device-tree or ACPI tables are installed as EFI configuration table. This can be done by firmware or by the bootloader provided by the OS.
Right, so I believe we should use the best-match mechanism in U-Boot to locate the correct DT and provide it. Is that possible?
No it is not, as U-Boot does not know which kernel will be run by GRUB.
Best regards
Heinrich
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.
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
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.
Francesco
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.
Hello Tom,
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:
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.
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.
Francesco
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).
boot-architecture@lists.linaro.org
-
Ahmad Fatoum -
Andrew Davis -
Daniel Thompson -
ecurtin＠redhat.com -
Elliot Berman -
ff -
Francesco Dolcini -
Heinrich Schuchardt -
Humphreys, Jonathan -
Jan Lübbe -
Jon Humphreys
-
Marcin Juszkiewicz -
Pere Garcia -
Rob Herring -
Simon Glass -
Steve Capper -
Sumit Garg -
Tom Rini