About The Cf Speed (and Sd Too)

[ldrolez]

Hi !

I've read in the PCMCIA specs that the maximum speeds are:

For 16-bit I/O Transfers (255 ns Minimum cycle)
* Byte mode: 3.92 Mbytes/sec
* Word mode: 7.84 Mbytes/sec

But in the Intel document 28000901.pdf, you can read that the maximum best case is 32Mbps with a 423ns cycle. So I don't understand... The PXA has a 2.3Mhz clock for PCMCIA instead of 4 Mhz and word transfers are impossible ?

  Ludo.

BTW, the other interesting thing in that document is that the SDIO port can go up to 78Mbps and does not share its BW with the memory bus  

PS: anyone knows if DMA is possible with PCMCIA ?

[Da_Blitz]

I have always said that the CF card was 16MB/s but i might have to check that now

sdio is nice but we are using it in mmc compatability mode at the moment

as for dma transfers i am not 100% sure, the spec itself dosent support dma until 3.0 but if you read the intel docs it says it complies to ethier 1.0 or 2.0 of the spec, 3.0 also added 66MB/s transfer speed but i am unsure if this was for ide mode only or not, but

back to dma i suppose you could dma the data so you didnt have to move each byte but have the hardware written in PIO but i think you are talking about ways for a speed increse. there are a couple of register hacks you can do to spped things up and was posted to one of the cxx00 fourms

also usb dosent share the mem bus ethier

[ldrolez]

sdio is nice but we are using it in mmc compatability mode at the moment

Not sure, since I can get 25mbit/s from my SD card and the Intel specs says that the MMC bus is limited to 19 mbits. On a PXA270, the MMC/SD controller can do 4 bits transfers, so it could be enabled in sharp drivers (but I cannot verify this since there's no open source mmc/sd driver).

hardware written in PIO but i think you are talking about ways for a speed increse. there are a couple of register hacks you can do to spped things up and was posted to one of the cxx00 fourms

Do you have any pointers ? Cannot find the post...
Anyway, increasing the CF performance will decrease the whole system performance since when a CF transfer occurs, the memory bus is "locked". So using 24Mbits of BW on the PCCard bus, leaves only 1/4 of BW usable on the memory bus (24/32). That's why screen refreshes are so slow when you run a 'dd' on the CF card or the integrated HD (VGA screen refreshes need 20% of the total bus bandwidth which is 1422Mbps with 100Mhz SDRAM). Everything is nicely explained in 28000901.pdf.

So the PCCard/CF implementation in the PXA really sucks, and all development efforts should be put in the SD slot IMHO.

Cheers,

  Ludo.

[Da_Blitz]

sorry i forgot that not every one uses a 2.6 kernel, as you can see from my tag i am running OZ so i get nice slow speeds

no actually increasing CF performance will increse general performance as the rest of the hardware dosent have to wait for the CF transaction to finish

for fast refreshes run the screen in 320x240 and place it in sram however i dont think the onboard hardware will allow you to do this and you have to reduce the overlays to 1 bit per pixel which requires kernel support, best solution is to map the lcd to sram and let it overflow into main me so that it dosent have to talk to ram for the first 256KB af data (i belive thay do this in 2.6) so you might want to revist your calculations for that one.

Your interprtation of the CF card is half correct, most embbeded cpus do cf in the same fassion due to pin consraints (remeber its an embedded cpu not a performance beast) the main performance booster i belive was removing wait states however the kernel performance can greatly help as well with things like caching and swap

in fact swap is a great way to improve performance on the sharp rom because it seems lixe there is a whole lot of extra crud that gets loded when its not needed so it gets swaped out leaving more room for cache (at least thats how i intrepret what i see) fiddling with hdparm doesnt help much at all and in fact can decrese performance

one thing that may be of intrest is the sys and proc filesystems, there are many tunable options in there that can both increase performance and battery life (eg 'laptop mode' for more battery life)

I am intrested in why you seek to make it better as there are many things you can do on a per program basis to speed it up (such as mplayer)

i will mention that the general speed and snapiness in 2.6 is an order of magnitude over 2.4, however SD development is hard as they dont offer the spec for free, i have given some infomation to kernel developers as well as some pdf's that talk about SD and SDIO and how to interface to them but they only cover about 90% of what we need so dont expect SD performance to shoot up rapidly

if you are really concened about performance for video then i would sugest a dell axim x50v with the vga out (linux boots on it nom) or perhaps go to the hardware section and make your thoghts heard on the thread i started about designing our own pda bassed on the iMX.3 from freescale

[ldrolez]

sorry i forgot that not every one uses a 2.6 kernel, as you can see from my tag i am running OZ so i get nice slow speeds

It seems that on a PXA270, you just need to set the SD_4BITS option in the MMC controller to have 4 bits transfers... Do you know if anyone has tried ? I cannot believe that we would be jailed for setting a bit in MMC controller.... Or just add the feature as a module option.

I am intrested in why you seek to make it better as there are many things you can do on a per program basis to speed it up (such as mplayer)

Because I just like playing with hardware and low level things
My current interests are:
- speeding up the CF interface (not much room here)
- playing with the SD interface. It seems that DMA is already implemented (on a 2.6, don't know on a 2.4), and 4 bits transfers could be enabled on a PXA270.
- improving the FB speed by using the DMA for bitblt (already done ?)

them but they only cover about 90% of what we need so dont expect SD performance to shoot up rapidly

I've seen that you can now buy 'MMC plus' cards that can do 4 bits and 8 bits transfers. I wonder if MMC+ 4bits is equivalent to SD 4bits and if the PXA can use them in that mode ? If so, no more worries about patents, licences and so on

Cheers,

  Ludo.

[Da_Blitz]

im not sure about the sd and mmc 4 bit thing ethier, guess it would be wise to break out the manuals  gettintg your hands on one of them would be a diffrent matter as here in Australia you can pretty much only get SD

for the SD i am unsure if flipping to 4 bits requires you to tell the card what you are doing as you do have to be backwards compatible

[ldrolez]

im not sure about the sd and mmc 4 bit thing ethier, guess it would be wise to break out the manuals

CoOol, I've found this application note on the mmca site: www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf

It seems that a mmc+ in 4 bits mode has a connector 100% compatible with SD cards ! In France I can get MMC+ cards for the same price as SD cards (nearly). I think that the end of SD cards is near  

Cheers,

   Ludo.

[Da_Blitz]

i might have to see what i can do to get a mmc+ card then

i am also intrested in FB speed hacks however in 2.6 these seem to be a reimlpmentation of bvdd in the kernel (ie overlays) that automatically do color space conversion for you, most speed hacks will come not from the kernel but the aplicatons that we are running

i am looking into cachefs that uses FUSE to cache files, could be handy to cause the Z to fully cache any *.mp3 files fully into memorey (however i can tell mpd to do this as well)