On Wed, Dec 3, 2025 at 6:11 AM Doug Anderson dianders@chromium.org wrote:
Hi,
On Mon, Dec 1, 2025 at 7:31 PM Chen-Yu Tsai wenst@chromium.org wrote:
Separately, it can be noted that we always _wanted_ a similar solution for ChromeOS, but we never quite got there... ;-)
FTR ChromeOS is moving in that direction: splitting SKU differences based on components into overlays that get applied to the base by the bootloader.
In the simplest example we could have one base dts and two overlays for two different DSI panel models:
- base.dtb
- panel-model-a.dtbo
- panel-model-b.dtbo
The problem we then run into is that the base.dtb will only have the generic model compatible "google,foo", not the sku and revision specific ones like "google,foo-sku1-rev2".
And we'd really like to avoid having _more_ overlays just to add the final specific compatible string, as that kind of defeats the purpose of using overlays to reduce the number of dts files.
I think you may have simplified the above a little too much to the point where it's confusing. At least I'm a bit confused. I _think_ the problems you're talking about are the kinds of things we run into when we take overlays above just two levels. I'm imagining:
- base.dtb
- board1-rev1.dtbo
- board2-rev1.dtbo
- board1-rev2.dtbo
- board2-rev2.dtbo
- panel-a.dtbo
- panel-b.dtbo
So I think you're saying that you'd start with the "base.dtb" and then extend it with exactly one of the "board" overlays and then exactly one of the "panel" overlays. Is that right?
For now I think we just experiment with having one end "model" or "product" as the base.dtb. The panel-*.dtbo selected describe the optional components, while the board-rev??.dtbo just provides the top level compatible and model.
In an example that I plan to send out this week, I would rework:
- arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri.dtsi - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku0.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku1.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku2.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku3.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku4.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku5.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku6.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku7.dts
into:
- arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri.dts - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-max98390-es8326.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-max98390-rt5682s.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-tas2563-es8326.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-audio-tas2563-rt5682s.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-panel-boe.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-panel-ivo.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku0.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku1.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku2.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku3.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku4.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku5.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku6.dtso - arch/arm64/boot/dts/mediatek/mt8188-geralt-ciri-sku7.dtso
The "mt8188-geralt-ciri-sku?.dtso" files only contain the following boilerplate:
/dts-v1/; /plugin/;
&{/} { model = "Google Ciri sku? board (rev4)"; compatible = "google,ciri-sku?", "google,ciri", "mediatek,mt8188"; };
The base "mt8188-geralt-ciri.dts" would already have a generic board- specific compatible:
model = "Google Ciri board"; compatible = "google,ciri", "mediatek,mt8188";
So I'd imagine that each of the "board" overlays could have "full" compatible strings. For instance, I'd imagine "board2-rev2" could have:
compatible = "google,booard2-rev2", "socVendor,soc"
The problem you're struggling with (I think) is that the panel overlays won't be represented in the compatible string (and "model") even though (historically) we always did in ChromeOS (they were included in the "sku" part of the compatible string).
Did I get that right?
In a sense you've generalized the problem I was describing.
In my example, the top level compatible gets fixed up by the final SKU-specific overlay. But that's 8 extra files to do one bit of fixup that supposedly the bootloader could be taught to do, and could do even better. The bootloader knows exactly which SKU and revision it's running on and can insert the information appropriately. We could get rid of those awkwardly long compatible string sequences:
compatible = "google,tentacruel-sku262147", "google,tentacruel-sku262146", "google,tentacruel-sku262145", "google,tentacruel-sku262144", "google,tentacruel", "mediatek,mt8186";
Going back to what I think you're describing, is that instead of one base board DTB for each product, we could have one base DTB for the reference design (in place of the .dtsi file we currently have), and make products and component selection all use overlays.
If we do that, then inserting the correct top level compatible and model becomes more important, since we do have things such as the ChromeOS OF component prober working based on top level compatible. Also, the model is present in logs, and would be very misleading to say one device name while in reality it is a different one.
I proposed internally maybe having the bootloader fix up the final compatible string, but I think we need some rough consensus upstream whether this is acceptable or not.
Maybe we need to come to some agreement about when the top-level compatible string needs to be changed. In the above, I'd perhaps argue that the panel isn't a major enough change that it needs to change the top-level compatible string. That would solve the problem, right? What do others think? Certainly for "probe-able" components we don't change the top-level compatible string. Can anyone point to any official documentation about the top-level compatible string?
I'd certainly like more documentation as well.
ChenYu