Do I need to invalidate caches before enabling (on ARMv7)?

Catalin Marinas catalin.marinas at arm.com
Mon Dec 8 03:59:09 PST 2014


On Thu, Dec 04, 2014 at 10:03:57AM +0000, Uwe Kleine-König wrote:
> Reading through ARMARM for v7-A and v7-R (ARM DDI 0406C.c, p1269) I
> found:
> 
>  ==== Behavior of the caches at reset ====
>  [...]
>  * An implementation can require the use of a specific cache
>    initialization routine to invalidate its storage array before it is
>    enabled.

Yes.

> The breakage I'm currently seeing in barebox might well be explained by
> stale I-cache entries and barebox (as of now) doesn't invalidate the
> i-cache before enabling it.

It should.

> In the paragraph that the above quote is taken from, furthermore the
> following is written:
> 
>  It is IMPLEMENTATION DEFINED whether an access can generate a cache hit
>  when the cache is disabled.
> 
> So stale entries in the cache might even hurt before the cache is
> enabled?!

The above is continued with:

  In particular, if an implementation permits cache hits when the cache
  is disabled and the cache contents are not invalidated at reset, the
  initialization routine must avoid any possibility of running from an
  uninitialized cache. It is acceptable for an initialization routine to
  require a fixed instruction sequence to be placed in a restricted
  range of memory.

So if some implementation does this, the SoC firmware must take care of
this before invoking other code like boot-loaders.

In addition, B3.2.1 VMSA behaviour when Stage 1 MMU is disabled states
that when SCTLR.I is 0, the memory accesses are non-cacheable, so such
accesses should hit in the cache (until the MMU is enabled).

Anyway, cc'ing Lorenzo for when he's back from holiday, he spent a lot
of time digging into this.

-- 
Catalin



More information about the linux-arm-kernel mailing list