Speaker
Description
It is commonplace that many boards in the real world have many sibling or cousin boards that are 95-99% the same as each other. Some examples:
- During development, most boards go through several revisions. A board might have proto0, proto1, evt0, evt1, evt1.1, dvt1, pvt, and mp revisions. These revisions almost the same with just small changes. While only "mp" (mass production) devices should end up in the public's hands, old prototype devices continue to be used for many years within the companies supporting the hardware.
- Many boards have several small variants that are nearly the same. As an example, the Pixel 10, Pixel 10 Pro, and Pixel 10 Pro XL are based on the same design and are nearly the same.
- Many boards are based on a reference design and only make small changes from that reference design. Chromebooks are one example of this. "sc7180-trogdor" was a reference design and a pile of different ODMs took this design and made small changes. Outside of Chromebooks, many phones are heavily based on the reference design of the SoC vendor.
Products that are highly similar to each other usually end up sharing a single binary image that is shipped out. That single image contains all needed device trees. Firmware on the product can figure out which specific device it's running on and can pick the correct device tree.
The common practice in the upstream device tree repository today is that each of these very similar boards needs its own complete device tree. The device tree is often shared using #includes of .dtsi files, but the final result is a pile of .dtb files that are mostly the same.
There are a few problems we have today. Two of them that are perhaps the most important:
- All of those device trees take up a lot of space. It would be nice if we didn't need a whole pile of .dtb files that are nearly the same.
- While firmware has all the details about the exact device it's running on, there is no standard way to mark device tree files so firmware can find the right one.
The device-tree overlay concept should help with point #1 in reducing the amount of space things take up. Trying to get agreement about how this should look has been difficult, though. One question that came up is if a "base" device tree was required to be a board or not. For supporting Pixel 10 hardware, it was most convenient for the base device tree to represent the SoC itself since some Pixel 10 devices had a different revision of the SoC. A second question that came up is how to deal with the top-level device-tree "compatible" in this case. It was unclear if we needed some way to "merge" the compatible based on all the overlays included which then led into questions about what needed to be in this top-level "compatible" to begin with.
Trying to solve point #2 has come up again and again, but somehow we never end up with any resolution. The typical refrain is that we need a grand unified design that all device-tree loaders will agree to use, but this always fails to materialize.
Both problems have downstream solutions. As an example, Pixel phones ship with devicetree overlays to avoid some of the duplication. Device trees and their overlays on Pixel phones have special properties in them that are used to help firmware pick the right one at boot time. Trying to upstream these solutions has met with difficulty though.
Let's have a discussion where we look at prior attempts and see if we can make some more forward progress.
Some threads I've been involved in (this is by no means a complete list of threads about the topic):