Hi,
On 04-09-15 16:24, Yousong Zhou wrote:
Hi,
On 1 September 2015 at 00:07, Hans de Goede <[email protected]> wrote:
Hi,
On 30-08-15 10:30, Yousong Zhou wrote:
Hi
In an OpenWrt ticket [1] I reported two issues encountered by 2 SD
cards of mine.
One of them failed with `error reading clusters` when reading a uImage
file of size about 2MB. This issue happened after we switch from DMA
transfer to `mmc_trans_data_by_cpu()`. It is caused by fixed 2
seconds timeout without considering the transfer size. A fixed was
just posted [2] in OpenWrt-devel list.
The other card failed at the SPL stage with `spl: mmc init failed with
error: -19`. That -19 is defined as macro TIMEOUT in U-Boot and it is
comparable to -110 in Linux kernel defined as ETIMEOUT. This problem
happened after we switch the clock divider from the
controller-internal one to mod0-clock (commit fc3a832 "sunxi: mmc:
Properly setup mod-clk and clock sampling phases"). Actually TIMEOUT
is not the root cause here. It is caused by
SUNXI_MMC_RINT_RESP_CRC_ERROR when trying to switch the card to
highspeed mode. Unfortunately I am not familiar with sunxi clock
system enough to provide a fix for this.
More details can be found in the ticket description in link [1]
[1] https://dev.openwrt.org/ticket/20387
[2] http://patchwork.ozlabs.org/patch/512163/
Thanks for the patch I've merged it into my sunxi u-boot tree,
and send a pullreq for merging it into u-boot master.
As for the other issue I've no idea what is going on there.
I just made a fix for that issue. It worked both for U-Boot and
Linux. The approach is that we change the bus frequency to 52MHz
before (instead of after) the access change. Well, the patch needs to
be applied on the core code. I am not sure of the possible side
effects on other cards...
Patch attached for both U-Boot and Linux.
Can you send the linux version upstream please?
Send it to Ulf Hansson <[email protected]> with
[email protected] and me in the Cc.
Then we can see what upstream thinks about this, this might
actually be a sunxi-mmc code bug somewhere ...
Once we've figured out what to do on the kernel side, we
can simply apply the same fix to u-boot.
Regards,
Hans
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
