[U-Boot-Users] JFFS2 images written from U-Boot unusable in Linux? (Round 2)
acurtis at onz.com
Sun Jan 9 18:30:32 CET 2005
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=.
>> => 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
>> 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.
> 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
More information about the U-Boot