Sdio Ram Drive

[rv6502]

topic for hardware gurus (and hobbyist wannabes like me) :

I was thinking of ways to increase the ram for fun (other than duct-taping a swap space usb HDD under it, and/or destroying a flash SD card with repetitive swap writes).

there are RAM-based IDE and now SATA "harddrives"
http://www.tomshardware.com/reviews/hyperos-dram-hard-drive-block,1186.html
those drives are used to act as ultra fast swap devices to augment memory or as ultra fast drives for data capture.

something similar to those ram drives could be used to boost the internal ram as a swap space like how GameCube Linux uses the 16MB audio ram as a swap to augment the internal 24MB.

I could not find any equivalent in SDHC or SDIO form, most likely because I'm likely to be one of the few crazy people who'd find a use for it.
and I found some SPI and I2C ram chips but they're depressingly small (1 megabit).
http://www.electronicspecifier.com/Memory/Ramtron-announces-power-efficient-512-Kilobit-and-1-Megabit-Serial-F-RAM-V-Family-memory.asp

...
Micron has 8Gb mobile LPDDR in sampling ( = not available in large quantities yet) ...
*drool* ( pandora gold edition anyone ? )
http://www.micron.com/products/dram/mobiledram/tiomap_partlist
but you can only hook up 1 of those chips at a time to the OMAP afaik,

one or more large serial RAM chips would be an easy way to expand memory as a ultra fast swap space with Linux.
I could not find a DDR RAM controller with a serial interface either (kinda stupid to go from fast DDR to slow 1bit serial in most cases) but it'd be possible to build one with a FPGA ... (way above my fpga-fu right now)

 

[Pleng]

Well you're limited by the speed of the SD Controller so I don't think you'd see any improvements in speed over a fast SD card, really.

If you're worried about wear then just use a dedicated lower-capacity but higher-speed card for swap, and only use half the capacity.

Then in the unlikely event that it ever does wear out as to become useless, you just need to replace it with a new one. Lets face it, a few dollers every couple of years won't exactly break the bank (it'll certainly be cheaper than any solution you have proposed!)

 

[Exophase]

