Loading ...
Sorry, an error occurred while loading the content.

139Re: Flushing the cache after turning it off

Expand Messages
  • rsprowson
    Feb 17, 2006
    • 0 Attachment
      --- In OKI-ARM-mcus@yahoogroups.com, "kendwyer" <kendwyer@...> wrote:

      > > I'm noticing some slightly odd behaviour when turning the cache
      > > off
      > > which makes me suspicious that the details in the datasheet
      > > suggesting how to flush the cache aren't quite right.
      > >
      > > Anyone here had problems/successes in this area?
      > >
      > > The sequence is
      > > - power up processor, hence the cache is off
      > > - enable the cache, everything runs fine
      > > - disable the cache & flush
      > > - random skipping to wrong address

      > In your description you mention that you "disable the cache &
      > flush"...
      > Do you diable and then flush or flush and then disable?

      Flush then disable, though I realise that might sound odd.
      Essentially I used the description in 9.5.2 of the datasheet, and
      without posting the actual assembler here I do:

      Push non ATPCS preserved registers
      Disable I and F in the CPSR
      Get the address of a block of ROM which doesn't contain code
      Align the address onto an 8k boundary
      for (WAY=0; WAY<4; WAY++)
      Lock WAY
      Read the 2k into the locked WAY
      Write 0 into the CACHE register

      > Do you do a "write back" before the flush?

      Yes, as long as the above worked, which is where my suspicion lies.

      > What memory areas are cacheable?

      Bank 0 and 25 (SDRAM and ROM respectively).

      > If you do not perform a writeback then there may be cache coherency
      > issues. Also ensure that the cache is correctly initialized:
      > void init_cache(void)
      > {
      > put_wvalue(CACHE, 0);
      > put_wvalue(CON, 0);
      > put_wvalue(FLUSH, 0x1);
      > return;
      > }

      Yup, already doing that, albeit in assembler.
      Perhaps reading the 8k from a cached area is upsetting things, but I
      can't think why?

      It's doing /something/ as there are a couple of places where I need
      to be sure the value makes it back into SDRAM (incase someone resets
      the ARM at just that moment), without the flush those bits fail after
      a reset, with the flush they work as I anticipated.
    • Show all 8 messages in this topic