[U-Boot-Users] 83xx address translation: is it really necessary?

[U-Boot-Users] 83xx address translation: is it really necessary?

[Jeff Mann]

>I'm adding support for a new 83xx board, the 8349E-mITX.  For some
reason, turning on address translation causes the board to halt.

>enable_addr_trans:
>	/* enable address translation */
>	mfmsr	r5
>	ori	r5, r5, (MSR_IR | MSR_DR)
>	mtmsr	r5
>	isync
>	blr

>As soon as the mtmsr is executed, everything stops.

I also have this problem. Skipping address translation solves this
problem. I also wonder, "why do we enable address translation at all?"\

-J.Mann

[U-Boot-Users] 83xx address translation: is it really necessary?

[Kumar Gala]

On Aug 7, 2006, at 10:28 AM, Jeff Mann wrote:

>> I'm adding support for a new 83xx board, the 8349E-mITX.  For some
> reason, turning on address translation causes the board to halt.
>
>> enable_addr_trans:
>> 	/* enable address translation */
>> 	mfmsr	r5
>> 	ori	r5, r5, (MSR_IR | MSR_DR)
>> 	mtmsr	r5
>> 	isync
>> 	blr
>
>> As soon as the mtmsr is executed, everything stops.
>
> I also have this problem. Skipping address translation solves this
> problem. I also wonder, "why do we enable address translation at  
> all?"\

There is a performance improvement from using address translation.   
You need to make sure you are setting up the BATs properly for your  
address map.

- kumar

[U-Boot-Users] 83xx address translation: is it really necessary?

[Timur Tabi]

Kumar Gala wrote:

> There is a performance improvement from using address translation.  

Can you explain that?  Obviously, just translating the addresses can't improve performance, especially since the translated addresses have the same numerical value, so there must be some side-effect.

 > You
> need to make sure you are setting up the BATs properly for your address 
> map.

Well, I'm using the same BATs as the 8349EMDS, so I don't know what the right BATs are.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] 83xx address translation: is it really necessary?

[Kumar Gala]

On Aug 7, 2006, at 3:39 PM, Timur Tabi wrote:

> Kumar Gala wrote:
>
>> There is a performance improvement from using address translation.
>
> Can you explain that?  Obviously, just translating the addresses  
> can't improve performance, especially since the translated  
> addresses have the same numerical value, so there must be some side- 
> effect.

If you dont do address translation you can't set the WIMG settings  
for the various regions of memory.  For example you can't mark normal  
memory as cacheable.

>> You
>> need to make sure you are setting up the BATs properly for your  
>> address
>> map.
>
> Well, I'm using the same BATs as the 8349EMDS, so I don't know what  
> the right BATs are.

Is the physical memory map the same on the ITX as it is on the 8349EMDS?

- kumar

[U-Boot-Users] 83xx address translation: is it really necessary?

[Timur Tabi]

Kumar Gala wrote:

> Is the physical memory map the same on the ITX as it is on the 8349EMDS?

Beats me.

The EMDS has this for the BATs:

#define CFG_PCI1_MEM_BASE	0x80000000
#define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
#define CFG_PCI1_MEM_SIZE	0x10000000	/* 256M */
#define CFG_PCI1_MMIO_BASE	0x90000000
#define CFG_PCI1_MMIO_PHYS	CFG_PCI1_MMIO_BASE
#define CFG_PCI1_MMIO_SIZE	0x10000000	/* 256M */
#define CFG_PCI1_IO_BASE	0x00000000
#define CFG_PCI1_IO_PHYS	0xE2000000
#define CFG_PCI1_IO_SIZE	0x00100000	/* 1M */

#define CFG_PCI2_MEM_BASE	0xA0000000
#define CFG_PCI2_MEM_PHYS	CFG_PCI2_MEM_BASE
#define CFG_PCI2_MEM_SIZE	0x10000000	/* 256M */
#define CFG_PCI2_MMIO_BASE	0xB0000000
#define CFG_PCI2_MMIO_PHYS	CFG_PCI2_MMIO_BASE
#define CFG_PCI2_MMIO_SIZE	0x10000000	/* 256M */
#define CFG_PCI2_IO_BASE	0x00000000
#define CFG_PCI2_IO_PHYS	0xE2100000
#define CFG_PCI2_IO_SIZE	0x00100000	/* 1M */

Question #1: Why is CFG_PCI1_MEM_PHYS the same as CFG_PCI1_MEM_BASE, but CFG_PCI1_IO_PHYS is not the same as CFG_PCI1_IO_BASE?

I'm porting the ITX support from an older U-Boot (1.1.3) that was written by another group.  This is what they have:

#define CFG_PCI1_MEM_BASE	0x80000000
#define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
#define CFG_PCI1_MEM_SIZE	0x20000000	/* 512M */
#define CFG_PCI1_IO_BASE	0x00000000
#define CFG_PCI1_IO_PHYS	0xe2000000
#define CFG_PCI1_IO_SIZE	0x1000000	/* 16M */

#define CFG_PCI2_MEM_BASE	0xA0000000
#define CFG_PCI2_MEM_PHYS	CFG_PCI2_MEM_BASE
#define CFG_PCI2_MEM_SIZE	0x20000000	/* 512M */
#define CFG_PCI2_IO_BASE	0x00000000
#define CFG_PCI2_IO_PHYS	0xe3000000
#define CFG_PCI2_IO_SIZE	0x1000000	/* 16M */

