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