The mtd is the internal flash. The number of partitions the kernel shows will match the number you specify in your bootargs. If you don't specify the partitions in your bootargs the kernel will assume the defaults. Be careful with this because the defaults may not match the partitions you used when your kernel and file system was written to the flash.

If you specify all three partitions the kernel will enumerate them mtd0 for u-boot, mtd1 for uImage, and mtd2 for rootsf. If you leave out the u-boot partition in the bootargs the kernel will enumerate them mtd0 for uImage, and mtd1 for rootfs. mtdblock1 is the same partition as mtd1 but accessible as a block device verses a character device.

You need to adjust any instructions you find to what you are specifying in your bootargs.

you should specify the filesystem type when you mount your flash file system.

use:mkdir /mnt/mtd2mount -t jffs2 /dev/mtdblock2 /mnt/mtd2

As far as your /dev/sda1 mount error did you format the partition /dev/sda1 as vfat? You need to 'mkfs.vfat /dev/sda1' after you finish your partitioning with fdisk. You will also need to initialize the other partitions with the appropriate file systems. So if you didn't do it 'mksf.ext3 /dev/sda2' and 'mkswap /dev/sda3'.

I will update the wiki so that the mtd mount points shown a bit more clear.

As far as /dev/sda1. I checked the kernel tree that came with the sheeva plug and saw that vfat and fat is NOT compiled in as part of the kernel but as a kernel module. That would explain why it tries to insmod vfat.ko in rc.local. The stupid thing is that fat.ko and vfat.ko that came with the filesystem does not work with the supplied kernel.

So, I guess it comes down to:

compile your own kernel and make sure vfat is compiled into the kernel instead of a module (this is what I did)compile the kernel module to match the running kernel.change /dev/sda1 so that it uses ext2 instead of vfat. Ext2 is already available to the kernel. Running ext2 is not a bad idea considering what happened to tomtom.boot the kernel from NAND flash, and boot the filesystem from /dev/sda2.

That's a lot of choices, I would *like* to add them all to the wiki but will definitely take some time.....

1. I had to partion/format my USB drive on another machine because vfat(msdos) was not available in the Marvel kernel release. I created a fat partion (sda1), a ext3 partition (sda2) and a swap partition (sda3).

2. I tried formatting the /dev/sda1 with ext2 instead of fat16 and the uboot ext2load didn't work.

3. My mtdblock2 was my root not the mtdblock1 because I recovered using the Marvel "SheevaPlug Development Kit - USB Flash Recovery from U-Boot-Rev1.2.pdf". It creates

mtd0: "u-bootmtd1: "uImagemdt2: "rootfs"

4. "mount /dev/mtdblock1 /mnt/mtd1" had to be changed because of 3 above to "mount /dev/mtdblock2 /mnt/mtd2". This also require the change in mkdir for this mount point.

5. When I executed "cp -av /mnt/mtd2 /mnt/sda2" is created /mnt/sda2/mtd2/ stuff. I had to move that dir up one to /mnt/sda2.

6. While changing the bootargs I used my "mtdparts=nand_mtd" entries for uImage and rootfs. This again was required because of the recover from usb issue above.

uImage will be /dev/mtd0 and /dev/mtdblock0rootfs will be /dev/mtd1 and /dev/mtdblock1

if your bootargs define all 3 partitions.mtdparts=nand_mtd:0x100000@0x000000(u-boot)ro,0x300000@0x100000(uImage)ro,0x1fc00000@0x400000(rootfs)Then when this is passed to the kernel as it's command line args

u-boot will be /dev/mtd0 and /dev/mtdblock0uImage will be /dev/mtd1 and /dev/mtdblock1rootfs will be /dev/mtd2 and /dev/mtdblock2

It's up to you how you want to define the partitions of your flash. But you must be consistent with what you pass to the kernel. And make sure you set all references ie root=/dev/mtdblock2 or which device you write your kernel or files system to accordingly.

ro following the (name) sets the partition to read onlyrw following the name is actually an error and will show up as such in dmesg if you look close.