Re: [U-Boot] JFFS2 scanning bug
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
Hi Mark,
mpfj-l...@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
0x (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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
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
0x (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 m...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
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 = 0x4d 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:
RO 2000 RO 4000 RO 6000 RO 8000 RO
A000 RO C000 RO E000 RO 0001 RO 0002
00030004000500060007
00080009000A000B000C
000D000E000F00100011
00120013001400150016
001700180019001A001B
001C001D001E001F0020
00210022002300240025
0026002700280029002A
002B002C002D002E002F
00300031003200330034
00350036003700380039
003A003B003C003D003E
003F0040004100420043
00440045004600470048
0049004A004B004C004D
004E004F005000510052
00530054005500560057
00580059005A005B005C
005D005E005F00600061
00620063006400650066
006700680069006A006B
006C006D006E006F0070
00710072007300740075
0076007700780079007A
007B007C007D007E007F 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] JFFS2 scanning bug
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
