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];
};
};
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.
< snip >
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
