MPC8248 poor performance

[Paul Eaton]

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.
   
  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.
   
  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 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20070130/4dbb5ddb/attachment.htm