Right then - replying to myself, here's what fixed the problem for me:
1. Decided to leave the locking as it was
CON_WAY0 | CON_LOAD | CON_LOCK0
CON_WAY1 | CON_LOAD | CON_LOCK1
CON_WAY2 | CON_LOAD | CON_LOCK2
CON_WAY3 | CON_LOAD | CON_LOCK3
there are 4 ways, but only up to 3 can be locked (the defines are
slightly confusingly named) - this has the effect of setting the nth
way to be in load mode, and the previous n-1 ways are locked:
Loading way 0 => no ways locked obviously!
Loading way 1 => way 0 is now locked
Loading way 2 => way 0 and 1 now locked
Loading way 3 => way 0 and 1 and 2 now locked
Way 3 gets confusing since I guess either the loaded 2k of dummy data
or the cache flushing code could end up in the cache, but as long as
we load 2k of something and pending writes will be forced out.
When reenabling the cache all ways are unlocked anyway, you may need
to think more if you're selectively flushing just some of the cached
regions (in my code I have the SDRAM and ROM cached, but only ever
have both or neither cached, not one or the other).
2. Tried with and without the FLUSH_FLUSH write
I'm with Ken here that it should be in there in his example code (as
I also lock as described in (1) above, it's not really essential for
If you're flushing when selectively disabling banks, it would need a
FLUSH_FLUSH, but for me globally disabling it there's little point
wasting 128 cycles since I do a FLUSH_FLUSH when reenabling the cache
3. And the magic change was...
Neither (1) nor (2) actually made any difference. The difference was
to use a bank for the dummy read which is currently marked as
cacheable and a section of it which would never have been seen before
by the cache.
Previously I'd just been using somewhere (64k AND NOT 0x1FFF) away
from the cache flush loop, but as there's about 100k of code I would
have visited some of those locations already.
Fortunately, as the code is in the internal ROM, and the ROM is
marked as cacheable, I can simply use the top half of bank 25
(normally for external flash which is unused).
Previously my test would survive about 5s before bailing out with an
abort on data transfer (LDMIA'ing from a dodgy address), but has been
running all night,
--- In OKI-ARMfirstname.lastname@example.org, "rsprowson" <news@...> wrote:
> --- In OKI-ARMemail@example.com, "kendwyer" <kendwyer@> wrote:
> > Hi,
> > Note the following: "Since the CPU will be made to wait until the
> cache memory initialization has been completed. The instruction
> > of writing to the FLUSH register will take about 128 instruction
> > cycles."
> Though equally 9.2.1 says "A locked way will not be flushed even
> a flushing operation is made using the FLUSH register.", which is
> I queried it. I interpret the FLUSH register as only being useful
> initialisation, not when disabling, though that's open to Oki's
> Quick question: in your test code you have
> CACHE_CON_WAYn | CACHE_CON_LOAD | CACHE_CON_LOCK0 (for n=0 to 3)
> whereas I have
> CACHE_CON_WAYn | CACHE_CON_LOAD | CACHE_CON_LOCKn (for n=0 to 3)
> was that just a copy and paste error?
> Cor this is turning out to be more of a headache than I'd thought!