On Mon, Dec 1, 2025 at 5:52 PM Linus Walleij <[email protected]> wrote: > > Hi Dough, > > thanks for your mail! > > Let me just see if I understand correctly what you're trying to > do (and apparently actively doing in production): > > On Tue, Nov 18, 2025 at 11:43 PM Doug Anderson <[email protected]> wrote: > > > We would like an officially accepted scheme that lets us more > > efficiently ship compiled device trees for a handful of related > > products by breaking the device trees up into a common "base" device > > tree and then applying "overlay" device trees atop the base to make a > > full and complete device tree. > (...) > > In Android, we do a pretty good job of solving the stated problem > > using device tree overlays. We describe the SoCs in "dts" files and > > compile them into "dtb"s. We describe boards in "dtso" files and > > compile them into "dtbo" files. A bootloader can handle identifying > > the correct base and overlay (the scheme for doing this is a separate > > but related topic) and applying the overlay atop the base "dtb". This > > solution is fully implemented downstream for Android phones and is > > well documented [2]. > > So in the kernel we have several arch/*/boot/dts/vendor/ folders > where they have: > > soc.dtsi included by board.dtsi included by system.dts > and the top system.dts is all that get compiled. > > So what you say is that you do the same thing but at runtime? > > Can you just describe why this is done like this with > overlays? > > I can only guess that you have one bootloader that needs > to compose device trees to many systems and the bootloader > only discovers the system it is running on and its constraints > at runtime, so shipping the static system.dtb as many people > do is not an option for you? > > And the reason the bootloader doesn't already know what > it is running on and doesn't just pass that one device tree > or is just prepared with that one device tree has something > to do with manufacturing or so? > > Sorry it just evades me. > > Probably becayse even U-Boot these days use the provided > device tree dtb, for the system targeted, to initialize itself. I > suppose your bootloader is generic enough to avoid that > chicken-and-egg problem, right? > > I guess if I had this problem: > > soc.dtsi > board-a.dtsi > board-b.dtsi > system-board-a-v1.dts > system-board-a-v2.dts > system-board-b-v1.dts
This is the easy case. The harder one is you have soc-rev1.dtsi and soc-rev2.dtsi and you just doubled the combinations. > etc having to be combined at runtime, in a bootloader, I would > consider shipping exactly these files in a memory-based > filesystem in my bootloader, and bake a DTS compiler into > my bootloader so it can just build a device tree for what > it detects. We don't want to do that for the same reasons we don't pass a dts to the kernel... > But I guess you didn't want to hear that :D > > Anyway, please describe how you ended up in this situation, > I'm trying to understand this. > > It is quite clear that device tree overlays were intended for > say plug-n-play additions and minor fragments to be added > to a basically complete device tree, what you are doing was > probably not how it was intended. (Or let's see if someone > proves me wrong on that.) Board DTs are relatively minor compared to the SoC DT. I would be interested in some experiments around making this change with existing DTs. Take a board DT and add the overlay boilerplate (that may be nothing more than add '/plugin/') and remove the SoC include. Does that apply to a compiled SoC DTB and is the result the same as before? Think of it as moving from building C code using a #include of every .c file to build a single .o to linking multiple individual .o files. No one would argue the former is better. Rob _______________________________________________ boot-architecture mailing list -- [email protected] To unsubscribe send an email to [email protected]
