Dear eric cariat,
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.
Clock values are OK (running from 12 Mhz like the 9g45 eval kit), system running at 400 Mhz. 260416 Hz is exactly what I probe on the hardware.
Good.
Is the 9G45 (H)MCI is really identical to the 9260 MCI or are there subtle differences?
I checked the datasheet of the 9260, most register seems to be the same... I suppose you have been testing the gen_atmel_mci on the 9260 ?
Correct, on 9xe which is like 9260
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.
I added a udelay(1) and udelay(50) -> it freeze If I put a udelay(100) -> everything is OK (same effect as printf)
100us is a significant slowdown, that means 10kWords per second...
Is your data cache on?
I suppose it is enabled by default, so I added #define CONFIG_SYS_NO_CP15_CACHE in my config file -> but that still freeze
That define seems odd to me, it should be CONFIG_SYS_NO_DCACHE.
My observation are the following :
It seems that we are trying to read too many data byte : for ACMD 51 : the data reply is not a full 512 bytes data packet, but only 8 bytes len (checked with oscillo). Actually when in function mci_send_cmd() with ACMD 51, we first read the 8 "useful" byte ... then we try to "fill the rest of block" => we try to read 512 - 8 = 504 more bytes (which never comes on the DAT0 ) as there are no more data we should exit from mci_data_read() with a timeout error, but this never happen (I have to check error_flags about that)
That should not hurt, and even if, it should not depend on the speed at which we are trying to read the dummy data.
Doing a pause or printf in the while change the RXRDY flag (set to 1) and so we exit from the while without any error... ( I could not understand why ? ). It seems that when we don't read the correct number of byte, the MCI controller behave incorrectly (the status register seems to be incoherent)
This sounds very fishy to me.
Actually the driver set a block len of 512 byte only once (at initialization) in the mode register (mr) in gen_atmel_mci:mci_set_mode(). So I suppose we need to change dynamically the block len for each command (most command will use the 512 byte data block reply, but some (like ACMD51) are using a specific len -> I think we don't need to change the block len in the SDCard see comment [1] below )
<snip>
But this is not correct because it must be done only for specific command (with a fixed data size reply), Here, the "filling the rest of block" is never used again -> the code is working using mmcinfo, rescan and fatls (I d'ont need the printf or udelay anymore in the while loop), but unfortunately If I remove all other debug information -> It freeze again !
Which again suggests its not due to the way the Card is handled.
So I suppose we have to modify the code for every command -> we need to know if the data reply is a fixed size or if we have to fill the rest of loop (to fill a 512 byte data packet). But the number of "data" byte reply for each command is not really clear in the specification ("Simplified_Physical_Layer_Spec.pdf") I don't know if there are some more documentation on that ...
Google for SDCard and license restrictions...
So I 'm not sure if I'm looking in the right direction ? am I missing something about the length on data reply ? just wanted to know what you think about all that ? any other advice ?
I would think to look more in the hardware/memory/cache direction and less in the driver direction. The 9xe/9260 here runs at 200MHz and the MCI at 100 MHz, which is close to your 133MHz, and there are no such effects here whatsoever from old 1GB Cards to 32GB SDHC Cards.
Best regards, Reinhard