mips: fix DTC unit warnings
PATCH 1/1 mips: fix DTC unit warnings
Fix following warnings for all mips based boards:
mips: + pic32mzdask
+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg property
---
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8
This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184
see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033
arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/mips/dts/pic32mzda.dtsi +1 -1
@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };
arch/mips/dts/skeleton.dtsi +1 -1
@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 { device_type = "memory"; reg = <0 0>; };
Signature · 1 line
2.5.0
PATCH 1/1 mips: fix DTC unit warnings
Quoted 40 lines · Heiko Schocher
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
This warnings pop up with the DTC compiler:$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +0
-0
arch/mips/dts/skeleton.dtsi line 22
Quoted 8 lines
arch/mips/dts/skeleton.dtsi +1
-1@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 { device_type = "memory"; reg = <0 0>; };
PATCH 1/1 mips: fix DTC unit warnings
In reply to Heiko SchocherAm 15.04.2016 um 12:59 schrieb Heiko Schocher:
Quoted 7 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
Quoted 42 lines
This warnings pop up with the DTC compiler:
$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +1
-1@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 { device_type = "memory"; reg = <0 0>; };
Signature · 9 lines
- Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160415/6be5aea5/attachment.sig>
PATCH 1/1 mips: fix DTC unit warnings
In reply to Heiko SchocherAm 15.04.2016 um 12:59 schrieb Heiko Schocher:
Quoted 40 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
This warnings pop up with the DTC compiler:$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +0
-0
arch/mips/dts/skeleton.dtsi line 19
Quoted 5 lines
arch/mips/dts/skeleton.dtsi +1
-1@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 {
I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
If that is untrue, please someone object on the Linux mailing lists.
Regards,
Andreas
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +0
-0device_type = "memory"; reg = <0 0>; };
Signature · 3 lines
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Graham Norton HRB 21284 (AG N?rnberg)
PATCH 1/1 mips: fix DTC unit warnings
Quoted 52 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Quoted 40 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
This warnings pop up with the DTC compiler:$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +0
-0arch/mips/dts/skeleton.dtsi line 19
Quoted 5 lines
arch/mips/dts/skeleton.dtsi +1
-1@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
commit c9d9121683b35281239305e15adddfff2b462cf9
Author: Stephen Warren <[email protected]> Date: Fri Feb 19 15:59:29 2016 +1100
Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any node that has a reg property must include a unit address in its name with value matching the first entry in its reg property. Conversely, if a node does not have a reg property, the node name must not include a unit address. Also allow ranges property as it is deemed valid, but ePAPR is not clear about it.
Implement a check for this. The code doesn't validate the format of the unit address; ePAPR implies this may vary from (containing bus) binding to binding, so doing so would be much more complex.
That's where that warning comes from.
But some real quick grepping makes it seem like the cpu at 0 error is also a sign of a bigger problem in the dts file
But I would suggest that whomever is making special case warnings for U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're not a black box...
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160415/3c746d5b/attachment.sig>
PATCH 1/1 mips: fix DTC unit warnings
Quoted 6 lines · Tom Rini
Quoted 5 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg property
Note that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 6 lines
Quoted 6 lines
arch/mips/dts/pic32mzda.dtsi line 31
Quoted 6 lines
arch/mips/dts/pic32mzda.dtsi +1
-1cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc";
Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
Quoted 10 lines
Quoted 10 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 3 lines
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
I vaguely recall seeing discussion that /memory *would* be special-cased, but as you point out obviously isn't yet. I doubt it's anything to do with U-Boot itself, but rather the more general problem that if /memory at NNNN changes name based on what RAM is present, it's not possible for any bootloader to update it in a sane way (what node name do you search for to edit), or any OS to read it in a sane way (what node name do you search for to find out where memory is). As such, a special case is logically required.
Quoted 24 lines
commit
c9d9121683b35281239305e15adddfff2b462cf9Author: Stephen Warren <[email protected]> Date: Fri Feb 19 15:59:29 2016 +1100Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any node that has a reg property must include a unit address in its name with value matching the first entry in its reg property. Conversely, if a node does not have a reg property, the node name must not include a unit address. Also allow ranges property as it is deemed valid, but ePAPR is not clear about it.
Implement a check for this. The code doesn't validate the format of the unit address; ePAPR implies this may vary from (containing bus) binding to binding, so doing so would be much more complex.
Signed-off-by Stephen Warren <[email protected]>[robh: also allow non-empty ranges]Signed-off-by Rob Herring <[email protected]>[moved new test in check_table]Signed-off-by David Gibson <[email protected]>
Quoted 8 lines
That's where that warning comes from.
But some real quick grepping makes it seem like the cpu at 0 error is also a sign of a bigger problem in the dts file
But I would suggest that whomever is making special case warnings for U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're not a black box...
Equally though, anyone working on DT in U-Boot should be hanging out on the device tree mailing list, and getting actively involved in discussions, rather than hiding here.
PATCH 1/1 mips: fix DTC unit warnings
Quoted 16 lines · Stephen Warren
Quoted 6 lines · Tom Rini
Quoted 5 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertyNote that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/mips/dts/pic32mzda.dtsi +0
-0
Quoted 10 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi line 31
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi +1
-1cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc";Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
So the likely answer here is that the dtsi is wrong and needs to be fixed rather than just dropping @0.
Quoted 14 lines
Quoted 10 lines
Quoted 10 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 3 lines
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
Quoted 8 lines
I vaguely recall seeing discussion that /memory *would* be special-cased, but as you point out obviously isn't yet. I doubt it's anything to do with U-Boot itself, but rather the more general problem that if /memory at NNNN changes name based on what RAM is present, it's not possible for any bootloader to update it in a sane way (what node name do you search for to edit), or any OS to read it in a sane way (what node name do you search for to find out where memory is). As such, a special case is logically required.
Right, makes sense. But it'll also have to handle that today (nearly) everyone is /memory at NNNN.
Quoted 28 lines
Quoted 28 lines
commit
c9d9121683b35281239305e15adddfff2b462cf9Author: Stephen Warren <[email protected]> Date: Fri Feb 19 15:59:29 2016 +1100Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any node that has a reg property must include a unit address in its name with value matching the first entry in its reg property. Conversely, if a node does not have a reg property, the node name must not include a unit address. Also allow ranges property as it is deemed valid, but ePAPR is not clear about it.
Implement a check for this. The code doesn't validate the format of the unit address; ePAPR implies this may vary from (containing bus) binding to binding, so doing so would be much more complex.
Signed-off-by Stephen Warren <[email protected]>[robh: also allow non-empty ranges]Signed-off-by Rob Herring <[email protected]>[moved new test in check_table]Signed-off-by David Gibson <[email protected]>That's where that warning comes from.
But some real quick grepping makes it seem like the cpu at 0 error is also a sign of a bigger problem in the dts file
Quoted 7 lines
Quoted 3 lines
But I would suggest that whomever is making special case warnings for U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're not a black box...
Equally though, anyone working on DT in U-Boot should be hanging out on the device tree mailing list, and getting actively involved in discussions, rather than hiding here.
True. And devicetree-spec is very quiet and devicetree is very very loud, and somewhere along the line for me at least vger kicked me off, sigh. Fixing that at least.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160415/1f6114ff/attachment.sig>
PATCH 1/1 mips: fix DTC unit warnings
Quoted 54 lines · Tom Rini
Quoted 16 lines · Stephen Warren
Quoted 6 lines · Tom Rini
Quoted 5 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertyNote that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/mips/dts/pic32mzda.dtsi +0
-0Quoted 10 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi line 31
Quoted 4 lines
cpus {arch/mips/dts/pic32mzda.dtsi +1
-1- cpu at 0 { + cpu { compatible = "mips,mips14kc";Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
So the likely answer here is that the dtsi is wrong and needs to be fixed rather than just dropping @0.
Quoted 14 lines
Quoted 10 lines
Quoted 10 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 3 lines
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
Quoted 8 lines
I vaguely recall seeing discussion that /memory *would* be special-cased, but as you point out obviously isn't yet. I doubt it's anything to do with U-Boot itself, but rather the more general problem that if /memory at NNNN changes name based on what RAM is present, it's not possible for any bootloader to update it in a sane way (what node name do you search for to edit), or any OS to read it in a sane way (what node name do you search for to find out where memory is). As such, a special case is logically required.
Quoted 2 lines
Right, makes sense. But it'll also have to handle that today (nearly) everyone is /memory at NNNN.
Nodes without a unit address are far more common currently, on ARM at least:
u-boot$ grep -HrnI 'memory@' arch/arm/dts|wc -l
3
u-boot$ grep -HrnI 'memory {' arch/arm/dts|wc -l
86
kernel.git$ grep -HrnI 'memory {' arch/arm/boot/dts|wc -l 528
kernel.git$ grep -HrnI memory@ arch/arm/boot/dts|wc -l 27
kernel.git$ cat arch/arm/boot/dts/skeleton.dtsi
...
memory { device_type = "memory"; reg = <0 0>; };
(That last one is the base DT file that is typically included in all board files, and so should in theory set the correct example).
U-Boot's /memory updating code doesn't handle a unit address; see common/fdt_support.c fdt_fixup_memory_banks().
Linux's /memory parsing code doesn't handle a unit address, except for one PPC32 special case; see drivers/of/fdt.c early_init_dt_scan_memory().
(Which makes me wonder how any of the systems which do have /memory at nnn rather than plain /memory actual work...)
PATCH 1/1 mips: fix DTC unit warnings
Quoted 55 lines · Stephen Warren
Quoted 54 lines · Tom Rini
Quoted 16 lines · Stephen Warren
Quoted 6 lines · Tom Rini
Quoted 5 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertyNote that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/mips/dts/pic32mzda.dtsi +0
-0Quoted 10 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi line 31
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi +1
-1cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc";Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
So the likely answer here is that the dtsi is wrong and needs to be fixed rather than just dropping @0.
Quoted 22 lines
Quoted 10 lines
Quoted 10 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 3 lines
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
I vaguely recall seeing discussion that /memory *would* be special-cased, but as you point out obviously isn't yet. I doubt it's anything to do with U-Boot itself, but rather the more general problem that if /memory at NNNN changes name based on what RAM is present, it's not possible for any bootloader to update it in a sane way (what node name do you search for to edit), or any OS to read it in a sane way (what node name do you search for to find out where memory is). As such, a special case is logically required.
Quoted 4 lines
Quoted 2 lines
Right, makes sense. But it'll also have to handle that today (nearly) everyone is /memory at NNNN.
Nodes without a unit address are far more common currently, on ARM at least:
Brain fart, you are correct. I git grepped both memory and cpu and then got 'em backwards in my reply.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160415/b67551b7/attachment.sig>
PATCH 1/1 mips: fix DTC unit warnings
In reply to Stephen WarrenHello Stephen,
Am 15.04.2016 um 18:56 schrieb Stephen Warren:
Quoted 15 lines · Tom Rini
Quoted 6 lines · Andreas F?rber
Quoted 5 lines
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertyNote that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/mips/dts/pic32mzda.dtsi +0
-0
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/dts/pic32mzda.dtsi line 31
Quoted 4 lines
cpus {arch/mips/dts/pic32mzda.dtsi +1
-1- cpu at 0 { + cpu { compatible = "mips,mips14kc";Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
Yes, everywhere I removed the @address I hope to get a response with the correct reg value. It is not possible for me to look through all the RMs ... nor test the new DTS on real boards ... and nobody has volunteered to fix the warnings, so I posted this "fixup" patch ...
So, lets discuss the correct fix ...
Hmm... is there a valid reg property for cpu ? Or can we add a dummy one?
Or may we do a "cpu at 0" -> "cpu0"?
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 4 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
If that is untrue, please someone object on the Linux mailing lists.
Quoted 8 lines
Quoted 1 line
Uh, what? From dtc:
I vaguely recall seeing discussion that /memory *would* be special-cased, but as you point out obviously isn't yet. I doubt it's anything to do with U-Boot itself, but rather the more general problem that if /memory at NNNN changes name based on what RAM is present, it's not possible for any bootloader to update it in a sane way (what node name do you search for to edit), or any OS to read it in a sane way (what node name do you search for to find out where memory is). As such, a special case is logically required.
Hmm.. dummy question ... why is:
memory: memory at address {
not possible?
Quoted 28 lines
Quoted 28 lines
commit
c9d9121683b35281239305e15adddfff2b462cf9Author: Stephen Warren <[email protected]> Date: Fri Feb 19 15:59:29 2016 +1100Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any node that has a reg property must include a unit address in its name with value matching the first entry in its reg property. Conversely, if a node does not have a reg property, the node name must not include a unit address. Also allow ranges property as it is deemed valid, but ePAPR is not clear about it.
Implement a check for this. The code doesn't validate the format of the unit address; ePAPR implies this may vary from (containing bus) binding to binding, so doing so would be much more complex.
Signed-off-by Stephen Warren <[email protected]>[robh: also allow non-empty ranges]Signed-off-by Rob Herring <[email protected]>[moved new test in check_table]Signed-off-by David Gibson <[email protected]>That's where that warning comes from.
But some real quick grepping makes it seem like the cpu at 0 error is also a sign of a bigger problem in the dts file
Quoted 6 lines
Quoted 3 lines
But I would suggest that whomever is making special case warnings for U-Boot bring that up on the U-Boot mailing list or otherwise ask? We're not a black box...
Equally though, anyone working on DT in U-Boot should be hanging out on the device tree mailing list, and getting actively involved in discussions, rather than hiding here.
Hmm... hidding is maybe the wrong definition ... instead I would call it "stack overflow" ... I try to follow device tree mailing list too, but also U-Boot, lkml, linux-mtd, ... and beside of this, I have also to work
so, yes I miss some(a lot currently) threads ... so, sorry for poping this thread up, but I want to get rid of this warnings ...
bye,
Heiko
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
PATCH 1/1 mips: fix DTC unit warnings
Quoted 23 lines · Heiko Schocher
Hello Stephen,
Am 15.04.2016 um 18:56 schrieb Stephen Warren:
Quoted 20 lines · Tom Rini
Quoted 6 lines · Andreas F?rber
Quoted 5 lines
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Review
Quoted 4 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertyNote that I am quite out-of-the-loop on these warning. I wrote the dtc patch that triggers them years ago, but it's only recently been applied due to Rob's efforts. I'm at most tangentially aware of the discussions surrounding applying it now.
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
arch/mips/dts/pic32mzda.dtsi +1
-1cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc";
Quoted 8 lines
Quoted 3 lines
Surely the correct fix is to add a reg property? (Of course, this depends on the binding definition; for ARM my assertion would certainly be true). If not, what does MIPS do about SMP? Even if you write, say, 4 nodes with name "cpu" they'll all become the same single node in the DTB.
Yes, everywhere I removed the @address I hope to get a response with the correct reg value. It is not possible for me to look through all the RMs ... nor test the new DTS on real boards ... and nobody has volunteered to fix the warnings, so I posted this "fixup" patch ...
Yes, we need to, but this isn't strictly a U-Boot problem, so this is by and large the wrong place to start with these patches.
Quoted 5 lines
So, lets discuss the correct fix ...
Hmm... is there a valid reg property for cpu ? Or can we add a dummy one?
Or may we do a "cpu at 0" -> "cpu0"?
No, in this case MIPS needs to update their skeleton to match the normal CPU binding.
[snip]
Quoted 10 lines
Quoted 2 lines
Equally though, anyone working on DT in U-Boot should be hanging out on the device tree mailing list, and getting actively involved in discussions, rather than hiding here.
Hmm... hidding is maybe the wrong definition ... instead I would call it "stack overflow" ... I try to follow device tree mailing list too, but also U-Boot, lkml, linux-mtd, ... and beside of this, I have also to work
so, yes I miss some(a lot currently) threads ... so, sorry for poping this thread up, but I want to get rid of this warnings ...
Well, sorry, but we're not going to address these warnings any time soon, by and large. The vast majority of these are in DT files that we inherit, almost entirely, from the kernel. The ones that we don't (ie most of x86) we should only update to fix this warning once everyone else agrees on the correct new style. Or if they already have, we need to do it that way.
You may wish to have travis-ci stuff pin down to an older DTC version for a while, to cut down on noise.
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160418/7e219a42/attachment.sig>
PATCH 1/1 mips: fix DTC unit warnings
In reply to Tom RiniAm Freitag, 15. April 2016, 12:30:58 schrieb Tom Rini:
Quoted 82 lines · Andreas F?rber
Quoted 60 lines
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Quoted 47 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask+Warning (
unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
This warnings pop up with the DTC compiler:$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu {arch/mips/dts/pic32mzda.dtsi +0
-0compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +0
-0arch/mips/dts/skeleton.dtsi line 20
Quoted 6 lines
arch/mips/dts/skeleton.dtsi +1
-1@@ -16,7 +16,7 @@ aliases { }; - memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
Quoted 1 line
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
commit
c9d9121683b35281239305e15adddfff2b462cf9Author: Stephen Warren <[email protected]> Date: Fri Feb 19 15:59:29 2016 +1100Warn on node name unit-address presence/absence mismatch
ePAPR 1.1 section 2.2.1.1 "Node Name Requirements" specifies that any node that has a reg property must include a unit address in its name with value matching the first entry in its reg property. Conversely, if a node does not have a reg property, the node name must not include a unit address. Also allow ranges property as it is deemed valid, but
ePAPR is not clear about it.Implement a check for this. The code doesn't validate the format of the unit address; ePAPR implies this may vary from (containing bus) binding to binding, so doing so would be much more complex.
Quoted 7 lines
Signed-off-by Stephen Warren <[email protected]>[robh: also allow non-empty ranges]Signed-off-by Rob Herring <[email protected]>[moved new test in check_table]Signed-off-by David Gibson <[email protected]>That's where that warning comes from.
and that is supposed to get a special case for memory. On the kernel variant of dtc the change got deactivated again and will only trigger the warnings with a special command currently.
Also in another thread [0] on the arm-kernel-list Rob Herring explicitly stated:
Quoted 2 lines
Quoted 2 lines
This has come up before and been beaten to death. Bottom line is plain "memory" is allowed, and I plan to add that exception to dtc."
And as stated there as well, memory at 0 is not correct in all cases, as it would need to be memory at baseaddress, so for example on Rockchip
- memory at 0 for the rk3288
- memory at 60000000 for rk3188 and other A9s
So it's definitly not suitable for a general node in that skeleton,dtsi
Heiko
PATCH 1/1 mips: fix DTC unit warnings
In reply to Andreas FärberQuoted 44 lines · Andreas F?rber
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
Quoted 43 lines
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>---
This warnings pop up with the DTC compiler:$ /tmp/dtc/dtc -v Version: DTC 1.4.1-gbeef80b8This fixes the compile warnings for:
https://travis-ci.org/hsdenx/u-boot/jobs/123254184see:
https://travis-ci.org/hsdenx/u-boot/jobs/123281033arch/mips/dts/pic32mzda.dtsi | 2 +- arch/mips/dts/skeleton.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)arch/mips/dts/pic32mzda.dtsi +1
-1@@ -27,7 +27,7 @@ }; cpus { - cpu at 0 { + cpu { compatible = "mips,mips14kc"; }; };arch/mips/dts/skeleton.dtsi +0
-0@@ -16,7 +16,7 @@ aliases { };
Quoted 8 lines
arch/mips/dts/skeleton.dtsi line 19
Quoted 2 lines
arch/mips/dts/skeleton.dtsi +1
-1- memory { + memory at 0 {I have just been told on linux-rockchip mailing list that such a change should not be done as /memory is being special-cased in dtc warnings for the benefit of U-Boot. Supposedly U-Boot cannot handle updating memory size on /memory at 0.
If that is untrue, please someone object on the Linux mailing lists.
Interestingly MIPS arch does not update size on /memory node during bootm. Either we can fix that in arch/mips/ or all boards have to implement board specific ft_board_setup() to address this. Shortly you'll see a patch.
In PIC32 boards(may be in some other boards as well) embedded dts is used for U-Boot and for Linux full dts is downloaded from external media. And external version has updated memory reg=<> property so problem due to '/memory at 0' fix is not seen.
Quoted 7 lines
Regards,
AndreasQuoted 3 lines
arch/mips/dts/skeleton.dtsi +0
-0device_type = "memory"; reg = <0 0>; };
PATCH 1/1 mips: fix DTC unit warnings
In reply to Heiko SchocherQuoted 6 lines · Heiko Schocher
Fix following warnings for all mips based boards:
mips: + pic32mzdask(quoted diff) +2
-0+Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name +Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg propertySigned-off-by Heiko Schocher <[email protected]>
This just isn't right as-is (that cpu one is wrong, MIPS cannot make up a different binding from the right of the arches).
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160418/f0eecc68/attachment.sig>