<DIV>Thanks Kumar for your suggestion to look into the I-cache and D-cache initialization.</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>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.</DIV> <DIV> </DIV> <DIV>I don't see the sequence documented anywhere in the Freescale
documents and the trial and error method with the Abatron is getting old.</DIV> <DIV> </DIV> <DIV>Paul</DIV> <DIV><BR><BR><B><I>Kumar Gala <galak@kernel.crashing.org></I></B> wrote:</DIV> <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR>On Jan 26, 2007, at 1:42 PM, Paul Eaton wrote:<BR><BR>> Hi,<BR>><BR>> We have a custom 8248 card that we are testing.<BR>> The core is running at 400MHz and the system bus is 80Mhz (measured <BR>> and verified), 32 bit wide memory interface.<BR>> There is nothing connected to the CPM except 1 RS232 port which is <BR>> not used in our test loop.<BR>><BR>> We are running a small test C loop (with approx. 60 assembly <BR>> language instructions) at the end of u-boot as in the Hello World <BR>> example. The loop runs fine but upon closer analisis I found that <BR>> each loop takes 6uS. This averages out to 100nS/instruction = <BR>>
10MIPS = sad performance. I would have expected at least 100MIPS or <BR>> more.<BR>><BR>> I've checked the HID0 SPR register to verify that the instruction <BR>> cache is enabled.<BR>><BR>> I've also stepped thru the code to verify that the code stays <BR>> within the loop (no async branches or irqs). Looking at the adr and <BR>> data lines with an analyzer the loop appears to do the correct <BR>> amount of I/O to SDRAM but the amount of time of between SDRAM <BR>> accesses seem longer than I would expect if caching, pipelining, <BR>> snooping, etc are enabled.<BR>><BR>> Any ideas on what could be slowing the CPU down are greatly <BR>> appreciated.<BR>><BR><BR>Is the code doing any d-side access? is the d-cache enabled? How are <BR>the BATs setup for memory locations you are accessing.<BR><BR>- k<BR><BR><BR><BR></BLOCKQUOTE><BR><p> 
<hr size=1>TV dinner still cooling?<br><a href="http://us.rd.yahoo.com/evt=49979/*http://tv.yahoo.com/">Check out "Tonight's Picks"</a> on Yahoo! TV.