cache settings for ltib colilo and kernel

[Dietrich]

This message contains an entire topic ported from the WildRice - Coldfire forum.  Freescale has received the approval from the WildRice administrator on seeding the Freescale forum with messages.  The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value as you search for answers to your questions.  Freescale assumes no responsibility whatsoever with respect to Posted Material.  For additional information, please see the Terms of Use - Message Boards and Community Forums.  Thank You and Enjoy the Forum!

---

Dec 1, 2005, 6:07 PM

Post #1 of 3 (31 views)
Copy Shortcut
 [ColdFire] cache settings for ltib colilo and kernel  Can't Post 

--------------------------------------------------------------------------------
 
I'm bringing up a custom 5472 board using the LTIB package
(ltib-rigoletto-20050802) with Linux kernel version 2.6.10, and I have
some questions about the cache settings for colilo and the kernel.

First, in colilo's arch/5475/cache.S, there is the following code for
the enableCache function:

move.l #0x01040100, %d0 /* Invalidate whole cache */
movec %d0,%CACR
nop

move.l #0x0000e400, %d0 /* setup ACR0..ACR3 */
movec %d0, %ITT0 /* ACR0 */
movec %d0, %DTT0 /* ACR2 */
move.l #0, %d0
movec %d0, %ITT1 /* ACR1 */
movec %d0, %DTT1 /* ACR3 */

/* Enable cache */
move.l #0xa4098400, %d0 /* Write buffer, dflt precise */
movec %d0,%CACR
nop
rts

I made a dummy loop in colilo that just sits and does nops and placed it
in the code after colilo copies itself to SDRAM and finishes its other
initializations. While it was running, I looked at the SDRAM chip
select and noticed there were a lot of accesses happening. I was able
to fix this by changing the ACR0 and ACR3 values to 0x0003e000 instead
of 0x0000e400. After making this change, I noticed that the SDRAM chip
select activity was reduced to exactly what I expected for automatic
refresh and no other activity. I also noticed that the time required to
inflate the kernel image went from minutes to seconds.

Does anyone have any comments on this? Does this seem like a reasonable
change?

My next question has to do with the cache settings in the kernel's
arch/m68k/coldfire/head.S cache settings. Shortly after __start and
before all the mmu_map calls, there is the following code:

move.l #0xe000c040, %d0
movec %d0, %itt0

My concern here is that the kernel has overwritten ACR0 that was setup
by colilo for caching SDRAM. Wouldn't it be better for the kernel to
set ACR2 here, like this:

move.l #0xe000c040, %d0
movec %d0, %itt1

What do you think about this? Was the intent to overwrite the ACR0
value set by colilo, or is this a bug?

Finally, in the kernel's include/asm-m68k/cfcache.h file, there is the
following definition, which is the value written to the CACR register:

#define CACHE_INITIAL_MODE (CF_CACR_DEC+CF_CACR_BEC+CF_CACR_IEC
+CF_CACR_EUSP)

It seems to me that the IDCM bit needs to be set, like this:

#define CACHE_INITIAL_MODE (CF_CACR_DEC+CF_CACR_BEC+CF_CACR_IEC
+CF_CACR_IDCM+CF_CACR_EUSP)

Without the IDCM bit set, all accesses other than 0xe0000000 will be
cached. That would probably be bad for things like peripherals on flex
bus, etc. I notice that the kernel sets MBAR to 0xe0000000. I wonder
if the 0xe000c040 value was written to ACR0 in order to prevent caching
of internal peripherals, when the better solution may have been to set
the IDCM bit in the CACR. Any thoughts on this?

If anyone could offer some insight on these issues, I would greatly
appreciate it. This is my first experience bringing up Linux on an
embedded system, and I still haven't gotten over the learning curve yet.

Thanks,
Steve

--------------------------------------------------------------------

Dec 1, 2005, 7:43 PM

Post #2 of 3 (31 views)
Copy Shortcut
 Re: [ColdFire] cache settings for ltib colilo and kernel [In reply to]  Can't Post 

--------------------------------------------------------------------------------
 
 
>My next question has to do with the cache settings in the kernel's
>arch/m68k/coldfire/head.S cache settings. Shortly after __start and
>before all the mmu_map calls, there is the following code:
>
> move.l #0xe000c040, %d0
> movec %d0, %itt0
>
>My concern here is that the kernel has overwritten ACR0 that was setup
>by colilo for caching SDRAM. Wouldn't it be better for the kernel to
>set ACR2 here, like this:
>
> move.l #0xe000c040, %d0
> movec %d0, %itt1
>
>What do you think about this? Was the intent to overwrite the ACR0
>value set by colilo, or is this a bug?

