[U-Boot] i.MX dcache issues

[Dirk Behme <dirk.behme@de.bosch.com>]

On 15.07.2012 16:45, Beno?t Th?baudeau wrote:
> 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.

As promised I re-checked this again: The test and issue reported 
previously in this thread were done on a plain v2012.04.01, so *without* 
  "i.MX: fsl_esdhc: allow use with cache enabled." applied.

So I can't tell if "i.MX: fsl_esdhc: allow use with cache enabled." does 
completely help or not.

Sorry for the noise, too many branches ;)

Best regards

Dirk

>>> 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
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


-- 
======================================================================
Dirk Behme                      Robert Bosch Car Multimedia GmbH
                                 CM-AI/PJ-CF32
Phone: +49 5121 49-3274         Dirk Behme
Fax:   +49 711 811 5053274      PO Box 77 77 77
mailto:dirk.behme at de.bosch.com  D-31132 Hildesheim - Germany

Bosch Group, Car Multimedia (CM)
              Automotive Navigation and Infotainment Systems (AI)
              ProJect - CoreFunctions (PJ-CF)

Robert Bosch Car Multimedia GmbH - Ein Unternehmen der Bosch Gruppe
Sitz: Hildesheim
Registergericht: Amtsgericht Hildesheim HRB 201334
Aufsichtsratsvorsitzender: Volkmar Denner
Gesch?ftsf?hrung: Uwe Thomas, Michael Bolle, Robby Drave, Egbert Hellwig
======================================================================