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