Re: IO FLASH and caches

[Bart Veer <bartv at ecoscentric dot com>]

    >>> The attached patch handles the case where the CPU cannot
    >>> disable caches and needs to provide an uncached address
    >>> instead. The fix was tested with a NIOS2 CPU.
    >> 
    >> I don't think this patch is correct. In general flash should be
    >> read through the cache. Flash devices are slow and using the
    >> cache improves performance. It is the responsibility of the
    >> flash driver to ensure that stale data is evicted from the
    >> caches by calling cache control macros. In general the drivers
    >> already do this.
    >> 
    >> This patch forces uncached access for any architecture that
    >> defines CYGARC_UNCACHED_ADDRESS(). Many platforms (e.g. MIPS,
    >> PPC, ARM9) provide both cached and uncached views of memory.
    >> These architectures also provide mechanisms for flushing and
    >> invalidating the caches.

I think the patch may be fundamentally flawed.

If I understand correctly, the issue you are trying to address is that
after a flash program operation that involves bypassing the cache, the
data cache may still contain stale data from before. So you change the
verify code to look at the uncached flash contents. The problem is
that any subsequent code reading the flash may still get the stale
data from the cache.

In other words, you have not solved the problem. All that the patch
does is stop the verify code from reporting the problem.

What should happen is that the flash driver does whatever is necessary
to keep the cache and the flash contents coherent. I believe the V2
AMD and Strata drivers should do the right thing. _V2_CACHED_ONLY
should not be defined because the Nios II can bypass the cache when
manipulating flash, so _INTSCACHE_DEFAULT_END() should sync and
invalidate the data cache. When control returns to the generic flash
code all stale data should have been removed from the cache so the
verify code will see the new data.

It is possible that some of the V1 drivers get this wrong. If so, the
solution is to switch to a V2 driver.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.