[U-Boot] gen_atmel_mci freeze on at91sam9g45

[Reinhard Meyer <u-boot@emk-elektronik.de>]

Dear eric cariat,
> I'm currently working on a custom board with an at91sam9g45 : I followed the
> instruction in README.atmel_mci. In U-boot, if I use the command mmcinfo,
> the system hang. The uSD is working correctly with at91bootstrap and linux.
> In U-boot everything seems fine, the card exchange a few command and
> response, and then freeze on the command 55 51 (the first command that will
> receive some data on DAT0 ) :
> 
> U-Boot> mmcinfo
> mci: bus_hz is 133333333, setting clock 150000 Hz, block size 512
"setting clock" should read "requesting clock". 150000 is the clock a MMC card
should be inquired with. Unfortunately the minimum clock obtainable is 260416,
but that did not cause problems with SD cards so far...
> mci: setting clock 260416 Hz, block size 512
So the software sets it to the minimum-.
> mci: bus_hz is 133333333, setting clock 0 Hz, block size 512
> mci: setting clock 260416 Hz, block size 512
> mci: bus_hz is 133333333, setting clock 260416 Hz, block size 512
> mci: setting clock 260416 Hz, block size 512

First make sure the clock values are correct: Assuming the system is running
at 400MHz, this would make sense if the MCI is clocked by system clock / 3.
Then the minimum clock would indeed be 260416.

Is the 9G45 (H)MCI is really identical to the 9260 MCI or are there subtle
differences?

> But if I add some printf to debug , just after the
> mci_data_op=mci_data_read() in gen_atmel_mci, then everything is OK and I
> can now use the uSD without any problem.
> Here is where I add the printf, so uSD is correctly handled :
> 
> diff -crbN u-boot-2010.09.orig/drivers/mmc/gen_atmel_mci.c
> u-boot-2010.09/drivers/mmc/gen_atmel_mci.c
> *** u-boot-2010.09.orig/drivers/mmc/gen_atmel_mci.c    2010-09-28
> 23:20:55.000000000 +0200
> --- u-boot-2010.09/drivers/mmc/gen_atmel_mci.c    2010-12-04
> 17:52:59.092770689 +0100
> ***************
> *** 252,257 ****
> --- 252,258 ----
>               while (!status && word_count < (sys_blocksize / 4)) {
>                   status = mci_data_op(mci, &dummy,
>                       error_flags);
> +                 printf("status=%x\n",status);
>                   word_count++;
>               }
>               if (status) {
> 

Have you tested whether a udelay() serves the same purpose? It would seem that there is
an issue when mci_data_op() is called too frequently. However, quite the same code exists
a few lines above and it did not hang there.

Is your data cache on?

There are no timeouts coded in mci_data_read() and mci_data_write(), maybe it would be good
to add some...

I also cannot rule out that pre-initialisation of the MCI by the bootstrap code could leave
some registers with values that the gen_atmel_mci driver does not reset. But then, a printf
would unlikely fix the problem.

Patches are always welcome ;)

Best Regards,
Reinhard