On Sat, 16 Nov 2013 19:47:45 +0200, Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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. For consistency, please use aliases or full paths to nodes instead. Make DTC do the translation from labels to aliases/paths. g. -- 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