help with SD read/write speed

[maslovsky]

Is there something wrong? The internal storage should be based on SDRAM for SL5500.

I\'m taling about C750, which has internal storage in flash.

[Anonymous]

Yes... but... Invalidating the buffers in that way  won\'t prevent the filesystem corruption, I guess. Kernel should know that the media is changed, and shouldn\'t write it.  A single sync before the suspend may be enough. Swapping mounted media won\'t do anything good anyway. And the third thing, you get all caches reloaded on resume. You need more time to resume and loose some battery life for extra flash reads.

[ciro]

Oops, I wasn\'t logged in. Previous  post is mine.

[chyang]

What is this module\'s usage?
Does it solve the problem a little?
Thanks.

http://www.zaurususergroup.com/modules.php...download&sid=52
 MMC/SD driver  
Description: MMC/SD driver for SL5500 replacement for the original driver - sharp_mmcsd_m.o  
 
Filesize: 16.82 Kb
Added on: 29-Jan-2004
Downloads: 114
Category: patches / 5500

[ScottYelich]

thanks derekp ... I\'ll give that a try! (I did take note of it...)

Scott

[chyang]

Thanks.
I tried the module and it improved the right speed about 3 times. :-)
Original module in 3.13 ,copy a 4358462 bytes file from SDRAM to sd, the time is about 20.945s, so the write speed is about 208KB/s.
While with the module mentioned above, the time decreases to 6.393s, so the write speed is about 682KB/s. IT\'s great!!
:-)

[klrussell]

Sorry for what is probably a ridiculously basic question, but how do I install the new module on my 5500.  Do I have to recompile?  Thanks for any help.

[mike_r]

klrussell,

gunzip the file (so it looks like mmcsd.o). Copy it to /lib/modules/2.4.18-rmk7-pxa3-embedix/kernel/drivers/block. (The 2.4.18 part may be a bit different, but you get the idea.) Remove the link to sharp_mmcsd_m.o. Make a new link:

ln -s mmcsd.o sharp_mmcsd_m.o

Reboot. I\'m sure there are better ways to do this, but it worked for me.

As a test, I copied a 23 MB backup file from CF to SD. Straight 3.13 ROM, I got 150 kB/sec. Flashing in the async kernel got me to 250 kB/sec. Installing this driver got me up to 400 kB/sec (2.5 min down to 1 min). Not bad.

Mike

[Anonymous]

Something else you can try in the meantime is to mount your SD card through the loopback driver, if you have a lot of data to copy to it... i.e.:
umount /dev/mmcda1
mount -oloop,noatime,async /dev/mmcda1 /mnt/card

I am using the Cacko ROM for 5500 with homes on SD. Is there a way to use loopback on /home and /tmp to acheive faster write speeds?
From reading posts here it appears that mounting a card in asynchronous IO mode is buggy and can cause errors? It would be a bad idea to try mounting my SD card in asynch mode, then?

Thanks in advance

[Anonymous]

Well... so it\'s bad, there\'s no improvement for 5600 users.

[derekp]

I am using the Cacko ROM for 5500 with homes on SD. Is there a way to use loopback on /home and /tmp to acheive faster write speeds?
From reading posts here it appears that mounting a card in asynchronous IO mode is buggy and can cause errors? It would be a bad idea to try mounting my SD card in asynch mode, then?

Thanks in advance

Actually, I haven\'t heard any complants yet about using the async kernel.  If you saw one, let me know so I can investigate.  On the other hand, I have had some issues with suspend lockups when using /home or root on SD through the loopback driver during my tests, the way I got around it initially is to make sure that the /var/lock directy was pointing to the ramdisk (see the latest prep-home-sd_test5 script I posted for the tkc-2.0-alpha3 rom).  But, using the async kernel removes this need.
The async kernel should be a good fit for the Cacko rom with it\'s /home on SD.  Otherwise, you\'d have to rebuild your rom and change the mount line where it mounts /home to add the -o loop option to it.  I haven\'t tried that particular rom yet, so you\'d be adventering into unknown teritory.

The only issue that I can see poping up with the async kernel (or using the loopback mount for that matter) is if you pop out the SD card after writing to it without ejecting it, you could have data loss.  But otherwise you should be fine.

Try it and see, and report back the results... what\'s the worse that could happen? (famous last words) :-)

[rjd_z]

I installed the new module, and the time to copy an 18 MB file from the CF to SD improved significantly.  Throughput increased from 184 KB/sec to 408 KB/sec.

Nice job.

[albertr]

May I ask the kind soul who anonymously posted the new MMC/SD module for 5000d/5500 - what are the changes/improvement over the old one from Sharp ROM 3.x days? I see that version string didn\'t change (still says \"sharp_mmcsd 0.21 27 Sep 2002\"), but some functionality was definitely changed. Does it mean that Sharp Japan is still burning money working on improvements for old 5x00 series, or mmc/sd code was given out to third party? Please shed some light if you can... and thank you for releasing it!
Thanks,
-albertr

[Mickeyl]

I am also interested to know where that module originally comes from and how it has been created. As you may know (or not) the SD module is our #1 problem for delivering newer kernels to the Zaurus family.

[Anonymous]

I don\'t know if there any legal issues exist, so I\'ve posted the module anonimously. If you tell me that everything\'s ok, I can provide the source.
New module is 90% Sharp\'s code which was disassembled and re-assembled having some functions replaced.
Now I have approx. 50% code of the dirver converted to C.
The actual changes are:
1) Higher SPI bus freq. (I\'have no idea why original driver doesn\'t default to higher speed, although it does provide ioctl interface for changing it via /dev/sd_slotstat).
2) Different way to prefetch blocks. Original driver guarantees every eighth block to be wasted for ext2.
3) Better checksum code.
4) Original driver has hardcoded delay to wait for the card after reset. New driver attempts to detect the card multiple times increasing the delay.