[U-Boot] i.MX dcache issues

[Benoît Thébaudeau]

On 15/07/2012 15:45, Stefano Babic wrote:
> 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.

I've seen it since, but it is not sufficient according to Dirk Behme.

> > 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.

OK.

> > 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.

OK. I tried it because no_snoop is set for i.MX5 boards, so I was wondering if
it was an undocumented feature of this IP.

> > 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.

OK.

> > 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.

I'll tell you.

> > 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.

OK, but there is an inconsistency in that case between i.MX25 and i.MX35: These
issues are present on both, but without CONFIG_SYS_DCACHE_OFF defined, dcache is
enabled by default on i.MX35, but not on i.MX25.

Best regards,
Benoît