Hi Grant, On Nov 15, 2013, at 9:01 AM, Grant Likely wrote: > On Tue, 12 Nov 2013 11:20:04 +0100, Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> Hi Grant, >> >> On Nov 11, 2013, at 6:56 PM, Grant Likely wrote: >> >>> On Tue, 29 Oct 2013 21:01:06 +0200, Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >>>> Enable the generation of symbol & fixup information for >>>> usage with dynamic DT loading. >>>> >>>> Passing the -@ option generates a __symbols__ node at the >>>> root node of the resulting blob for any node labels used. >>>> >>>> When using the /plugin/ tag all unresolved label references >>>> be tracked in the __fixups__ node, while all local phandle >>>> references will the tracked in the __local_fixups__ node. >>>> >>>> This is sufficient to implement a dynamic DT object loader. >>>> >>>> Changes since v1: >>>> >>>> * Forward ported to 1.4 version >>>> * Added manual entries for the -@ option >>>> >>>> Signed-off-by: Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> >>> >>> Hi Pantelis, >>> >>> This looks pretty good on first look. Comments below. >>> >>>> --- >>>> Documentation/dt-object-internal.txt | 295 +++++++++++++++++++++++++++++++++++ >>>> Documentation/manual.txt | 10 ++ >> >> [snip] >> >>>> +----------------------------------------- >>>> + >>>> +Since the device tree is used for booting a number of very different hardware >>>> +platforms it is imperative that we tread very carefully. >>>> + >>>> +2.a) No changes to the Device Tree binary format. We cannot modify the tree >>>> +format at all and all the information we require should be encoded using device >>>> +tree itself. We can add nodes that can be safely ignored by both bootloaders and >>>> +the kernel. >>> >>> Not /entirely/ true. It would be completely fine to bump up the binary >>> format version for the overlays since they will never be loaded >>> standalone. If there are specific things that you would like to have in >>> the marshalled format then go ahead and propose them. Then the overlay >>> would use the new protocol version, but the base tree would use the >>> existing one. >> >> OK, I see. I am very hesitant to bump the format version, because both the >> base DTS and the overlay need to be compiled with symbol support. >> We can bump the version format for the overlay fragment, but bumping the >> version for the base DTS will affect bootloaders badly. > > Hmmm, I missed that detail. Why does the base tree require symbol > support? It looked to me like the overlay had all the resolution > information needed. > It is because the symbols are in our case the labels of the DTS. We need to generate a node containing all the labels so that the overlays can use in order to get the target of their insertion point. > g. > Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