It is intended to overwrite %acr0 (yes, the use of %itt0 is a bug, I
have a patch for binutils that I need to find time to test/submit on
the mainline FSF sources).

The reason is that we don't want to cache MBAR where the internal
peripherals are, and when the kernel turns on the MMU, use the MMU
bits to specify whether the page is cached or not.

>Without the IDCM bit set, all accesses other than 0xe0000000 will be
>cached. That would probably be bad for things like peripherals on flex
>bus, etc. I notice that the kernel sets MBAR to 0xe0000000. I wonder
>if the 0xe000c040 value was written to ACR0 in order to prevent caching
>of internal peripherals, when the better solution may have been to set
>the IDCM bit in the CACR. Any thoughts on this?

IDCM is for instruction default cache modes, has nothing to do with
data default cache modes(DDCM) which is set to 0x2 which the default
mode to be cached. Remember that those apply for non-MMU accesses, and
are when the MMU is on are ignored in favor of the CM field in the MMU
TLB entry.

An __ioremap_nocache() call to map an i/o space sets up page table
entries that have CM bits of 0x2 which indicates that the page is
non-cachable precise. So an access to the memory pointed at by what
iomap_nocache() returns causes a TLB miss which sets up a TLB entry
for the access which has the CM bits set to 0x2 instead of the usual
copyback value of 0x0.

--
Peter Barada

--------------------------------------------------------------------

Dec 2, 2005, 9:59 AM

Post #3 of 3 (31 views)
Copy Shortcut
 Re: [ColdFire] cache settings for ltib colilo and kernel [In reply to]  Can't Post 

--------------------------------------------------------------------------------
 
Peter,

Thanks for the explanation. I think I'm getting a better understanding
of it now. I had forgotten to consider the caching that is being setup
by the MMU.

-Steve

On Thu, 2005-12-01 at 22:43 -0500, Peter Barada wrote:
> >My next question has to do with the cache settings in the kernel's
> >arch/m68k/coldfire/head.S cache settings. Shortly after __start and
> >before all the mmu_map calls, there is the following code:
> >
> > move.l #0xe000c040, %d0
> > movec %d0, %itt0
> >
> >My concern here is that the kernel has overwritten ACR0 that was setup
> >by colilo for caching SDRAM. Wouldn't it be better for the kernel to
> >set ACR2 here, like this:
> >
> > move.l #0xe000c040, %d0
> > movec %d0, %itt1
> >
> >What do you think about this? Was the intent to overwrite the ACR0
> >value set by colilo, or is this a bug?
>
> It is intended to overwrite %acr0 (yes, the use of %itt0 is a bug, I
> have a patch for binutils that I need to find time to test/submit on
> the mainline FSF sources).
>
> The reason is that we don't want to cache MBAR where the internal
> peripherals are, and when the kernel turns on the MMU, use the MMU
> bits to specify whether the page is cached or not.
>
> >Without the IDCM bit set, all accesses other than 0xe0000000 will be
> >cached. That would probably be bad for things like peripherals on flex
> >bus, etc. I notice that the kernel sets MBAR to 0xe0000000. I wonder
> >if the 0xe000c040 value was written to ACR0 in order to prevent caching
> >of internal peripherals, when the better solution may have been to set
> >the IDCM bit in the CACR. Any thoughts on this?
>
> IDCM is for instruction default cache modes, has nothing to do with
> data default cache modes(DDCM) which is set to 0x2 which the default
> mode to be cached. Remember that those apply for non-MMU accesses, and
> are when the MMU is on are ignored in favor of the CM field in the MMU
> TLB entry.
>
> An __ioremap_nocache() call to map an i/o space sets up page table
> entries that have CM bits of 0x2 which indicates that the page is
> non-cachable precise. So an access to the memory pointed at by what
> iomap_nocache() returns causes a TLB miss which sets up a TLB entry
> for the access which has the CM bits set to 0x2 instead of the usual
> copyback value of 0x0.
>
 
 
 

Message Edited by Dietrich on 04-03-2006 11:00 AM

Message Edited by Dietrich on 04-04-2006 09:14 PM