* [U-Boot] JFFS2 scanning bug
@ 2009-02-25 13:07 Mark Jackson
2009-02-26 14:48 ` Ilya Yanok
0 siblings, 1 reply; 8+ messages in thread
From: Mark Jackson @ 2009-02-25 13:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-02-25 13:07 [U-Boot] JFFS2 scanning bug Mark Jackson
@ 2009-02-26 14:48 ` Ilya Yanok
2009-02-26 15:18 ` Mark Jackson
0 siblings, 1 reply; 8+ messages in thread
From: Ilya Yanok @ 2009-02-26 14:48 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-02-26 14:48 ` Ilya Yanok
@ 2009-02-26 15:18 ` Mark Jackson
2009-02-26 15:46 ` Ilya Yanok
0 siblings, 1 reply; 8+ messages in thread
From: Mark Jackson @ 2009-02-26 15:18 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-02-26 15:18 ` Mark Jackson
@ 2009-02-26 15:46 ` Ilya Yanok
2009-02-26 16:19 ` Mark Jackson
2009-03-06 20:06 ` mpfj-list at mimc.co.uk
0 siblings, 2 replies; 8+ messages in thread
From: Ilya Yanok @ 2009-02-26 15:46 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-02-26 15:46 ` Ilya Yanok
@ 2009-02-26 16:19 ` Mark Jackson
2009-03-06 20:06 ` mpfj-list at mimc.co.uk
1 sibling, 0 replies; 8+ messages in thread
From: Mark Jackson @ 2009-02-26 16:19 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-02-26 15:46 ` Ilya Yanok
2009-02-26 16:19 ` Mark Jackson
@ 2009-03-06 20:06 ` mpfj-list at mimc.co.uk
2009-03-14 0:59 ` Ilya Yanok
1 sibling, 1 reply; 8+ messages in thread
From: mpfj-list at mimc.co.uk @ 2009-03-06 20:06 UTC (permalink / raw)
To: u-boot
> 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)
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-03-06 20:06 ` mpfj-list at mimc.co.uk
@ 2009-03-14 0:59 ` Ilya Yanok
2009-04-30 13:05 ` Mark Jackson
0 siblings, 1 reply; 8+ messages in thread
From: Ilya Yanok @ 2009-03-14 0:59 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [U-Boot] JFFS2 scanning bug
2009-03-14 0:59 ` Ilya Yanok
@ 2009-04-30 13:05 ` Mark Jackson
0 siblings, 0 replies; 8+ messages in thread
From: Mark Jackson @ 2009-04-30 13:05 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-04-30 13:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-25 13:07 [U-Boot] JFFS2 scanning bug Mark Jackson
2009-02-26 14:48 ` Ilya Yanok
2009-02-26 15:18 ` Mark Jackson
2009-02-26 15:46 ` Ilya Yanok
2009-02-26 16:19 ` Mark Jackson
2009-03-06 20:06 ` mpfj-list at mimc.co.uk
2009-03-14 0:59 ` Ilya Yanok
2009-04-30 13:05 ` Mark Jackson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.