quoted

quoted

quoted

quoted

However, #address-cells=2, #size-cells=1 is common enough that we
really need to support that case.

On the root node?!?  Who would do such a strange thing?

Ebony, for one, it works nicely for a 32-bit system with >32-bit bus.

It means you cannot have a 4GB-or-bigger region below your
root node.  Dunno if Ebony ever needs one, for I/O mapping
perhaps?

Nope.  0-4GB is RAM, 4-8 is in-built IO, 8-12 is PCI IO, and I forget
what 12-16 is, if anything.

Let's take the first of these -- 4GB of RAM.  Not that
you'll ever see an Ebony with that much memory of course ;-)

How do you express 4GB of memory when #a=2 #s=1?  Something
like

reg = < 0 0  ffffffff   0 fffffff  1 >

and you're lucky this is actually allowed in a memory
node, some other nodes/properties won't allow you to.

Contrast this to #a=2 #s=2 where you simply say

reg = < 0 0  1 0 >

quoted

quoted

Apple G5s do it too.

And they do a an awful workaround for their memory node
because of this.

Is their any reason why you couldn't use #a=#s=2 on 32-bit
systems?  The root node is one contiguous hunk of address
space, so the biggest (theoretically) possible size is equal
to the biggest address (+1).  It's not hard to come up with
an example where you need a size of 4GB or more.

Well, yes, we could.  I believe the only reason Apple does it is to
make the tree a little more compact.

I think the main reason is that their 64-bit OF actually
is a 32-bit one with lots of weird extras tugged on ;-)

But the point is that trees are
out there with #a=2 #s=1, so the fixup code ought to be able to handle
them.

Yes of course, I'm not disagreeing there -- I'm just
saying that for boards where we do have control over
the device tree we should discourage this monstrosity :-)


Segher