Qi didn't work with my uSD, workaround found

Andy Green andy at openmoko.com
Sat Dec 13 19:21:28 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:

|> I've recently bought a new uSD card, Transcend TS8GUSDHC4 (8Gb, class
|> 4) and was quite surprised it doesn't work with Qi. Having no debug
|> board, i spent considerable time debugging by trial-and-error and
|> found that Qi is able to load a kernel from it only after reboot (i
|> have another kernel in NAND, that is loaded after uSD fails) but not
|> after power-on. A strategically placed udelay solves the issue for me:

Yes, makes sense thanks.

|>         while (retries--) {
| hmmm :-/ retries==?

Different cards have different post-power dead time.  We should get a
given card to talk to us as early as possible.

|>                 udelay(100000);
|>                 udelay(100000);
|>                 udelay(100000);
| WTF? anything wrong with a single "udelay(600000);" instead of
1+1+1+3? Maybe
| even 1,000,000 for all the SD crap to come

We can solve it by just consolidate these into a 300000 delay since that
works, and double the retries counter.

Paul, do you want to resend that patch with a unified udelay() and
double retries?

| maybe we should 'scope VDD for uSD on powerup, sdclk and data on
second and
| 3rd channel?
| OTOH uSD might need some time just to init itself internally after
powerup.
| Hard to probe that.
| However I wonder what's the story with the retires. Shouldn't that
catch it?

Different cards act differently, so this code is adaptive.  It can't sit
there forever, because then an absent SD Card kill the boot, so there is
a balance.

I was talking to a guy offlist with a similar problem of a card that is
slow to talk, in that case in Linux: it needed rootdelay=1 or more for
the same reasons.

I have to say you should probably reserve your :-/ and WTF for code that
doesn't work.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklD/SgACgkQOjLpvpq7dMphYgCcDKnS7ZCVoVzu89TUPfxTy5F8
UfwAoJS0yRsOPxG6O+wWvtJ6p99GVD/I
=qqMa
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list