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 [email protected] http://lists.openmoko.org/mailman/listinfo/community -- BlueStar88 ________________________________________________________ PGPID: 0x36150C86 PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
