the mtdparts=.... is part of your u-boot bootargs and are passed to the kernel as it command line arguments.

For instance if in u-boot my bootargs looks like this.

bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000(u-boot)ro,0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/sda1 rootdelay=10

If i run dmesg after boot and search for the kernel command line I see:

Kernel command line: console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000(u-boot)ro,0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs) rw root=/dev/sda1 rootdelay=10

By the way this boots with my root file system on the first partition of my usb 2.0 harddrive.

So, after much pain and many attempts I did get the x10 cm19a module to build.  Unfortunately it just crashes on load.

The nfs mount of the tree from another linux device didn't quite workout.  The module would not build because some of the tools needed had not be built from the source.  For instants scripts/mod/modpost.

In the end I loaded the tree on the sheeva.  Downloaded the defconfig from the optware sources.  And built the kernel and some modules on the sheeva.  Then I was able to get my module to build but it doesn't work properly.

The file system is usually in the third partition of the Flash.  Since the flash doesn't really have a partition table, we need to tell the kernel where the partition boundaries are.  Once we have decided on the partition sizes we want to use we must be consistent in what we tell the kernel.  If we decide to change the partition size and thus the boundaries we will need to rewrite the images stored in the effected partition. you could come up with a partition scheme that had a large second partition for the file system and a small third partition for the kernel.  Your bootargs and bootcmd would need to change to match what you are using.  I think the u-boot always needs to be in the first flash partition.

Some configurations are telling the kernel about all three partitions of the flash through the bootargs ie:
mtdparts=nand_mtd:0x100000@0x000000(u-boot)ro,0x400000@0x100000(uImage),0x1fb00000@0x500000(rootfs)

Some are telling the kernel about just two ie:
mtdparts=nand_mtd:0x400000@0x100000(uImage)ro,0x1fb00000@0x500000(rootfs)

The format here is a list of size@starting location(name)[ro]

 The kernel enumerates them in the order shown so if the rootfs is in the third partition the kernel is told about it will be /dev/mtdblock2.
If rootfs is the second one in the bootargs it will be /dev/mtdblock1.

The reason we don't always tell the kernel about the u-boot partition is to make it really difficult for the kernel to access it.  That way we don't corrupt it with a typo.  The 'ro' shown in these two examples tells the kernel to make the partition read only which is another safeguard against writing to it by mistake.

Note in the second example the 'ro' on the kernel partition will make it impossible to rewrite the kernel.  We would need to reboot with different bootargs in order to change the kernel.  Setting the rootfs partition to ro would probably not work well.

Mark

nandwrite --help explains the options
  -p, --pad             pad to page size

You should use it to write the kernel so you pad the file out to the page size of the nand.

The file system .jff2 should already be padded so you should not use -p when you write the file system.

The -m option might help if you have a write failure by marking the flash block bad
  -m, --markbad         mark blocks bad if write fails

also you should run
flash_eraseall -j /dev/mtd(x)    (x) should be replaced with the appropriate partition number.

to clear the partition before you use nandwrite

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/mtd2
mount -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'.

No it does not come with a power supply.  It has the same small DC power jack as one of my older USB 1.0 hubs.  So, I'm using the power supply from the old hub.  It is rated at DC 5V 2A inner+/outer-.  I'm not sure what the power jack size is but it is the same as a few devices I have with 5V 2A power supplies.

I believe if you just run depmod this error will go away.  I'm now running a new kernel so I can't verify that right now.

Mark

(Plugit -  you beat me to it.  You posted as I was typing)

That is great...  

So I assume you need a fat partition on the SD card to read the kernel from.  u-boot also supports a command 'ext2load' which can read the kernel from an ext2 partition on a usb device.  Is this supported with your changes?  This is convenient since you don't need the fat partition and you can just put the kernel image in /boot/ or your root file system.

Mark

The hub I mentioned has a jack to for using a power supply.  I used it for a few days without a supply.  I rsynced a large harddrive to another and to a flash drive, tested a few usb devices all the while running the file system on one of the usb drives.  No problems.  I'm still using it but now I have a power supply connected to the hub so I don't put any unneeded strain on the internal Plug power supply.

I've been using a cheap USB 2.0 hub I bought here http://www.cablewholesale.com/specs/usb-hub/40u2-42401.htm without any problems at all.

By the way if anyone needs some cables these guys have great prices.  No I don't work for them.

Brian,

So I have this code for a module for an X10 cm19a (USB transceiver) that I have compiled and used in the past.  I got it from http://lemaymd.com/drupal/node/3 but then I customized it a bit for my own use.  I would like to compile it for use on the Plug but I am using the optware kernel you created and I don't have the header files.  apt-get would install 2.6.28-11 and ipkg doesn't have the headers available.  What is the best way to get the header files so I could still use your optware kernel?  Would I also need the configure file that you used to create the kernel?

An optware linux-headers file that matched the kernel would be great.

Mark

Check the FAQ on the Wiki

http://www.openplug.org/plugwiki/index.php/Frequently_Asked_Questions

nandwrite --help explains the options
-p pad to page size.  The JFFS2 image is already padded. but the kernel is not.  Use it for kernel writes.
-m mark blocks bad if the write fails.  Seems appropriate to use for both kernel and file system.

Now it looks like you don't have a valid files system in the rootfs partition.  since you moved the partition you need to write the jffs2 file system to the new partition.

You should be able to boot from NFS using the new kernel that is now in flash.  Then write the file system.

flash_eraseall -j /dev/mtd2
nandwrite -m /dev/mtd2 YourFileSystem.jffs2

Since your only telling the kernel about two of the partitions on your flash, the files system will be the second one /dev/mtdblock1.  You can either change your bootargs to root=/dev/mtdblock1 or change the bootargs to tell the kernel about all 3 partitions.