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

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

Hi Mark,

mpfj-list@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.