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