I've upgraded to the current kernel. TTFF-issue is solved by the last
kernel-patch. Congratulations!
Now I'm testing the inteferences while accessing data from the sd-card.
On the current default clock of 16MHz I see heavy GPS-signal breach-ins
in a pulsing manner, if I do some continuous access with 'dd' to the
card. If I stop dd the perception signal stabilizes. Okay, this was to
expect.
According to the statement below, the clock rate on the SD-card side is
far above the effective data-rate on the CPU side. We do 16MHz on one
and something around 2MHz on the other. That makes no sense to me.
What about fixing the rate on the sd-card side to far lower level, not
only while ideling, even if accessing? Lets say 5MHz. Would it make any
sense and would it decrase the clock noise significally enough, to be
able to just ignore the hardware patch?
I haven't found the file to place any permanent kernel opts yet, to test
this. No grub, no lilo :-) thats beyond my knowledge about the FR
booting internals. Any hints?
Andy Green schrieb:
> Somebody in the thread at some point said:
>> | | access let me know what the max speed of the Glamo's MicroSD card
> | | controller is? looking for MB/s, or something like that.
> |
> | It's just slightly under 25MHz SD Clock, we round it up and call it 25MHz.
>> | What is that in MB/s?
>> Well, a good rule of thumb for generic 1-bit transfer is divide by 10
> for the max speed in Bytes/sec you could expect, here we have 4-bit so
> the peak raw trasfer speed is ~10MBytes/sec *BUT* after Glamo pulls the
> data from the card, we have to sit there dragging it into the CPU
> memory, on top of card latencies and command setup the speed is way
> slower, still a decent ~2MBytes/sec each way IIRC.
>> -Andy
_______________________________________________
Openmoko community mailing list
community at lists.openmoko.orghttp://lists.openmoko.org/mailman/listinfo/community
--
BlueStar88
________________________________________________________
PGPID: 0x36150C86
PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.openmoko.org/pipermail/community/attachments/20080725/731b1ef2/attachment.pgp