On 10/24/2012 03:47 AM, Daniel Mack wrote: > Hi, > > a project I'm involved in uses a module/baseboard combo, and components > on either board are described in DT. I'm currently using separate dts > files which build upon each other with include statements, which works > fine for development. > > In production though, we will certainly have running changes (and hence > different versions) over the lifetime of the product for both the > baseboard and the module, and the hardware has support for identifying > the versions of both sides at runtime. > > So let's say we have n versions of the baseboard and m versions of the > module, we would much like to only prepare n + m files, instead of n * m > by pre-compiling every possible combination (some of which may actually > never occur 'in the wild'). > > So my question is: is it possible to do that kind of assembly of a > number of files at runtime in U-Boot? I guess all it takes is merging a > number of trees together, right? I browsed through the APIs but couldn't > yet find an clear approach to that kind of problem. If not, what would > it take to add that functionality? I can probably help with the > implementation if someone tells me what would be the right way.
Yes, solving this would be very useful; it's a wide-spread problem. Some thoughts though: Simply overlaying two DTBs on top of each-other (in the same fashion that dtc's /include/ statement would do at compile-time) might not be fully general enough, although perhaps it would be sufficient for your immediate needs. For example, lets say that a GPIO is routed from a device on the main board to a device on a daughter board, or even from one daughter board into the main board and back out to a different daughter board. Now, consider that the different board(s) that are the source of the GPIO might use completely different SoCs or versions of the SoC, which might require using a different GPIO specifier to represent the signal. That means you need to change the .dtb file for the "client" of the GPIO depending on the HW or .dtb that provides the GPIO. That's certainly not a simple matter of merging multiple .dtb blobs together. The same issue could easily apply to I2C or SPI buses, chip selects, etc. One solution would be to explicitly represent a connector or connection-point in DT, such that the connector can implement the naming of all signals that pass through it, and provide a translation point for hooking the two DT fragments together. This seems within the spirit of DT. Another solution might be some form of variables/macros/code in the DTB that can be used to parameterize other DTBs that get merged with it. This is probably an enormous can of worms. I wonder if similar yet more subtle issues might arise, such as some motherboards requiring an active-low IRQ signal yet others requiring an active-high IRQ signal, thus requiring a daughter-board to program its IRQ source differently. Similarly, what about different drive strength requirements for a signal source, depending on what board version receives the signal? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
