The first time I booted after reflashing the kernel I got hung just like that.  Then I did a hard reset and it worked fine.  Yeah, your getting close....almost there.

"mtdparts=nand_mtd ..." is correct for a 2.6.22.x kernel.
"mtdparts=orion_nand ..." is correct for a 2.6.30 kernel.

So If you are booting the 2.6.30 kernel over tftp, you need to change that.  I noticed that if you boot with an incorrect mtdparts for the 2.6.30 kernel, the 2.6.30 kernel seems to figure out the "old" partitions.  Which sounds like what you're seeing.

You definately need to use "orion_nand" once you're ready to boot the 2.6.30 kernel from nand.

That would be a problem.  It has to have a limited set of device drivers in /dev (including ttyS0) when the kernel boots.  The kernel needs ttyS0 BEFORE udev is started.

Actually the ip args are only applicable if you are mounting root over nfs.  So they shouldn't be important in your case.  The first IP address is the IP you want assigned to the sheeva.  The second and third args are the ip address of the server.

Based on the "Writing Jaunty Filesystem" doc you don't use "-p" when writing the jffs2 partition.  You do use it to write the kernel image.

To upgrade to 2.6.30 read the readme http://sheeva.with-linux.com/sheeva/README-2.6.30-rc2
Then download the readme to the sheeva.  Then run it (don't forget to set the U-Boot args.  I linked the rc2 rather than the rc3, since rc3 has some minor issues that should be fixed in rc4.


Here's a thread on the topic.

http://openplug.org/plugforum/index.php?topic=145.0

mavr15, In a lot of cases you can get away with using a previous kernel with new modules, but there are cases where it just won't work.  Apparently this is one of those cases.  When you enable a new module it "may" enable features (export symbols) that weren't exported before the module was enabled.  The most prudent approach is to flash the matching kernel if the modules have been changed/updated.

mavr15, Were you getting "unknown symbol" when you modprobed tun?  I actually tested tun on my system and it loaded fine when I modprobed tun.  I wonder if you were using the previous version of the kernel that was build without tun with the new Modules.  That could cause a potential "unknown symbol".

In any case the 2.6.22.19 kernel should work just fine.

I'm pretty sure it's been submitted to the maintainers.  It might take a while to trickle up into the official kernel.  Hopefully the fix will be in the official .30 kernel.

Call the power company and see if you can get them to turn your power off and on?   Barack Obama could get them to do it. hehe

I agree that SD isn't as fast as USB on the Sheeva.  I did some testing with results similar to yours.  The interesting thing is that even though SD isn't as fast as USB, it's still WAY faster than JFFS2 running from flash.

Right now I'm running with an SD root and a USB /home, which is a nice combo for a development Sheeva.

If you can get the pronged piece to move at all you can usually just put a prying device in the gap and pry it loose.  Seems to me we used a butter knife.  It does have a catch on the underside that makes it a bit of a bear to remove it.

All I can say is wow.  When you move your root filesystem to SD it is way fast compared to JFFS2.  It moves wear and tear off your Flash to replaceable SD.  It's beautiful that you could pop out the SD from a SheevaPlug, pop it into an SD reader on a standard machine and create a duplicate SheevaPlug install in minutes.  I'm using an 8Gig SD formatted with EXT2.  My theory is that journaling filesystems such as EXT3, EXT4, JFS, XFS create undo wear on flash media.  So I stick with plain 'ol EXT2 with noatime specified in fstab.

All you need to do is:

"cp -ax / /Whereever/SdIsMounted"
In U-Boot change boot_args to "root=/dev/mmcblk0p1".

I just added the tun driver to 2.6.30-rc2 and 2.6.30-rc3.  It was already in 2.6.22.19.

The first time I rebooted after flashing.  I had a similar response.  In my case A hard reset fixed the problem and It's been working fine ever since.  The most interesting problem I had was the kernel not being able to identify what the root filesystem type was.  That's where the "rootfstype=jffs2" came in.

I'd suggest using tftp to boot the kernel if you're still having problems and then do a  reflash.