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

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

[Martin Egholm Nielsen]

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

I have the following kernel configuration options concerning JFFS2:
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_NAND=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_LZO is not set
# CONFIG_JFFS2_LZARI is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
# CONFIG_JFFS2_PROC is not set

Are there anything else needed in order to support the way U-Boot writes 
an image?

Best regards,
  Martin Egholm

[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

[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
>

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

[Craig Hughes]

On Jan 9, 2005, at 9:30 AM, Allen Curtis wrote:

> Did you try upgrading to the latest MTD tools?

Yes, I did, and it made it break in a slightly different place, but 
still didn't work as long as I had an entry in device_table.txt which 
was an existing file or directory in the root_fs tree.

C

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

[Martin Egholm Nielsen]

> 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

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

[Martin Egholm Nielsen]

Hi again,

New information entered the scene: I tried another (identical) board 
today having none of the "Bad eraseblock" messages from my Linux kernel. 
And then everything worked!
Hence, my boardsupplier suggested that U-Boot "ignored" these "Bad 
eraseblock" that the NAND presumable was born with... What do you think?

BR,
  Martin Egholm

>>>> # 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
==== 8< 8< 8< ====
> 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

>>> 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.

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

[Pantelis Antoniou]

Martin Egholm Nielsen wrote:
> Hi again,
> 
> New information entered the scene: I tried another (identical) board 
> today having none of the "Bad eraseblock" messages from my Linux kernel. 
> And then everything worked!
> Hence, my boardsupplier suggested that U-Boot "ignored" these "Bad 
> eraseblock" that the NAND presumable was born with... What do you think?
> 
> BR,
>  Martin Egholm
> 
>>>>> # 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
> 
> ==== 8< 8< 8< ====
> 
>> 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
> 
> 
>>>> 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.
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 

NAND support is currently broken when bad blocks are present.

Will sent patches shortly dealing with the problems...

Regards

Pantelis

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

[Martin Egholm Nielsen]

>>>>>> # 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
>> New information entered the scene: I tried another (identical) board 
>> today having none of the "Bad eraseblock" messages from my Linux 
>> kernel. And then everything worked!
>> Hence, my boardsupplier suggested that U-Boot "ignored" these "Bad 
>> eraseblock" that the NAND presumable was born with... What do you think?
>> ==== 8< 8< 8< ====
>>
>>> 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
> NAND support is currently broken when bad blocks are present.
> Will sent patches shortly dealing with the problems...
Aahaaa! That explains a bit (alot)! :-)
Is this also broken in U-Boot 1.1.2 or just CVS?
Any estimates on when - months? ;-)

Thanks for the super info!
  Martin

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

[Martin Egholm Nielsen]

>> New information entered the scene: I tried another (identical) board 
>> today having none of the "Bad eraseblock" messages from my Linux 
>> kernel. And then everything worked!
>> Hence, my boardsupplier suggested that U-Boot "ignored" these "Bad 
>> eraseblock" that the NAND presumable was born with... What do you think?
=== 8< 8< 8< ===
Pantelis Antoniou wrote:
> NAND support is currently broken when bad blocks are present.
> Will sent patches shortly dealing with the problems...
Has these been submitted yet?

BR,
  Martin Egholm

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

[Wolfgang Denk]

In message <cuusuk$ifd$1@sea.gmane.org> you wrote:
>
> Pantelis Antoniou wrote:
> > NAND support is currently broken when bad blocks are present.
> > Will sent patches shortly dealing with the problems...
> Has these been submitted yet?

No.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As in certain cults it is possible to kill a process if you know  its
true name.                      -- Ken Thompson and Dennis M. Ritchie