From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Sun, 15 Jul 2012 16:37:06 +0200 (CEST)
Subject: [U-Boot] i.MX dcache issues
In-Reply-To: <500269A3.60105@googlemail.com>
Message-ID: <137497504.13302.1342363026154.JavaMail.root@advansee.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Sun, Jul 15, 2012 at 08:56:35AM +0200, Dirk Behme wrote:
> 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=e576bd90f940806b989ffd666552081f17f032c8
> 
> Are you sure that this patch does really help?

I meant: It's necessary, but perhaps not sufficient. I have not tested it yet.

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

It's exactly the kind of issues I currently get. Was CONFIG_MMC_BOUNCE_BUFFER
defined for your tests to make sure no unaligned buffer was used? I'll tell you
if it works better for me with this patch.

Best regards,
Beno?t