139Re: Flushing the cache after turning it off
- Feb 17, 2006
--- In OKI-ARMfirstname.lastname@example.org, "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 &
> 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++)
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);
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.
- << Previous post in topic Next post in topic >>