transfer jffs2 rootFS to Nand flash

Ricard Wanderlof ricard.wanderlof at
Thu Aug 30 07:51:33 EDT 2007

On Thu, 30 Aug 2007, Saravanan Chanemouganandam wrote:

> Thanks to your analysis and answer. I have removed the --pad option in
> mkfs.jffs2 and then flashed the image using "nandwrite -p /dev/mtdblock1
> cmrootfs.img". This time theres no  "due to bad blocks" error.

Ok, well that's good anyway.

> The test on mounting jffs2 image was success once after flashing within the
> running linux as
> cm-debian:/mnt/net#mount -t jffs2 /dev/mtdblock1 /mnt/test
> cm-debian:/mnt/net# ls /mnt/test
>  bin   dev  home    lib         media  opt              proc  sbin  sys  usr
> boot  etc  initrd  lost+found  mnt    packages.txt  root  srv   tmp  var
> Indeed, the test of above jffs2 mount after reboot of the system got failed
> and its a strange.
> cm-debian:/mnt/net# mount -t jffs2 /dev/mtdblock1 /mnt/test
> Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
> empty_blocks 0, bad_blocks 8, c->nr_blocks 4080
> mount: /dev/mtdblock1: can't read superblock

The "Cowardly refusing to erase blocks on filesystem with no valid JFFS2 
nodes" indicates to me that what Linux thinks is /dev/mtdblock1 is in fact 
completely erased flash.

> I hope this may explain some hidden stuffs behind the failure of mounting when
> kernel boots. I think it could be the compatibility isseu of the compulab NAND driver and
> the JFFS2. any idea from this behaviour?

The only idea I have is that the device numbers (/dev/mtdblockN) get 
shifted around for some reason, i.e. you should use /dev/mtdblock0 or 2 or 
something. Can't understand why though.


More information about the linux-mtd mailing list