transfer jffs2 rootFS to Nand flash
Ricard Wanderlof
ricard.wanderlof at axis.com
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.
/Ricard
More information about the linux-mtd
mailing list