Skip to contentSkip to conversation

dtc: Empty ranges property: #cells-size warning

DISCUSSION Stefan Roese 3 participants 4 messages Oct 21, 2009 – Oct 22, 2009 3 messages not in the archive

lore
Share & tools
lore
#0 lore raw

Hi,

when changing #cells-size from 1 to 2 in the root node (to support >= 4GB of RAM in katmai.dts) I get the following warning:

Warning (ranges_format): /plb has empty "ranges" property but its #size-cells
(1) differs from / (2)

I could change #cells-size to 2 in the plb node as well. But this not really what I want, because of it's child nodes.

So my questions is: How can I solve this problem? Perhaps this warning should be removed from dtc?

Thanks.

Cheers,
Stefan

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 2 lines

when changing #cells-size from 1 to 2 in the root node (to support >= 4GB of

You mean "#size-cells".

Quoted 6 lines

RAM in katmai.dts) I get the following warning:

Warning (ranges_format): /plb has empty "ranges" property but its #size-cells
(1) differs from / (2)

Quoted 7 lines

I could change #cells-size to 2 in the plb node as well. But this not really
what I want, because of it's child nodes.

So my questions is: How can I solve this problem? Perhaps this warning should
be removed from dtc?

No, the warning is correct, and your device tree is in error.

An empty "ranges" property means that the child address space is identical to the parent address space, which isn't the case here.

You should resolve this by using a non-empty "ranges" property, instead. If e.g. the address space is 1GB, and located at 0, you would do

< 0 0 0 0x40000000 >
(child) (parent) (size)

Segher

A message that is not in the archive (sent off-list or not yet received): 54889.84.105.60.153.1256143282.squirrel-JorI+TVEvZrY24RiXHRV3ti2O/[email protected]

#4 lore raw
Quoted 24 lines · Segher Boessenkool
Quoted 2 lines

when changing #cells-size from 1 to 2 in the root node (to support >= 4GB of

You mean "#size-cells".

Quoted 6 lines

RAM in katmai.dts) I get the following warning:

Warning (ranges_format): /plb has empty "ranges" property but its #size-cells
(1) differs from / (2)

Quoted 7 lines

I could change #cells-size to 2 in the plb node as well. But this not really
what I want, because of it's child nodes.

So my questions is: How can I solve this problem? Perhaps this warning should
be removed from dtc?

No, the warning is correct, and your device tree is in error.

An empty "ranges" property means that the child address space is identical to the parent address space, which isn't the case here.

Quoted 6 lines

You should resolve this by using a non-empty "ranges" property, instead. If e.g. the address space is 1GB, and located at 0, you would do

   < 0    0 0    0x40000000 >

(child) (parent) (size)

Exactly. An empty ranges property makes no sense if the parent and child address spaces aren't identical. You need an explicit ranges property to show how the child address space is embedded in the parent's.

Signature · 4 lines
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw
Quoted 9 lines · On Thursday 22 October 2009 00:04:13 David Gibson wrote:
Quoted 9 lines

No, the warning is correct, and your device tree is in error.

An empty "ranges" property means that the child address space is identical to the parent address space, which isn't the case here.

You should resolve this by using a non-empty "ranges" property, instead. If e.g. the address space is 1GB, and located at 0, you would do

Quoted 7 lines
Quoted 2 lines
   < 0    0 0    0x40000000 >

(child) (parent) (size)

Exactly. An empty ranges property makes no sense if the parent and child address spaces aren't identical. You need an explicit ranges property to show how the child address space is embedded in the parent's.

OK, thanks for making this clear.

Cheers,
Stefan