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