I believe that SDIO is only 1bit, while SDHC can be 4bit or 8bit (I think it's 8bit on Pandora). So it'll actually be much slower. From what I understand, SDIO is just a SPI interface. Somehow I just don't think "ultra fast" when I think "serial RAM."

 

[rv6502]

I believe that SDIO is only 1bit, while SDHC can be 4bit or 8bit (I think it's 8bit on Pandora). So it'll actually be much slower. From what I understand, SDIO is just a SPI interface. Somehow I just don't think "ultra fast" when I think "serial RAM."

it'd be faster than erasing a sector, I tried to put a swap on an SD card for the heck of it, for very light work on a fresh card it was ok, but
SD controllers have an internal buffer and making a bunch of IO quickly saturates and stalls on sector erase.

and as for "ultra fast" != "serial" ... isnt SATA and USB 2.0 fast AND serial? it depends how you clock it.

so, I should say "I could not find any relatively fast and large (in bits, not physical size) serial ram chips"

speaking of USB, a USB 2.0 RAM stick would work, but when googleing for anything like that it seem that the common world has decided that
Flash ROM = RAM
so if one exists, googleing for it would be unlikely to yield any result.

 

[Exophase]

Give me a break. Yeah, SATA and USB 2.0 are fast.. for block drive and peripheral connection interfaces! Serial RAM is a lot slower than parallel RAM, and that's not going to be changing any time.. ever. Or maybe you think parallel buses that saturate attainable clock speed are obsolete?

A RAM card over SDHC is obviously the best option. I meant the interface of course, not using SDHC flash! SDIO or USB is not going to compete. Yeah, maybe you can't find SDHC RAM cards, but it looks like you can't find any of this stuff so the point is pretty moot.

 

[rv6502]

Give me a break. Yeah, SATA and USB 2.0 are fast.. for block drive and peripheral connection interfaces! Serial RAM is a lot slower than parallel RAM, and that's not going to be changing any time.. ever. Or maybe you think parallel buses that saturate attainable clock speed are obsolete?

A RAM card over SDHC is obviously the best option. I meant the interface of course, not using SDHC flash! SDIO or USB is not going to compete. Yeah, maybe you can't find SDHC RAM cards, but it looks like you can't find any of this stuff so the point is pretty moot.

that's what I'm saying: they don't seem to make fast serial rams.

all the serial ram chips I've found were small and designed to be connected to slow (~16Mhz) micro-controllers / SoC.

a large 133Mhz serial-accessed SDR DRAM would give a decent 16MB/sec (not counting overhead or a self-clocking encoding) and be less of a pain to interface and design boards than using parallel DDR ram.
although they might still require differential pairs to reach those speeds reliably.

 

[Exophase]

There's no demand for 133MHz serial RAM. Even if it's easier to design for, no one wants RAM that's 32-128x slower than DDR SDRAMs would be while still requiring as fast of a clock. And you'd be kinda hard pressed to find SPI-like 133MHz serial interfaces on most things, not just "slow" microcontrollers.

You either are okay with very slow RAM where access time really doesn't matter much or fast RAM where it does, there isn't a demand for things right inbetween.

Since none of what you want exists you'd may as well dream about RAM cards over SDHC because that's the best option. It'd be faster than USB, the only other option. RAM that's 50x slower than what's internal to the Pandora doesn't seem awfully useful.. if you're using it as a swap space that you're constantly hitting you might not be destroying any SD cards but you will be waiting forever for anything to happen.

 

[kloplop321]

Interesting article, but I am not too interested for the concept moved to the pandora.

 

[senquack]

Reminds me of those ancient 1MB RAM expansion cards you could get for your computer that ran off the ISA bus. Slow as sheeeeiiiitttt.

 

[rv6502]

if you're using it as a swap space that you're constantly hitting you might not be destroying any SD cards but you will be waiting forever for anything to happen.

not constantly hitting, but regularly on application switches is a good probability.

my laptop in 2001 was a Celeron 650Mhz, 192MB of ram, running Mandrake Linux + KDE, pretty close in power to the Pandora.
I could get work done really well even tho the swap would easily go up to 512MB usage, its the total number of Apps idle that would eat at the memory with only one or two used at the same time, with a short 1 to 2 seconds of swapping when switching to a not-so-recently-used app.

the work usage went 1-5mins in one app, switch with 1-2 second swap, 1-5 mins in another app, etc.
a lot of swap activity, but definitely workable with about the same swap activity pattern for surfing the net (incl. online documentation, man pages).


I'll have to try getting DDR RAM to work on the fpga board I have and hook it up as an SDHC card.
last I tried the xilinx tools were buggy and caused random compilation errors and crashes, regularly failed to reprogram the fpga (even tho the program returned "success" it was still running the old program), and other annoying buggy tool details so I put the projects aside.

 

[greendots]

Angstom and e17 will use quite a bit less ram then Mandrake and KDE. Of course pandora's ram has to be shared but still 256 should be enough.

You might find this post interesting:
http://www.gp32x.de/board/index.php?/topic/48640-quite-realistic-chance-to-have-about-400mb-of-ram-in-pandora/
With it, you'll have around 400MB and I bet compressing/decompressing from the DDR is going be faster then anything from the SD slot.

Also remember last year at this time we only had 128mb and most devs thought it was plenty.

 

[Exophase]

Pandora is not a desktop. I find it strange that anyone would want to use it as if it were one, constantly switching between different apps that each use a lot of memory. If you're swapping every 5 minutes then it'll take a really long time for you to destroy an SD card.

 

[torpor]

man, if it wasn't for threads like this i'd be going crazy. i just cant wait to have pandora in my own hands, running my own code on it. i have full trust of the controller and ergonomics situation .. this is going to be amazing. but i want it now.

its definitely no desktop.

 

[Series-8]

I think this is quite possible (useful...hrm).

The SD card slot I believe is a 4 bit 50Mhz bus; thus a 25MB/s data rate (which does not jive with the wikipedia numbers....oh well)

Its probably not that hard to combine a CPLD and a DDR1/2/3 chip, however unless there are more engineers in the forum this isn't going to happen.

SPI would be far too slow for DDR (also the wrong electrical format).

This does not make a really fast 'swap' disk - but better than using up all the NAND backup sectors on a flash chip.

This would work VERY well for a 'backing store' for the /dev/ramzswap.

Unless.... we can overdrive the SDHC bus, 50Mhz becomes 100Mhz ?

*sigh* SATA only uses FOUR pins.... (at MANY Ghz....)

 

[rv6502]

I think this is quite possible (useful...hrm).

The SD card slot I believe is a 4 bit 50Mhz bus; thus a 25MB/s data rate (which does not jive with the wikipedia numbers....oh well)

Its probably not that hard to combine a CPLD and a DDR1/2/3 chip, however unless there are more engineers in the forum this isn't going to happen.

SPI would be far too slow for DDR (also the wrong electrical format).

This does not make a really fast 'swap' disk - but better than using up all the NAND backup sectors on a flash chip.

This would work VERY well for a 'backing store' for the /dev/ramzswap.

Unless.... we can overdrive the SDHC bus, 50Mhz becomes 100Mhz ?

*sigh* SATA only uses FOUR pins.... (at MANY Ghz....)

25MB/sec with no seek time is quite good, normal HDD have long seek time and swaping in/out causes a lot of seeking so it wouldn't be so slow compared to HDD.

I've been trying to download the new xilinx webpack and toy with the idea (got 64MB DDR on the dev board) but their download server cuts off the download at exactly 319.75 MiB forcing people to use their "download manager", very suspicious / annoying.
the previous webpack has so many bugs I spend more time working around them than getting things done, the proprietary linux drivers didn't work, and the linux tools wouldn't communicate with the windows-based fpga programing server (protocol bugs).

its almost as fun as pulling your teeth.

 

[Squidge]

Unless.... we can overdrive the SDHC bus, 50Mhz becomes 100Mhz ?

If your going to drive the bus at 100Mhz, then you may as well just use SDXC which supports that speed. It'll be fun running the data paths at 100Mhz however, and I doubt that the current hardware design supports such speeds.

 

[Exophase]

OMAP3530's SD/MMC data bus is 8bits, so as long as all the pins are brought out you should be able to use the MMC interface instead to get 8bit width.

 

[notaz]

SD only needs 4 data pins, so Pandora uses remaining 4 as GPIOs connected to write protect switch and some LEDs. With some modding in could be possible though, but that wouldn't be easy.

 

[Tor]

SD only needs 4 data pins, so Pandora uses remaining 4 as GPIOs connected to write protect switch and some LEDs. [...]

Is that right? I was certain the 8 bits were there to support MMC Plus/Media cards, which have 8 bits.