Hi Grant, On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou > <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >>> This handles many of the use cases, but it assumes that an overlay is >>> board specific. If it ever is required to support multiple base boards >>> with a single overlay file then there is a problem. The .dtb overlays >>> generated in this manor cannot handle different phandles or nodes that >>> are in a different place. On the other hand, the overlay source files >>> should have no problem being compiled for multiple targets, so maybe >>> it isn't an issue. Plus if dtc is installed on the target, then the >>> live tree from /proc can be used as the reference when compiling the >>> overlay. >> >> My worry is that this format is dependent on linking against the board >> DTS file. One of the ideas thrown around here was that it might make >> sense to store the DTB fragment in the EEPROM of the device. > > Right, that wouldn't work well if the base DT changed, or if a > BeagleBone2 is released that has the same header configuration, but > different backing devices. It would be nice to have a solution for > that. > >> In that case you have a OS independent hardware description, which can >> be even used even by the bootloader to access devices it knows not about >> at compile time. >> >> Other than that, I have no other objections. > > I'm open to suggestions if anyone has any. I have not objections to a > fixup approach, but I'm not comfortable with anything that is fragile > to modifications to the fragment. I am fairly new to the DT world so please bear with me, but how about a method that resolves symbols the same way that the linux dynamic linker does when shared libraries are loaded? A separate table (similar to .PLT/GOT sections in the ELF object format) could be created when the fragment is loaded, and the phandle references could be fixed to point to the table offsets during compile time. This table would be a second level indirection and the kernel would populate this table with the in-kernel values of the phandles that the dt fragment refers to. This might involve changes to the DT core, but as such, this method wouldn't suffer from the fragility problem of either base or fragment DT trees being modified. The table itself could be added to the tree by the compiler, and the phandles could point to it (fixed). such phandles could be marked for special handling to facilitate the 1-level indirection. What do you think about this? Regards, Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
