On 11/13/2012 01:09 AM, Pantelis Antoniou wrote:
> On Nov 13, 2012, at 9:25 AM, David Gibson wrote:
...
>> 1) We annotate the base tree with some extra label information for
>> nodes which overlays are likely to want to reference by phandle. e.g.
>>
>> beaglebone_pic: interrupt-controller@XXXXX {
>> ...
>> phandle,symbolic-name = "beaglebone_pic";
>> };
>>
>> We could extend dtc to (optionally?) auto-generate those properties
>> from its existing label syntax. Not sure if that's a good idea or
>> not yet. In any case, we compile this augmented base tree to .dtb as
>> normal and boot our kernel with it.
>
> I'm fine with that. You can auto-generate when there's a label to a node.
> The cape dt fragment will use the label name to reference a node.
> More details below...
>
>> 2) The information for the capes/modules/whatever is
>> distributed/packaged as .dts, never .dtb. When userspace detects the
>> new module (or the user explicitly tells it, if it's not probeable) it
>> picks up the correct dts and runs it through dtc in a special mode.
>> In this mode dtc takes the existing base tree (from /proc/device-tree,
>> say) as well as the new dts. In this mode, dtc allocates phandles for
>> the new tree fragment so as not to collide with anything from the
>> supplied base tree (as well as avoiding internal conflicts,
>> obviously). It also allows node references to the base tree by using
>> those label annotations from (1) to match symbolic names to the
>> phandle values in the base tree.
>
> Not good to rely on userspace kicking off dtc and compiling from source.
> Some capes/expansion boards might have your root fs device, for example
> there is an eMMC cape coming up, while networking capes are common too.
>
> However I have a compromise.
>
> I agree that compiling from source can be an option for a runtime definable
> cape, but for built-in capes we could do a bit better.
>
> In particular, I don't see any particular need to have a DT fragment
> reference anything that dependent of the runtime device tree. It should
> be possible to compile the DT fragment in kernel, against the generated
> flattened device tree, producing a flattened DT fragment with the phandles
> already resolved.
>
> So the sequence could be something like this:
>
> $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE}
> $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE}
> $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE}
>
> The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated.
I'm not sure that will avoid phandle collisions though.
If you build everything at runtime, you'll always be compiling each new
partial .dtb based on the phandles actually in-use in the kernel's
current complete device tree. You can always easily avoid collisions
that way.
If you instead pre-compile both the based .dtb /and/ some partial .dtbs,
then you're essentially statically defining some phandle values, but
splitting those static assignments across 3 (in your example) different
.dtbs. However, what guarantees that those 3 .dtbs are already loaded
into the system when some fourth partial .dtb is loaded, such that the
static phandle assignments influence that fourth partial .dtb's runtime
compilation?
Put another way, what happens when you:
1) Boot the kernel using am335x-bone.dtb.
2) Incrementally load weather-cape.dtb. Don't incrementally load
geiger-cape.dtb for whatever reason.
3) Load runtime-compiled-cape.dtb. This avoids conflicts with the
already-loaded am335x-bone.dtb and weather-cape.dtb since
runtime-compiled-cape.dtb is compiled at runtime based on the currently
loaded .dtbs. However, it may well end up conflicting with
geiger-cape.dtb since that isn't loaded.
4) Now attempt to load geiger-cape.dtb - possible conflict.
Given all of that, I'd assert that if you want to statically assign any
phandles, all static assignments need to be done in the base .dtb that
the kernel is loaded with, and not in any pre-compiled partial .dtbs.
So, if your root filesystem is on an eMMC cape, then you need to create
a board .dts file that /include/s the base board .dts and the cape .dts
files and boot the kernel with that.
Or, you get U-Boot/... to merge the relevant pre-compiled .dtbs and boot
the kernel with that.
Or I suppose you could have a well-known range of phandles for
pre-compiled .dtbs that the runtime dtc mode always avoided, preferably
without the need for explicit phandle-range statements in the .dts
files, e.g. driven by a dtc static-assignment-vs-dynamic-assignment
command-line option?
--
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
