On Fri, Apr 15, 2016 at 10:56:40AM -0600, Stephen Warren wrote:
> On 04/15/2016 10:30 AM, Tom Rini wrote:
> >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
>
> 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.
>
>
> >>>diff --git a/arch/mips/dts/pic32mzda.dtsi b/arch/mips/dts/pic32mzda.dtsi
>
> >>> cpus {
> >>>- cpu@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.
> >>>diff --git a/arch/mips/dts/skeleton.dtsi b/arch/mips/dts/skeleton.dtsi
>
> >>>- 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:
>
> 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@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@NNNN.
> >commit c9d9121683b35281239305e15adddfff2b462cf9
> >Author: Stephen Warren <swar...@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 <swar...@nvidia.com>
> > [robh: also allow non-empty ranges]
> > Signed-off-by: Rob Herring <r...@kernel.org>
> > [moved new test in check_table]
> > Signed-off-by: David Gibson <da...@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...
>
> 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.
--
Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
