On 2015/9/6 22:51, Yousong Zhou wrote:
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 I undertand your point: Uboot w/o commit[1] + 3.16 kernel failed
that way just as Uboot w/ commit[1] + pre-3.16 kernel, right?
If that is it, could you check sunxi-platform's patches merged into
v3.16 for sure whether there is any patch do the same things just like
what commit[1] did for uboot or not?
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 :)
yousong
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/
--
Best Regards
Shawn Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
