[PATCH 0/3] capebus moving omap_devices to mach-omap2

[Pantelis Antoniou]

Hi Joel,

On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote:

> Hi Grant,
> 
> On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
>> 
>> 
>> Joel A Fernandes <agnel.joel at gmail.com> wrote:
>> 
>>> Hi Grant,
>>> 
>>> On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely
>>> <grant.likely at secretlab.ca> wrote:
>>>> 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.
>> 
>> That's an interesting idea that is worth exploring. That would make
>> it possible to avoid a fixup stage, but it also means that any parsing
>> code must know how to handle the got-like table. It won't be
>> backwards compatible with existing tools. It also wouldn't easily
>> support the case of firmware applying the overlay and passing the
>> resulting tree to the kernel. Hmmm.... Not being backwards compatible
>> at the data level is a big problem. I really want a method that can
>> resolve back to the current data format or is a compatible extension
>> of it.
>> 
> 
> Is it meaningful or feasible to make the table a part of the tree
> structure itself? the table would initially be empty. If I'm right,
> this is how the GOT tables in ELF objects that refer to unresolved
> symbols in shared libraries are implemented as well, they are a part
> of the object and are loaded into memory and fixed up. If the table is
> a part of the DT data, the tools would then be able to parse such a
> tree. We could enforce that the got-like tree would strictly follow a
> predefined format.
> 
> Something along these lines would also avoid the need for a tree fix
> up. Do you think this reduces the difficulty of backward compatibility
> with the parsing tools and firmware loading?

To be honest here, we are discussing a new object format. 
There are a few twists IMO.

a) We definitely, absolutely, don't want to introduce anything that will
risk compatibility with devices already out there. The binary format
for device trees that don't need the dynamic resolution features we're
talking about here, should be be usable for those older devices.

b) Device tree is flexible enough to store the additional data in it's own
node format. So we shouldn't have any kind of binary data tacked on; this
ties with a) - make sure that the binary format doesn't change.

c) There is no need (at least AFAIKT) of having any other resolution type
than a phandle of a node.

d) Finally, for some use-cases the problem is simplified by not having
all the features of a true dynamic linker. For example for the capebus
case the 'base' DTS won't have any references to any fragments. It is only
the fragments that have unresolved references and only to the 'base' DTS.

> 
>>> 
>>> 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.
>> 
>> That's part of the problem. Property values are essentially
>> anaonymous data. There is no mechanism currently for marking data
>> such as indicate which data values are phandles. If there were then
>> it would be a simple matter to find all the phandles and fix them up.
>> 
>> We could possibly add data type suppplementary properties to the tree
>> to solve that problem. They would have to be optional for the base
>> tree to retain backwards compatibility, but could be required on
>> overlays.
>> 
> 
> Sure, so if we add data type supplementary properties to the tree to
> indicate the data type as "indirect phandle", then kernel could refer
> to the index in the got-like table to fetch the actual phandle address
> (1-level of indirection), instead of directly using the address in the
> data field.
> 

I'm fine with this.

> 
> Thanks and Regards,
> 
> Joel

Regards

-- Pantelis