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