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.
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.
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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
