[U-Boot] i.MX dcache issues

[Stefano Babic]

On 14/07/2012 23:28, Benoît Thébaudeau wrote:
> Hi all,
> 

Hi,

> Has anyone tested i.MX25 or i.MX35 with dcache on?
> 
> I'm working with U-Boot 2012.04.01 on several custom platforms using these
> processors.
> 
> With dcache off, everything works fine, but slowly.
> 
> With dcache on, it's much faster (e.g. mtest), but it's impossible to read
> files through the eSDHC, and U-Boot hangs if trying to ping using the FEC.

This is known - the buffers must be invalidate, there is a pending patch
doing this.

> Shouldn't mtest disable dcache automatically, then set it back to its original
> state once finished? Otherwise, some of its tests to the memory may actually
> test the dcache rather than the memory chips connections.
> 
> dcache seems to be enabled for mx35pdk, but disabled for spear3, so I'm
> wondering if it has been thoroughly tested on mx35pdk.

My last status is that ESDHC does not work with cache on, but support
for cache was already merged into the FEC driver.

> 
> I have added traces to arch/arm/lib/cache-cp15.c to check that the MMU is
> properly initialized with the appropriate addresses, and it is.
> 
> Defining CONFIG_SYS_CACHELINE_SIZE to 32 in the board file, which sets
> ARCH_DMA_MINALIGN to 32 instead of 64 does not worsen things (as expected with
> 32-byte cache lines).
> 
> Defining CONFIG_MMC_BOUNCE_BUFFER and/or setting the no_snoop option of the
> eSDHC driver does not change anything.

snoop is a feture of PowerQuick SOCs, it has no meaning on i.MX.

> 
> Defining DEBUG in mmc.c shows that the 1st mmc_send_cmd following the retry_scr
> label uses a cacheline-unaligned size that gets caught by the buffer bouncing
> mechanism that reallocs it for nothing since scr has already been allocated with
> a cacheline-aligned size. The requested transfer length is left unchanged by
> bouncing, but it seems normal for MMC commands, and it should not be an issue as
> long as allocated sizes are aligned.
> 
> Also, the mmc read commands to free RAM regions seem to work fine, so I'm
> wondering if this issue is not caused only by stack-allocated buffers. I'm not
> sure the data ending up in the buffers is random when there is an issue: the
> pattern f783 appears very often at the position of the expected 55aa DOS
> partition marker.
> 
> Shouldn't the MMC/eSDHC drivers flush/invalidate the dcache ranges that they use
> for DMA operations? Not doing so would explain why stack-allocated buffers are
> more affected than buffers in unused RAM areas.

Yes, and this is what the pending patch is supposed to do.

> 
> As to the FEC, dcache issues with DMA seem to have been taken care of, so I'll
> add traces to the FEC driver to see if there is any cacheline-unaligned buffer
> passed in.

Let's know what are the results here - FEC is supposed to work.

> BTW, why isn't there an enable_caches function in arch/arm/cpu/arm926ejs/cache.c
> or arch/arm/cpu/arm926ejs/cpu.c, just like in arch/arm/cpu/arm1136/cpu.c, so
> that dcache can be enabled by default if CONFIG_SYS_DCACHE_OFF isn't defined?

For all these reasons - because the drivers do not support yet cache,
cache on MX35 remains disabled. When support for cache (= buffers are
invalidate..) flows into mainline, it will be possible to activate cache
by default.

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================