On Fri, Apr 15, 2016 at 05:23:54PM +0200, Andreas Färber wrote:
Am 15.04.2016 um 12:59 schrieb Heiko Schocher:
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@0 has a unit name, but no reg property
Signed-off-by: Heiko Schocher hs@denx.de
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(-)
diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi index 8a554f9..791c364 100644 --- a/arch/mips/dts/pic32mzda.dtsi +++ b/arch/mips/dts/pic32mzda.dtsi @@ -27,7 +27,7 @@ };
cpus {
cpu@0 {
cpu { compatible = "mips,mips14kc";diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi index 24ee6c3..643996c 100644 --- a/arch/mips/dts/skeleton.dtsi +++ b/arch/mips/dts/skeleton.dtsi @@ -16,7 +16,7 @@ aliases { };
- memory {
- memory@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@0.
If that is untrue, please someone object on the Linux mailing lists.
Uh, what? From dtc:
commit c9d9121683b35281239305e15adddfff2b462cf9 Author: Stephen Warren swarren@nvidia.com 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.
Signed-off-by: Stephen Warren swarren@nvidia.com [robh: also allow non-empty ranges] Signed-off-by: Rob Herring robh@kernel.org [moved new test in check_table] Signed-off-by: David Gibson david@gibson.dropbear.id.au
That's where that warning comes from.
But some real quick grepping makes it seem like the cpu@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...