Hi all,
On Tue, Jul 17, 2012 at 12:30:22AM +0200, Marek Vasut wrote:
Dear Dirk Behme,
On 15.07.2012 00:08, Benoît Thébaudeau wrote:
On Sat, Jul 14, 2012 at 11:28:03PM +0200, Benoît Thébaudeau wrote:
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.
That will help: http://git.denx.de/?p=u-boot/u-boot-mmc.git;a=commitdiff;h=e576bd90f94080 6b989ffd666552081f17f032c8
Are you sure that this patch does really help?
If I remember correctly (will re-check) we have this patch locally applied. But even with this patch, we have issues so that we enabled CONFIG_SYS_DCACHE_OFF, i.e. disabled the dcache.
Try using the bounce buffer as I do on mx28.
The issues we observed *without* CONFIG_SYS_DCACHE_OFF: The SD card was detected as 1-bit only (mmcinfo), while with dcache off it was used as 4-bit. Debugging this showed that wrong configuration data was read [1]. Having a fat partition on the card, mmc part/fatls etc failed, too, with cache enabled.
Ad caches -- FEC should be fixed on these platforms, USB might work, MMC should work if you use the bounce buffer. FAT should be fixed, so should be ext2
I have switched to the git head, and applied all the latest EHCI/MSC patches from u-boot-usb-next. Since then, all my MMC/EHCI/FEC i.MX DMA issues are resolved, except on i.MX35 because of a huge bug in the handling of cache range checks on ARM1136. I have just posted a patch that fixes this issue.
Best regards, Benoît