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

[Allen Curtis]

Did you try upgrading to the latest MTD tools?

On Jan 9, 2005, at 9:03 AM, Craig Hughes wrote:

> 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
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>