From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Mon, 16 Jul 2012 08:13:21 +0200 Subject: [U-Boot] i.MX dcache issues In-Reply-To: <1803252839.13517.1342363559611.JavaMail.root@advansee.com> References: <1803252839.13517.1342363559611.JavaMail.root@advansee.com> Message-ID: <5003B101.9000608@de.bosch.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 ======================================================================