You need a serial communications program such as minicom.  Kermit also works.  As far as copy and paste go that's a function of the terminal program you're using.  I would be surprised if shift-insert and control-insert dont' work, these special key combinations seem to work in just about everything for copy/paste.

The 2.6.22.19 kernel should boot using the same configuration as the default kernel.

Only the 2.6.30-rc? kernel's require changing boot args.  I'm assuming you used a .30 kernel.

Don't panic.  Once you get your boot args right all will be well.

I'm not using debug_quirks but it wouldn't hurt to try.

I'm busy compiling code on the sheeva, next time I have to reboot I'll pull out my 8Gig and see what it is.  I know it's not Kingston.  Seems like some people are having success with Kingston and others aren't.  OCZ 2Gigs seemed to work fine in my initial tests although I haven't tried them after switching to the 8Gig.

The mvsdio.patch is still required.

I've been running my rc4 build since it was released and I've had zero problems with an 8Gig SD.  Working for 10 minutes and then dying sounds a little suspicious.  It makes me wonder of your SD card might be bad.  You could also install my rc4 kernel and see if that makes a difference.

The kernel's at http://sheeva.with-linux.com/sheeva/ have usb modules.  Use 2.6.22.19 for the simplest upgrade to the stock kernel.  Just download README-2.6.22.19 to your plug and run it.

OK.  I've reconfigured the kernel to statically link EXT3, EXT4 and JFS (I'm a big fan of JFS myself, I've never had a problem with it).  So now you can mount a root with any of those filesystems.  I've also added device mapper modules for RAID fans.

To upgrade the plug if you've already installed one of the .30 kernels: delete sheeva-2.6.30-rc4* files and rerun README-2.6.30-rc4.

ext3 is built as a module, the only thing this precludes is mounting root as ext3.  If you add ext3 to /etc/modules it should mount an ext3 partition just fine.  The device mapper is for multiple-disk setups such as raid (which isn't too important on a sheeva).  I may build it in just to get rid of that warning (I hadn't noticed it on the earlier rc's).

rc4 is not a debug build.  So far it seems to work great.  I put debugging in rc3 due to the NULL referernce errors that were popping up ocassionally.

My raw iperf rate with sheeva is 624Mbits/sec as client, 576Mbits/sec as server.  So my numbers are a lot more consistent than yours.  I'd probably chock that up to using Linux on both ends.

In the case of my data rate being 100MB to the sheeva and 20MB from the sheeva.  I'm kinda thinking it has to do with using the NFS sync flag on my server.  It seems to me that sync causes the server to block until the write has finished.  I'm not too concerned over it though, since my clients do a lot more reads from the server than writes.

Can you run iperf between the machines?  I ran iperf last night on a kernel that had debugging enabled and it was running in the range of 200Mbits/sec.  After installing a kernel with debugging disabled (2.6.30-rc4) it's running at 644Mbits/sec.  An Athlon machine runs at 926 Mbits/sec.

644 is acceptable but 200 just didn't seem like it was enough.  I tweeked a lot of ipv4 settings trying to get my speed up and now I realize the settings weren't a problem.  It was just debugging slowing it down.

I did a timed copy of a 50M file to the sheeva and it did about 100MB sec, copying from the sheeva did about 20MB sec.  This of course is to/from a Linux server.  Scp was wayyy slower, the little sheeva just can't keep up with then encryption.

Release candidate 4 is now available.  I've added support for netfilter/iptables.  With any luck the NULL pointer dereference that affected rc3 is fixed.

Kernel and modules are available from the following locations:

IPV4: http://sheeva.with-linux.com/sheeva/

IPV6: http://sheeva6.with-linux.com/sheeva/

Features IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), usb-serial, uvcvideo.

Thank you both for your comments.  It's nice to know my kernels are being used.  It's also nice to know the installer (README) is working as advertised.

"nandwrite /dev/mtd2 /ubuntu-9.0.5.Release.jffs2" should work just fine it's straight out of Marvell's doc. "-p" is for the kernel image not for the filesystem.

Again, you probably also need to put "rootfstype=jffs2" in your bootargs.

Add rootfstype=jffs2 to your boot args and you should be golden.  Of course I'm assuming you rewrote your rootfs when you changed your partition locations.

Like kilowatt mentioned.

setenv mainlineLinux yes
setenv arcNumber 2097

If you didn't set those it won't boot.