I'm informed (from reading the forums) that ionics may have some units available if you email them direct and ask.

I'm interested in the Cirrus model that's got a 2GHz chip in it, but haven't a lot of cash to throw around right now and have other projects on.

I'm not sure about your dummy display for SSH/NX, but to get VNC going on the sheeva, I installed tightvncserver and gnome-desktop, then ran the vncserver executable. All seemed to work fine.

For forwarding over SSH, just connect to your plug with ssh -X <plug-address-here> and then run the GUI app of your choice. Though if you drop the SSH connection it'll kill it.

Does the GP display have one of the newer generations of processors (i.e. faster or multicore) or just the same as the sheevaplug?

Just interested because new, faster, better, parallel ARM cores get announced all the time, and there are loads of plug computers shown at technology exhibitions, but nothing ever seems to actually get released.

(Also does anyone know the status of the GP Display and debian? Last I checked cyrius.com said it was unlikely.

Errr.... me? I didn't get a PM.

I also now feel bad because I don't know if I ever got back to oler with the binary he was after, or any further help after leading him to use my favourite sort of web/torrent interface.

oler, if you're there, did all turn out ok?

I had exactly the same problem and can confirm that setting the two uboot environment variables mentioned by tbm enabled the plug to boot again.

It happened to me after a recent apt-get dist-upgrade in which the kernel moved to 2.6.32. I wouldn't like to blame the update, and I wasn't aware that it could or did do anything to the uboot env, but I have no idea how else those variables could have been lost...

Anyway, I have a happy plug again.

FYI - you can have a graphical environment on the sheevaplug by using VNC too. I set up tightvncserver and the full gnome-desktop-environment on mine, and use gvncviewer from other machines to access it.

Hey, sorry it took so long to reply, I haven't checked here (or used my plug) in a while. The problem with the MMC Mobile card was that the custom u-boot from kwonsk couldn't see it properly, like some of the other cards I have lying around. Once booted into an OS you could use it fine.

I think the drivers are the same and they are functionally compatible with SD, most devices that can use SD can use MMC, and MMCMobile is just half length MMC. My card even came with an extender to make it full length if needed.

This hit slashdot a couple of days ago, there is now an LGPL driver for them, BUT (and it's a big but), it's not the full driver with video compression that's required for having a desktop. There's also a previous, reverse-engineered driver with much the same capability.

I think, anyway. Have a look here

Basic drawing stuff might be possible, but X isn't (yet). And even on other platforms where the device is fully supported, video playback isn't really possible.

Still interesting stuff, especially with the touchscreen.

Must admit I'm quite tempted to try one of these -

http://www.amazon.com/Spectec-SDW-821-802-11b-802-11g-Wireless/dp/B000RLBDIA/

Wireless b/g SDIO card But I have no idea of the state of the linux drivers for it.

Doesn't seem to help, I just get a file in /dev/.udev/failed called \x2fdevices\x2fplatform\x2fmvsdio that would seem to indicate that something hasn't worked properly.

I tried adding sd_mod too, in case it helped, but it didn't seem to, and there aren't many ko files to choose from... Must figure out how to make my own initrd's at some point.

That's a bit of a pain... but thanks, I'll give it a go.

Hi again,

I've been playing with this and the patched u-boot that another contributor built for SD card booting.

Using your tar file and uboot environment as a guide I've managed to get the kernel/initramfs to boot, but I can't get any farther than that.

The problem seems to be to do with devices/drivers. The /dev directory available from the initramfs busybox prompt doesnt contain any entry for either sd* devices or (possibly more likely with SDIO) mmcblk*p* devices.

Any thoughts on what might be wrong there? Does the debian kernel support the sheevaplug's SDIO device? Can supply more details if they would help.

Thanks.

I've got a little further now, though I still have problems.

Firstly, I'm attempting to use a debian image. The uImage and uInitrd are in the boot subdirectory and it seems that the uBoot ext2 functions can't read those properly. It didn't like symlinks to the real files either, so I had to copy them.

Next problem is that after the kernel's booted there's no sd* or mmcblk devices available, so I have no idea how I'm  going to get the root filesystem mounted either .... but I guess that's not a uboot problem.

Hi there,

I've just flashed your custom u-boot and I can get mmcinit working with one of my cards (Patriot 16GB class 6 SDHC). The other one (Kingston 2GB MMCmobile) doesn't seem to be detected.

So how do I use it?

What I'd really like is to get it to boot the kernel from an ext2 partition, but I'm not quite sure what boot arguments to use.

How did you get it to boot from fat?

Thanks.

Yup, got a patriot 16GB card that I've been using with my eee 901 for a while, that has been put in the plug. The plug is running the ubuntu OS that it came with as i haven't got around to trying debian yet.

Patriot 16GB SDHC
Class 6
Formatted with 15G of ext2 (ext3 worked too, but the journal seemed unnecessary) and 500M of linux swap.

Pretty sure it's a PSF16GSDHC6, can anyone tell me how to check from a running system?

I've also tried and had working a 2GB Kingston MMCMobile chip, which I like because it doesn't stick out from the side.