[U-Boot] Nokia N900 - eMMC not working after commit 02f3029f1810b99869254d0cf0a71946a008a728

[Macpaul Lin]

HI Lei Wen,

2011/11/14 Lei Wen <adrian.wenl at gmail.com>:
> Hi Macpaul,
>
>>> It seems some socs always treat cmd8 as failed...?
>>> I think it is reasonable to add a quirk configuration surround the judgement
>>> of cmd8 execution, so that even it is failed anyway, it could still go on with
>>> the following cmd sequence. If this quirk is not defined, and return behavior
>>> is still kept.
>>>
>>> What do you think for this?
>>>
>>> Thanks,
>>> Lei
>>>

For easily to discuss about this problem, I've stripped the part from
SD specification 3.0 as you mentioned.

Figure 6.1
http://i.imgur.com/bmoAX.jpg
Figure 6.2
http://i.imgur.com/7fxdx.jpg

As you can see, after the power ramp up to 74 clocks (1msec), the CMD0
can be send to the card.

So it seems your controller will do power ramp up (dynamic clock
gating?) "only after" the CMD0 has been send?
Is this correct? However, it is weird and seem not followed the specification.

Since only SD 2.0 cards can adopted with CMD8, other cards older than
SD 2.0 should treat CMD8 as timeout (I guess).
So CMD8 might be important for us to distinguish  the command sequence.
Sending CMD8 many times might really introduce problem for other cards.

> The 74 clock requirement is mentioned in both sd[1] and mmc spec[2].
> [1] page 91, section 6.4.1 power up, SD specification, part 1,
> Physical layer Simplificated Specification, version 2.0
> [2] page 54, section 7.3.1 Card reset to pre-idle state, JESD84-A44
>

> The card we met trouble on is SanDisk 8GB class4 sd card.

I don't have this card on hand. I only have Samsung and Trenscend
cards (SD2.0, SD1.10 / class4 or class10).
Is this SanDisk card also a SD 1.10 cards?

>> Add #ifdef to the code is a quick solution, but I think the we need to
>> figure out if there is other method
>> to help on 74 clock adoptable on more general case.
>>

It seems you can only add #ifdef related to your controller
(which means, do not add #ifdef as default to all other controllers.)

Have you tried to fix it with more delay after sending CMD0?
While mmc_go_idle have udelay(2000), which is 2ms, maybe writing a
wrapper (command filter) function in your driver to force it wait longer after
CMD0 has been send will be better.

However it might lead a little bit drawback for the driver performance.
But I think it won't be too much, only an "if" statement is enough.
Thus you won't affect the behavior of the mmc software stack, and also will be
more trivial to avoid adding #ifdef for special controller.

Just a suggestion, hope other people could give comments. :-)


-- 
Best regards,
Macpaul Lin