[U-Boot-Users] JFFS2 images written from U-Boot unusable in Linux? (Round 2)

[Craig Hughes]

On Jan 7, 2005, at 3:00 AM, Martin Egholm Nielsen wrote:

> Hi there,
>
> Now I've gotten a bit further in my quest for getting JFFS2 images to 
> work between U-Boot and Linux.
> I upgraded to ELDK 3.1 and configured the CONFIG_JFFS2_NAND_SIZE to 
> the proper size. So, now I can succesfully put an image on the flash 
> from U-Boot and "ls" it. (Thanks again for that...)
>
> Further, if I erase the NAND from Linux and create some files/dir's, I 
> can see them succesfully from U-Boot with "ls".
> However, if I put a JFFS2-image on the NAND _from U-Boot_, Linux 
> cannot mount the device any longer:
>
> # cd /tmp
> # mkdir image
> # cd image/
> # echo "Test1" > testfile
> # mkdir testdir
> # echo "Test12" > testdir/testfile
> # mkfs.jffs2 --pad --big-endian --root=. --output=../test20050107.jffs2
>
> => nand erase clean
> => tftp 100000 test20050107.jffs2
> => nand write.jffs2 100000 0 $(filesize)
>
> => ls
> Scanning JFFS2 FS: . done.
>  drwxr-xr-x        0 Tue Nov 30 17:45:59 2004 testdir
>  -rw-r--r--        6 Tue Nov 30 17:45:45 2004 testfile
> => ls testdir
>  -rw-r--r--        7 Tue Nov 30 17:45:59 2004 testfile
>
> # mkdir /mnt
> # mount -t jffs2 /dev/mtdblock0 /mnt
> jffs2: Erase block size too small (16KiB). Using virtual blocks size 
> (32KiB) instead
> Cowardly refusing to erase blocks on filesystem with no valid JFFS2 
> nodes
> empty_blocks 0, bad_blocks 5, c->nr_blocks 2048
> mount: Mounting /dev/mtdblock0 on /mnt failed: Invalid argument

Martin, I noticed something similar recently when I upgraded kernels to 
a more recent one (not sure the exact version change), and it looked 
like actually the problem was that mtd-utils mkjffs2 tool was not 
agreeing with the kernel about how what the FS should look like, when 
dealing with entries which are both in the filetree being turned into 
the image, and also in a device_table.txt file (for example if you're 
specifying permission changes or ownership changes that way).  The 
mtdutils tool seemed to be creating 2 physical copies of the file in 
the root_fs (which massively increased its size), and marking one of 
the copies as "erased" or something but not actually removing it.  When 
the new kernel saw that, it borked.  I fixed the problem temporarily by 
just chmod'ing the files I wanted to change perms on before running 
mkjffs2 -- but a better fix would be to resolve the bug in the tool 
instead.  I haven't had a chance to do this yet.  Anyway, I think it's 
not u-boot's fault -- u-boot is actually being better than the kernel 
about reading a damaged JFFS2 fs, where the kernel refuses to.

C