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

[Martin Egholm Nielsen <martin@egholm-nielsen.dk>]

> Did you try upgrading to the latest MTD tools?
I'm running with mkfs.jffs2 from ELDK 3.1 and tried a similar version on 
target - namely revision 1.42.

=== 8< 8< 8< ===
>>> # 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, 
But I have no such file. I'm just creating this simple root-filesystem...

But I'm getting some info from the Kernel at startup:

Scanning device for bad blocks
Bad eraseblock 1 at 0x00004000
Bad eraseblock 2 at 0x00008000
Bad eraseblock 3 at 0x0000c000
Bad eraseblock 4 at 0x00010000
Bad eraseblock 5 at 0x00014000
Bad eraseblock 6 at 0x00018000
Bad eraseblock 7 at 0x0001c000
Bad eraseblock 1600 at 0x01900000

Though I'm not sure what it means, or if has anything to do with this at 
all...

>> 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.
Sounds resonable to assume yes - I just wondered whether U-Boot had some 
sophisticated way of writing the image to the nand, that required some 
specific kernel configuration.

BR,
  Martin