On Sun, Mar 04, 2018 at 09:00:08PM -0800, Frank Rowand wrote:
> On 03/04/18 18:51, David Gibson wrote:
> > On Tue, Feb 27, 2018 at 07:47:04PM -0800, Frank Rowand wrote:
> >> On 02/27/18 17:48, David Gibson wrote:
> >>> On Tue, Feb 27, 2018 at 09:58:00AM -0800, Frank Rowand wrote:
> >>>> On 02/27/18 07:54, Rob Herring wrote:
> >>>>> On Sun, Feb 25, 2018 at 9:22 PM, <frowand.list@xxxxxxxxx> wrote:
> >>>>>> From: Frank Rowand <frowand.list@xxxxxxxxx>
> >>>>>>
> >>>>>> Hi All,
> >>>>>>
> >>>>>> I am once again out of my depth with bison and flex.
> >>>>>
> >>>>> Can't help on that one...
> >>>>>
> >>>>>> The Devicetree Specification and ePAPR both tell me that I can
> >>>>>> put a label on a node, as in:
> >>>>>>
> >>>>>> [label:] node-name[@unit-address] {
> >>>>>> [properties definitions]
> >>>>>> [child nodes]
> >>>>>> }
> >>>>>
> >>>>> Applying this to the root node would also imply that a unit-address is
> >>>>> also allowed which it is not. I'd contend that the root is special.
> >>>>
> >>>> Good point. Looks like I may have some additions to propose for the
> >>>> spec to clarify things.
> >>>>
> >>>> Also not mentioned in the spec:
> >>>> - "[label:]" should be something like "[label:} ..." (not sure of
> >>>> the syntax we use in the spec for multiples>
> >>>
> >>> Right. In general you can have multiple labels on anything.
> >>>
> >>>> - that labels can be put on /memreserve/
> >>>
> >>> So, like labels within property values, labels on memreserve will only
> >>> do something measurable with -Oasm output, and isn't really useful
> >>> with modern device tree workflows.
> >>
> >> I don't have enough visibility into the various bootloaders (and
> >> operating systems other than Linux), so I did not have any guesses
> >> about how useful labels on /memreserve/ are.
> >
> > Not very. To understand both these and within-property labels you
> > need to understand a use case that sounded good in the early days, but
> > I don't think was ever really used: that's of a very static board,
> > which a single fixed device tree image *almost* works. The only
> > exception being a few very small in place changes between different
> > models: e.g. size of RAM, size of flash. The idea was that you could
> > make a really tiny bootloader for such a platform by simply compiling
> > in the dtb (using -Oasm mode). You put labels on the handful of
> > numbers that need updating, and the bootloader can set them to the
> > right values by simply assigning the symbols, no parsing of the dtb
> > structure necessary.
> >
> > In practice it's turned out that even for pretty simple boards you
> > usually either want to a) parse and read parts of the dtb for internal
> > use in the bootloader and/or b) make at least a few changes that
> > involve adding, removing or resizing nodes or properties (note that
> > even allowing the kernel command line to be updated will require the
> > last). Once you have that, the model above doesn't really work. Plus
> > the fact that libfdt is fairly straightforward to use, even for more
> > complex read/write cases means that that model was never widely used.
> >
> >> If no one is using
> >> them and nobody cares if they exist,
> >
> > That's probably true..
> >
> >> then getting rid of them is
> >> one possible fallback if nothing else works.
> >
> > ..but I'm still very hesitant about making a backwards incompatible
> > change to the source format.
>
> I agree with that.
>
>
> > Especially since the rationale for
> > labels on the root node is also looking pretty weak at this point.
>
> Why do you think it is weak? What would make the rationale stronger?
>
>
> > Oh, I also realised there is a way to put a label on the root node
> > using existing dts syntax.. although it's a bit weird and won't work
> > in a /plugin/ file. It uses the fact that "static" overlays (as in
> > resolved by dtc, rather than later) can also add labels:
> >
> > / {
> > /* stuff */
> > }
> >
> > rootlabel: &{/} { };
> >
> > I haven't actually tried that, but I think it should work.
>
> Interesting. Of course I had to try.
>
> I left out the compile warnings (which are unrelated to the question).
>
> $ cat root_label.dts
> /dts-v1/;
>
> /memreserve/ 0x0000000000000000 0x0000000000001000;
> / {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
>
> soc {
> node0@0x0 {
> reg = <0x0 0x1000>;
> };
> };
>
> };
>
> my_root: &{/} { };
>
> $ dtc -@ -O dts root_label.dts
> /dts-v1/;
>
> /memreserve/ 0x0000000000000000 0x0000000000001000;
> my_root: / {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> phandle = <0x1>;
>
> soc {
>
> node0@0x0 {
> reg = <0x0 0x1000>;
> };
> };
>
> __symbols__ {
> my_root = [2f 00];
> };
> };
Cool.
> That is good, now we have a root label in the __symbols__ node
> for the base devicetree _and_ the root node has a phandle.
>
>
> $ dtc -@ -O dts root_label.dts > new_root_label.dts
>
> $ dtc -@ -O dts new_root_label.dts
> Error: new_root_label.dts:4.10-11 syntax error
> FATAL ERROR: Unable to parse input tree
>
>
> And that error is totally expected, as new_root_label.dts is back in
> the form of "my_root: / {" that started me on this quest.
Ah, because the dts output unlike the dts input is not treating the
root node specially. That's a bug, although the nicer way to fix it
would be to make labels work normally on the root node which has the
complications we've previously discussed.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
