MPC8248 poor performance

[Kumar Gala]

On Jan 30, 2007, at 1:41 PM, Paul Eaton wrote:

> Thanks Kumar for your suggestion to look into the I-cache and D- 
> cache initialization.
>
> I verified that neither the IBAT or DBAT tables are initialized. It  
> appears this operation is not handled by u-boot but rather the OS  
> is expected to configure the cache parameters. This is a problem  
> for my application given that we don't boot an OS after u-boot  
> completes.
>
> I've attempted to poke in the values that I feel are needed for the  
> BAT registers as well as HID0 with an Abatron, but my card resets  
> when I attempt to run after the values are loaded.

Yeah, setting up BATs this way is bound to cause issues.

If you want, take a look at the 83xx code in u-boot which now uses  
BATs to improve performance (allows for proper caching, etc.).

> Would you happen to know what linux module is used to set up cache  
> parameters on a MPC8248 (8260 class) processor? I'd like to look  
> over how Linux handles it to see if I'm missing something in the  
> initialization sequence.

The caches are setup via setup_common_caches in arch/powerpc/kernel/ 
cpu_setup_6xx.S

> I don't see the sequence documented anywhere in the Freescale  
> documents and the trial and error method with the Abatron is  
> getting old.
>
> Paul

- kumar

>
> Kumar Gala <galak at kernel.crashing.org> wrote:
>
> On Jan 26, 2007, at 1:42 PM, Paul Eaton wrote:
>
> > Hi,
> >
> > We have a custom 8248 card that we are testing.
> > The core is running at 400MHz and the system bus is 80Mhz (measured
> > and verified), 32 bit wide memory interface.
> > There is nothing connected to the CPM except 1 RS232 port which is
> > not used in our test loop.
> >
> > We are running a small test C loop (with approx. 60 assembly
> > language instructions) at the end of u-boot as in the Hello World
> > example. The loop runs fine but upon closer analisis I found that
> > each loop takes 6uS. This averages out to 100nS/instruction =
> > 10MIPS = sad performance. I would have expected at least 100MIPS or
> > more.
> >
> > I've checked the HID0 SPR register to verify that the instruction
> > cache is enabled.
> >
> > I've also stepped thru the code to verify that the code stays
> > within the loop (no async branches or irqs). Looking at the adr and
> > data lines with an analyzer the loop appears to do the correct
> > amount of I/O to SDRAM but the amount of time of between SDRAM
> > accesses seem longer than I would expect if caching, pipelining,
> > snooping, etc are enabled.
> >
> > Any ideas on what could be slowing the CPU down are greatly
> > appreciated.
> >
>
> Is the code doing any d-side access? is the d-cache enabled? How are
> the BATs setup for memory locations you are accessing.
>
> - k
>
>
>
>
>
> TV dinner still cooling?
> Check out "Tonight's Picks" on Yahoo! TV.