[U-Boot] JFFS2 scanning bug

[U-Boot] JFFS2 scanning bug

[Mark Jackson]

I've just updated from v2008.10 to v2009.01 on my AVR32 board (MIMC200).

JFFS2 no longer works (it hangs at "Scanning JFFS2 FS:", so I've done a git 
bisect, and here's the result:-

8a36d31f72411144ac0412ee7e1880e801acd754 is first bad commit
commit 8a36d31f72411144ac0412ee7e1880e801acd754
Author: Ilya Yanok <yanok@emcraft.com>
Date:   Thu Nov 13 19:49:33 2008 +0300

     jffs2: rewrite jffs2 scanning code based on Linux one

     Rewrites jffs2_1pass_build_lists() function in style of Linux's
     jffs2_scan_medium() and jffs2_scan_eraseblock().
     This includes:
      - Caching flash acceses
      - Smart dealing with free space

     Signed-off-by: Alexey Neyman <avn@emcraft.com>
     Signed-off-by: Ilya Yanok <yanok@emcraft.com>

:040000 040000 9c5a40532bce0ea6df7a287e3dff47189d513dd0 
8d4145b1d15ebd9a1281c5c8e7dd2e32ef168b26 M	fs

Is this a known problem ?

Regards
Mark

[U-Boot] JFFS2 scanning bug

[Ilya Yanok]

Hi Mark,

Mark Jackson wrote:
> I've just updated from v2008.10 to v2009.01 on my AVR32 board (MIMC200).
>
> JFFS2 no longer works (it hangs at "Scanning JFFS2 FS:", so I've done a git 
> bisect, and here's the result:-
>   
[snip]
> Is this a known problem ?
>   

No, I've never heard of it. Could you please be more specific? What type
of flash do you using? What is the size of your JFFS2 partition? How did
you create your filesystem?

Regards, Ilya.

[U-Boot] JFFS2 scanning bug

[Mark Jackson]

On 26/02/09 14:48, Ilya Yanok wrote:
> Hi Mark,
>
> Mark Jackson wrote:
>> I've just updated from v2008.10 to v2009.01 on my AVR32 board (MIMC200).
>>
>> JFFS2 no longer works (it hangs at "Scanning JFFS2 FS:", so I've done a git
>> bisect, and here's the result:-
>>
> [snip]
>> Is this a known problem ?
>>
>
> No, I've never heard of it. Could you please be more specific? What type
> of flash do you using? What is the size of your JFFS2 partition? How did
> you create your filesystem?

The JFFS image was made using Buildroot, and I think it's just over 5MBytes 
(size = 0x4d0000 bytes).

The image itself is fine, since if I install v2008.10, the target boots (into 
Linux) as expected.

The flash is an 8MByte device (Spansion P/N S29GL064N90TFI04).

I have taken an existing, working board, and simply installed v2009.01 (rather 
than v2008.10).  The target boots into U-Boot fine, and I can read / write the 
env variables, and, obviously, I'm able to write U-Boot itself !!

flinfo returns the following:-

U-Boot> flinfo

Bank # 1: CFI conformant FLASH (16 x 16)  Size: 8 MB in 135 Sectors
   AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E
   Erase timeout: 16384 ms, write timeout: 2 ms
   Buffer write timeout: 5 ms, buffer size: 32 bytes

   Sector Start Addresses:
   00000000   RO   00002000   RO   00004000   RO   00006000   RO   00008000   RO
   0000A000   RO   0000C000   RO   0000E000   RO   00010000   RO   00020000
   00030000        00040000        00050000        00060000        00070000
   00080000        00090000        000A0000        000B0000        000C0000
   000D0000        000E0000        000F0000        00100000        00110000
   00120000        00130000        00140000        00150000        00160000
   00170000        00180000        00190000        001A0000        001B0000
   001C0000        001D0000        001E0000        001F0000        00200000
   00210000        00220000        00230000        00240000        00250000
   00260000        00270000        00280000        00290000        002A0000
   002B0000        002C0000        002D0000        002E0000        002F0000
   00300000        00310000        00320000        00330000        00340000
   00350000        00360000        00370000        00380000        00390000
   003A0000        003B0000        003C0000        003D0000        003E0000
   003F0000        00400000        00410000        00420000        00430000
   00440000        00450000        00460000        00470000        00480000
   00490000        004A0000        004B0000        004C0000        004D0000
   004E0000        004F0000        00500000        00510000        00520000
   00530000        00540000        00550000        00560000        00570000
   00580000        00590000        005A0000        005B0000        005C0000
   005D0000        005E0000        005F0000        00600000        00610000
   00620000        00630000        00640000        00650000        00660000
   00670000        00680000        00690000        006A0000        006B0000
   006C0000        006D0000        006E0000        006F0000        00700000
   00710000        00720000        00730000        00740000        00750000
   00760000        00770000        00780000        00790000        007A0000
   007B0000        007C0000        007D0000        007E0000        007F0000   RO

Under v2008.10, when I do an 'ls', the line "Scanning JFFS2 FS:" is shown, 
along with a spinning - \ | / - character sequence.

Under v2009.01, the "Scanning JFFS2 FS:" text is shown and the target appears 
to hang (i.e. no spinning cursor, just a solid cursor).

I have also tried a new board (with blanked flash).  Under v2008.10 'ls' comes 
up with a "filesystem not found" type of error.  Under v2009.01, again the 
target just appears to hang.

I guessed that no-one else has this problem (since the bad commit was back in 
November), but it's definitely broken for me !!

I'm happy to help diagnose / fault find.

Regards
Mark

[U-Boot] JFFS2 scanning bug

[Ilya Yanok]

Hi Mark,

Don't you have JTAG debugger so you could find where exactly it hangs?
Or you can try adding debugging printf's to the source... I can't
reproduce your problem myself so that info would be useful.

Regards, Ilya.

[U-Boot] JFFS2 scanning bug

[Mark Jackson]

On 26/02/09 15:46, Ilya Yanok wrote:
> Hi Mark,
>
> Don't you have JTAG debugger so you could find where exactly it hangs?
> Or you can try adding debugging printf's to the source... I can't
> reproduce your problem myself so that info would be useful.
>
> Regards, Ilya.

I do have a JTAG unit, but it'll be quicker for me to just use some debug 
printf's.

I'll report back when I've found the problem.

Regards
Mark

[U-Boot] JFFS2 scanning bug

[mpfj-list at mimc.co.uk]

> Hi Mark,
>
> Don't you have JTAG debugger so you could find where exactly it hangs?
> Or you can try adding debugging printf's to the source... I can't
> reproduce your problem myself so that info would be useful.

Okay, I think I've found the problem.

When *not* using JFFS2_CMDLINE mode, U-Boot tries to work out the MTD
table automatically (for me using NOR flash, it's in the function
get_part_sector_size_nor() in cmd_jffs2.c).

Without specifying CONFIG_JFFS2_PART_SIZE, part->size defaults to
0xffffffff (use whole device).

However, the scanning code contains the line ...

end_phys = start_phys + flash->size;

... which, in this case, simply sets end_phys to (start_phys - 1).

Then the code has the lines ...

if (flash->start[i] >= end_phys)
	break;

... which results in an instant break, finally leaving the calculated
sector size as 0 !!

The attached patch seems to work for me, but probably needs double-checking
on some other platforms.

Regards
Mark
---
This patch fixes the JFFS2 scanning code when not using
CONFIG_JFFS2_CMDLINE.

Signed-off-by: Mark Jackson <mpfj@mimc.co.uk>
---
 common/cmd_jffs2.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/common/cmd_jffs2.c b/common/cmd_jffs2.c
index d0a7cea..2f3b3a9 100644
--- a/common/cmd_jffs2.c
+++ b/common/cmd_jffs2.c
@@ -1814,7 +1814,12 @@ static inline u32 get_part_sector_size_nor(struct
mtdids *id, struct part_info *
 	flash = &flash_info[id->num];

 	start_phys = flash->start[0] + part->offset;
-	end_phys = start_phys + part->size;
+
+	if (part->size == SIZE_REMAINING) {
+		end_phys = start_phys + flash->size;
+	} else {
+		end_phys = start_phys + part->size;
+	}

 	for (i = 0; i < flash->sector_count; i++) {
 		if (flash->start[i] >= end_phys)

[U-Boot] JFFS2 scanning bug

[Ilya Yanok]

Hi Mark,

mpfj-list at mimc.co.uk wrote:
>> Hi Mark,
>>
>> Don't you have JTAG debugger so you could find where exactly it hangs?
>> Or you can try adding debugging printf's to the source... I can't
>> reproduce your problem myself so that info would be useful.
>>     
>
>   

Thanks for clearing this out.

> Okay, I think I've found the problem.
>
> When *not* using JFFS2_CMDLINE mode, U-Boot tries to work out the MTD
> table automatically (for me using NOR flash, it's in the function
> get_part_sector_size_nor() in cmd_jffs2.c).
>
> Without specifying CONFIG_JFFS2_PART_SIZE, part->size defaults to
> 0xffffffff (use whole device).
>
> However, the scanning code contains the line ...
>
> end_phys = start_phys + flash->size;
>
> ... which, in this case, simply sets end_phys to (start_phys - 1).
>
> Then the code has the lines ...
>
> if (flash->start[i] >= end_phys)
> 	break;
>   

This is wrong actually as sector_size is not an attribute of a partition
but is an attribute of a whole mtd device and we don't want to get
smaller sector size (this would make generic scanning slower and can
break summary support). So just need to remove this break.

I'll prepare the patch and will post it in some days. (We can just drop
the above two lines and it should work but the most clean way would be
to calculate sector_size after flash_init() and then just use that value
but that means a lot of patching... Maybe someone has any ideas?)

[...]
>  	start_phys = flash->start[0] + part->offset;
> -	end_phys = start_phys + part->size;
> +
> +	if (part->size == SIZE_REMAINING) {
> +		end_phys = start_phys + flash->size;
>   

I can still imagine an overflow here.

Regards, Ilya.

[U-Boot] JFFS2 scanning bug

[Mark Jackson]

On 14/03/09 00:59, Ilya Yanok wrote:
> Hi Mark,
>

<snip>

>
> I'll prepare the patch and will post it in some days. (We can just drop
> the above two lines and it should work but the most clean way would be
> to calculate sector_size after flash_init() and then just use that value
> but that means a lot of patching... Maybe someone has any ideas?)
>

Has any progress been made with this ?  The v2009 code still seems to suffer 
from this.

Regards
Mark