Hi Grant,

On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely [off-list ref] wrote:

On Mon, Nov 5, 2012 at 7:54 PM, Pantelis Antoniou
[off-list ref] wrote:

quoted

quoted

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.

quoted

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