As you can see, some numbers are different, and some are missing.  I had to guess what value to use for CFG_PCI1_MMIO_BASE, etc.

I don't know why the PCI sizes are larger on the ITX than on the EMDS.  I have no documentation that tells me what these numbers should be.



-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] 83xx address translation: is it really necessary?

[Kumar Gala]

On Aug 7, 2006, at 5:44 PM, Timur Tabi wrote:

> Kumar Gala wrote:
>
>> Is the physical memory map the same on the ITX as it is on the  
>> 8349EMDS?
>
> Beats me.
>
> The EMDS has this for the BATs:
>
> #define CFG_PCI1_MEM_BASE	0x80000000
> #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
> #define CFG_PCI1_MEM_SIZE	0x10000000	/* 256M */
> #define CFG_PCI1_MMIO_BASE	0x90000000
> #define CFG_PCI1_MMIO_PHYS	CFG_PCI1_MMIO_BASE
> #define CFG_PCI1_MMIO_SIZE	0x10000000	/* 256M */
> #define CFG_PCI1_IO_BASE	0x00000000
> #define CFG_PCI1_IO_PHYS	0xE2000000
> #define CFG_PCI1_IO_SIZE	0x00100000	/* 1M */
>
> #define CFG_PCI2_MEM_BASE	0xA0000000
> #define CFG_PCI2_MEM_PHYS	CFG_PCI2_MEM_BASE
> #define CFG_PCI2_MEM_SIZE	0x10000000	/* 256M */
> #define CFG_PCI2_MMIO_BASE	0xB0000000
> #define CFG_PCI2_MMIO_PHYS	CFG_PCI2_MMIO_BASE
> #define CFG_PCI2_MMIO_SIZE	0x10000000	/* 256M */
> #define CFG_PCI2_IO_BASE	0x00000000
> #define CFG_PCI2_IO_PHYS	0xE2100000
> #define CFG_PCI2_IO_SIZE	0x00100000	/* 1M */
>
> Question #1: Why is CFG_PCI1_MEM_PHYS the same as  
> CFG_PCI1_MEM_BASE, but CFG_PCI1_IO_PHYS is not the same as  
> CFG_PCI1_IO_BASE?

Ask me this at lunch one day, its easier to explain in person.

> I'm porting the ITX support from an older U-Boot (1.1.3) that was  
> written by another group.  This is what they have:
>
> #define CFG_PCI1_MEM_BASE	0x80000000
> #define CFG_PCI1_MEM_PHYS	CFG_PCI1_MEM_BASE
> #define CFG_PCI1_MEM_SIZE	0x20000000	/* 512M */
> #define CFG_PCI1_IO_BASE	0x00000000
> #define CFG_PCI1_IO_PHYS	0xe2000000
> #define CFG_PCI1_IO_SIZE	0x1000000	/* 16M */
>
> #define CFG_PCI2_MEM_BASE	0xA0000000
> #define CFG_PCI2_MEM_PHYS	CFG_PCI2_MEM_BASE
> #define CFG_PCI2_MEM_SIZE	0x20000000	/* 512M */
> #define CFG_PCI2_IO_BASE	0x00000000
> #define CFG_PCI2_IO_PHYS	0xe3000000
> #define CFG_PCI2_IO_SIZE	0x1000000	/* 16M */
>
> As you can see, some numbers are different, and some are missing.   
> I had to guess what value to use for CFG_PCI1_MMIO_BASE, etc.

Its because I reworked the memory map to support both PCI Memory  
(prefetchable) and MMIO (non-prefetchable) windows.

> I don't know why the PCI sizes are larger on the ITX than on the  
> EMDS.  I have no documentation that tells me what these numbers  
> should be.

I'd rework the ITX to match the current EMDS. Also, does the ITX  
actually have PCI2 accessible or connected to anything?

- kumar

[U-Boot-Users] 83xx address translation: is it really necessary?

[Timur Tabi]

Kumar Gala wrote:
> I'd rework the ITX to match the current EMDS. Also, does the ITX 
> actually have PCI2 accessible or connected to anything?

Yes, SATA.

I finally got it working.  I had to make three changes:

1. Change CFG_INIT_RAM_ADDR from 0xe4010000 (I don't know where that number came from) to 0xFD000000, which is what the EMDS uses.

2. Change the CFG_PCIxxx constants to be the same as the EMDS.

3. Change CFG_HID2 from 0 to HID2_HBE

In other words, I am using an MPC8349ITX.h that originally worked with U-Boot 1.1.3, and all of the above constants were wrong for 1.1.4.  I need to merge in the values from the EMDS rather than keep them.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] 83xx address translation: is it really necessary?

[Timur Tabi]

I'm adding support for a new 83xx board, the 8349E-mITX.  For some reason, turning on address translation causes the board to halt.

enable_addr_trans:
	/* enable address translation */
	mfmsr	r5
	ori	r5, r5, (MSR_IR | MSR_DR)
	mtmsr	r5
	isync
	blr

As soon as the mtmsr is executed, everything stops.

So for now, I've disabled the call to enable_addr_trans().  I know I need to fix this bug, but my question is: why do we enable address translation at all?  My U-Boot works perfectly fine with it turned off, so what's the point?  U-Boot 1.1.3 didn't have this "feature".

-- 
Timur Tabi
Linux Kernel Developer @ Freescale