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: [EMAIL PROTECTED]
www.empirix.com
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
