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

[Morrison, Tom]

Thank you Becky (and Kumar) for all the information....and help!

To answer your questions, yes, we are using 4GB++ of memory
(and plan more in the near future). But, for the initial bring
up, I reduced the memory to 2Gig. Further, I have modified u-boot 
to NOT modify the memory reg properties (see below my snippet)...

Question: what other 'devices' does u-boot put down that I care 
about I have modified u-boot to put the correct memory structure? 

Also, are you saying there are additional patches for 
prom parsing code for this to work right - or are you 
talking about in general for the 4Gig memory??

Here is a dts snippet with some of the interesting parts:

/{	model = "MPC8548_CHEETAH";
	compatible = "MPC8548_CHEETAH";
	#address-cells = <2>;
	#size-cells = <2>;
  
 	memory { device_type = "memory";
		  reg = <0 	00000000 0 80000000>; // 2 GIG @ 0x0
         	};

	soc8548 at c6df00000 {
		#address-cells = <1>;
		#size-cells = <1>;
		#interrupt-cells = <2>;
		device_type = "soc";
		ranges = <00001000 00000000c 6df00000 000ff000>;
		reg = <0000000C 6df00000 0 001000>;	// CCSRBAR

.........
		serial at 4500 {
			device_type = "serial";
			compatible = "ns16550";
			reg = <4500 100>;	// reg base, size
			clock-frequency = <0>;	// should we fill in in
uboot?
			interrupts = <2a 2>;
			interrupt-parent = <&mpic>;
		};

		serial at 4600 {
			device_type = "serial";
			compatible = "ns16550";
			reg = <4600 100>;	// reg base, size
			clock-frequency = <0>;	// should we fill in in
uboot?
			interrupts = <2a 2>;
			interrupt-parent = <&mpic>;
		};

.........
};

Now, it looks like I am successfully parsing and translating the 
address to the expected address for the default stdout (0xc_6df0_4600)!

FWIW, I have identified that another problem with the code configuring
the CCSRBAR (and am sure I'll figure that one out soon because we have 
a working solution in the arch/ppc directory).

While I have your expert attention, I'd like to have you comment about
what potentially could be right/wrong with my definitions for the pci
express settings...

   a) Do I put those ranges in the ranges for the parent soc device
(also)?

   b) Do the below correctly define a 2 Gig PCI memory Window starting 
      at 0xC_6F00_0000 (to 0xC_EF00_0000) and PCI IO 16M Window starting
      at 0xC_6E00_0000 (to 0xC_6F00_0000)?

-----
  /* PCI Express */
  pcie at a000 {
	compatible = "fsl,mpc8548-pcie";
	device_type = "pci";
	#interrupt-cells = <1>;
	#size-cells = <2>;
	#address-cells = <3>;
	reg = <a000 1000>;
	bus-range = <0 ff>;
	ranges = <02000000 0 c 6f000000 c 6f000000 0 80000000
  		   01000000  0 00000000 0000000c 6E000000 0 01000000>;

-----

Thank you for all your help/comments...

Sincerely,

Tom Morrison
-----Original Message-----
From: Becky Bruce [mailto:becky.bruce at freescale.com] 
Sent: Monday, August 11, 2008 6:26 PM
To: Morrison, Tom
Cc: linuxppc-dev at ozlabs.org; Paul Mackerras
Subject: Re: Does Dev Tree WORK with soc at y_xxxx_0000 <#address/size> =
<2/1>


On Aug 11, 2008, at 4:37 PM, Morrison, Tom wrote:

> 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)).

So, how much RAM are you trying to use?  If it's 4GB+, there are still
patches you need that haven't been released yet but should be out in
the next week or so (I'm in the middle of pulling everything up to
top-of-tree and re-testing).

>
>
> 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...	

I'm not sure you've done the right thing here.  In many cases, you don't
actually need to modify the size/addr cells in the soc node - those just
impact the children of that node, which are relative to the parent.

You do need to change your high-level platform node at the very top of
the .dts to have the right width - here's a patch snippet from a dts I  
had
with 2/1 formatting (this is a very old .dts, so it uses the old-style
number formatting before we started using '0x'):

+       model = "MPC8641HPCN";
+       compatible = "mpc86xx";
+       #address-cells = <2>;
+       #size-cells = <1>;

and then the soc node itself was: (I located things at 0xf_xxx0_0000)

+       soc8641 at ff8000000 {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               device_type = "soc";
+               ranges = <00000000 0f f8000000 00100000>;
+               reg = <f f8000000 00001000>;    // CCSRBAR

The reg and ranges now reflect the wider parent bus address.

>
>
> 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 did that a while ago with 8641D and it worked fine at that point;
since then I've converted to a 2/2 format (which also works fine).

That, of course, assumes you've modified your bootloader to put the
devices in the right spot.  Without that, all bets are off.

Hope that helps.... if you're still confused, post some snippets of  
your dts and I'll take a look.

Cheers,
B