On Sep 6, 2015 10:14 PM, "Shawn Lin" <shawn....@rock-chips.com> wrote:
>
> 在 2015/9/6 20:09, Yousong Zhou 写道:
>>
>> Hi,
>>
>> On 6 September 2015 at 08:12, Shawn Lin <shawn....@rock-chips.com> wrote:
>>>
>>> On 2015/9/5 22:58, Hans de Goede wrote:
>>>>
>>>>
>>>> Hi Shawn Lin,
>>>>
>>>> On 05-09-15 16:07, Shawn Lin wrote:
>>>>>
>>>>>
>>>>> On 2015/9/5 18:19, Yousong Zhou wrote:
>>>>>>
>>>>>>
>>>>>> A SD card with sunxi-mmc can fail with the following error message
>>>>>> (RCD for
>>>>>> response CRC error) when trying to switch to highspeed mode. Setting
>>>>>> the bus
>>>>>> clock before the access mode switch fixed it.
>>>>>
>>>>>
>>>>>
>>>>> No, that's wrong!
>>>>>
>>>>> Before this card is switched to highspeed, it works under
>>>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before you
>>>>> notify sd cards to run into highspeed mode?
>>>>>
>>>>> Althought it works for this card, this patch will not please the other
>>>>> cards that they might not reply CMDs any longer including the
>>>>> following CMD6.
>>>>
>>>>
>>>>
>>>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>>>> take this
>>>> to the mmc list.
>>>>
>>>> So if this is not the proper fix for the problem that Yousong Zhou is
>>>> seeing, then
>>>> what might be the proper fix ?
>>>>
>>>
>>> From my knowledge of mmc, there hadn't have a way to deal with this
"broken"
>>> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec
sometimes,
>>> but at least we shouldn't violate it.
>>>
>>
>> Maybe the fix is anti-spec. But the fact is that the card works on
>> many other platforms with the builtin card reader (not through an USB
>> adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>>
>>>> Could it be that the sunxi-mmc is doing some things in the wrong order
>>>> when
>>>> changing the clock, or is this all under control of the mmc core ?
>>>>
>>>
>>> all of this is under control of the mmc core.
>>> So if Yongsong does want this card to work for any linux-based mmc
stack, I
>>> guess something like that should be "better"?
>>>
>>> if (switch to HS fail) {
>>> set_bus_clk
>>> goto retry switch to HS
>>> }
>>>
>>> BUT...I admit it seems strange as well.
>>>
>>
>> The SD Specification (simplified version) says "If CRC error occurs on
>> the status data, the host should issue a power cycle.", so I guess the
>> above approach is anti-spec in some way :)
>>
>
> Right，I was guessing that way from your intention.
>
>
>> In case it may help debug this problem, I'd like to add that the card
>> previously worked fine with U-Boot before commit [1]. This can also
>> be confirmed by Debian Jessie installer image with which the old
>> U-Boot there worked fine while the kernel (3.16) did not.
>>
>> [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
>>
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
>>
>
> Interesting... but that at least prove your patch is a workaround but not
find the root cause.
>
> Anyway, look into commit-sha [1], can you have a test by restoring
mod-clk and clock sampling phases before jump to kernel.
>
Maybe my statement about U-Boot commit [1] above was a little ambiguous,
sorry. I meant to say that with that commit applied, U-Boot failed
initialising the card the same way as the kernel, i.e. response crc error.
The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened. However after that the
3.16 kernel failed initialising the card.
So, with commit [1], U-Boot failed right away without any chance at all
jumping to kernel.
OpenWrt ticket 20387 has more info about the U-Boot failure.
https://dev.openwrt.org/ticket/20387
Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases". Never played with such things before :)
> I happended to fix some problems which seems *similar* to yours(but I'm
not sure just from commit[1]'s msg):
>
> https://patchwork.kernel.org/patch/7119661/
>
>> Cheers
>>
>> yousong
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
> --
> You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
