Fix problem with A-Data 2GB microSD card - Revisited

Sean McNeil sean at
Sun May 11 19:28:08 CEST 2008

Andy Green wrote:
> Somebody in the thread at some point said:
> |> What happens if we ignore the timeout bit if DRDY is set?  Normally
> |> timeout is just a way to stop waiting when a transfer is not happening
> |> or something fatal happened to the card in the meanwhile.  If data does
> |> come ready, we can just use it despite it took longer than the timeout.
> | I've tried that. I end up with corrupted data.
> Whoo.
> |> It'd be a pity to force all cards down to 10MHz because of (so far) 
> this
> |> one card: the 512MB cards I got from Openmoko don't exhibit this issue
> |> for example.
> | This happens with 2 identical A-Data 2GB cards on 2 v6 phones. I agree,
> | though, and would like to get down to the bottom of this. What is
> | setting f_max doing to the lower layer? Is it causing a pause between
> | blocks? Is it programming a DMA clock?
> No it's doing something pretty mundane, setting a ceiling for the clock
> rate that will be requested of this mmc driver from the mmc layer.  It
> won't ask for faster than 10MHz with /5 when you set that, despite the
> card says it can handle faster.
> In turn this just fixes the MMC clock generated by the Glamo to the
> 10MHz requested by the MMC layer.
> And the Glamo timeout counter (max 4095 x 16 clocks) is counted out
> using this MMC clock.  Therefore when you slow the MMC clock, you allow
> more absolute time to pass before the timeout fires, which I guess is
> the magic ingredient here; the card is slow to access the last 1GB for
> some internal reason.  But we tried cranking the timeout to the max also
> and that isn't enough.
> Since I didn't see a way to identify cards that behave like this other
> than seeing them time out, the only solution that we have at the moment
> to make it happy is to crank down the clock, which is a shame.
> -Andy
I see that it sets the GLAMO_REG_CLOCK_GEN8 to a clock divisor as a base 
0. So it looks like I'm setting it to 4 in my case. If this clock 
divisor isn't base 0 but base 1 then this calculation would be off and 
that would explain it. The card could be specifying a rate of 12MHz but 
the only way we knock it down to that rate is if I set the f_max low enough.

What does the documentation say about this? What is the reference clock? 
The code assumes a 50MHz clock.

More information about the openmoko-kernel mailing list