[U-Boot] [PATCH] mips: fix DTC unit warnings

Heiko Stübner heiko at sntech.de
Fri Apr 15 20:08:06 CEST 2016


Am Freitag, 15. April 2016, 12:30:58 schrieb Tom Rini:
> 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 at 0 has a unit name, but no reg property
> > > 
> > > Signed-off-by: Heiko Schocher <hs at 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 at 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 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.
> 
> Uh, what?  From dtc:
> 
> commit c9d9121683b35281239305e15adddfff2b462cf9
> Author: Stephen Warren <swarren at 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 at nvidia.com>
>     [robh: also allow non-empty ranges]
>     Signed-off-by: Rob Herring <robh at kernel.org>
>     [moved new test in check_table]
>     Signed-off-by: David Gibson <david at gibson.dropbear.id.au>
> 
> 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:

>> 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

[0] http://www.spinics.net/lists/arm-kernel/msg494038.html



More information about the U-Boot mailing list