Does Dev Tree WORK with soc at y_xxxx_0000 <#address/size> = <2/1>

[Morrison, Tom]

I am sorry, but I've butted my head against a tree for over a 
week and some things just aren't making sense...especially how
the prom parse code is working to exact / resolve physical 
addresses to then ioremap...

a) Setup, I have a working MPC8548E board using 2.6.23.8 (ARCH=ppc)
   with PHYS/PTE_64BIT enabled (with the proper patches)).

b) Goal: we want to move our board to a generic 2.6.23 version that 
   Freescale has produced to support the MPC8572DS (and eventually 
   use that kernel to build our BSP for our next board).

c) I have successfully gotten to work a pure '32-bit' dev tree 
   (PHYS/PTE_64BIT not defined - and the CCSRBAR @ 0xE000_0000)
    The #address/#size <1/1> is '1' (as well as the #size is '1')

d) I have modified this dev tree to support the 36bit mode addressing
   (with the CCSRBAR and PCIExpress defined to in the last 4Gig (instead
    of the default first 4Gig - e.g.: 0xC_E000_0000)...

e) I then set the soc to have #address-cells to '2' (#size-cells is '1')
   (and added the additional values accordingly to the ranges...	

f) The prom_parse code has a problem with translating these addresses

The main question is: has anyone ever tested this with soc #address/size
being <2/1> in this fashion?

I am more than happy to send my text dev tree - but I don't want to clog
up the group with this info - if there are some fundamental questions 
to be answered before then...

Thanks in advance!

Sincerely,


Tom Morrison
Principal Software Engineer
email: tmorrison at empirix.com 
www.empirix.com