ons 2013-05-15 klockan 19:39 +0200 skrev Albert ARIBAUD:
I understand all this, but what I am interested in is the root issue.
IIUC, the problem is that some code is loaded in DDR, and the CPU is about to jump to it, but its instruction cache is enabled so maybe some instructions after 'go' will be (wrongly) fetched from I-cache instead of being read from DDR (and fed into I-cache).
Yes.
Nothing in this is ARMv7 specific; it could happen in an arm926ejs just as well. It could happen on any CPU with distinct, non-consistent I- and D- caches an enabled I-cache.
Correct on all accounts.
So my suggestion is to implement the icache_flush in common/bmmt_cmd.c as follows:
... /* just about to 'go' */ #if CONFIG_ARM #if CONFIG_ICACHE if (icache_status()) invalidate_icache_all(); #endif /* CONFIG_ICACHE */ #endif /* CONFIG_ARM */ /* now go */
This style is a nightmare for adding more arches needing this, but solves the problem today.
But there is no CONFIG_ICACHE. In ARM there is CONFIG_SYS_ICACHE_OFF but it's not quite the same.
From what I can tell there is no need to theck icache_status(). It's
always safe to call invalidate_icache_all().
So it's back to use the compiler define for ARMv7.
The only problem I see for now is that, while ARM has a default icache_status(), apparently the targets that need the invalidate above do not have their own version of icache_status(); they'll need to provide one for this code to work.
And also an invalidate_icache_all(). That only exists on armv7 today.
m68k have icache_invalid() which seems to be the same.
Regards Henrik