Mini2440 - kernel 3.6 - JFFS2 takes a lot of time

Hello,

I'm using PTXDIST BSP in mini2440 64MB RAM & 256 NAND.
When the kernel initialize, it takes a lot of time mounting JFFS2 FS.
Sometimes more than 2 minutes and other times it stuck in this step.
This is random Behavior and it occurs a lot of times.

Do you know how can I do for accelerate this step ?

Thank you.

There is the kernel load log:

............
............
lib80211: common routines for IEEE802.11 drivers
input: gpio-keys as /devices/platform/gpio-keys/input/input2
s3c-rtc s3c2410-rtc: setting system clock to 2013-09-12 10:03:47 UTC
(1378980227)
dm9000 dm9000: eth0: link down
dm9000 dm9000: eth0: link down
usb 1-1: new full-speed USB device number 2 using s3c2410-ohci
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.4: new full-speed USB device number 3 using s3c2410-ohci
------------ A LOT OF TIME -------------------------------------
------------ A LOT OF TIME -------------------------------------
------------ A LOT OF TIME -------------------------------------
jffs2: Empty flash at 0x02cf1c10 ends at 0x02cf2000
jffs2: Empty flash at 0x0c367e68 ends at 0x0c368000
jffs2: Empty flash at 0x0c37c550 ends at 0x0c37c800
VFS: Mounted root (jffs2 filesystem) on device 31:3.
devtmpfs: mounted
........
........

Have you got an external USB hub attached to it?

Just to confirm, which selected_platformconfig option are you using? 
Specifically, PTXCONF_BAREBOX_CONFIG

Thank you Dave.

No, I don't.
I have a usb hub inside the board.

BAREBOX_CONFIG [=barebox-NAND-128M.config]
(2013-05-0) barebox version
(mini2440) platform name  
(-2012.12.0) platform version

I just can guess what happens in your target:

 - worn out flash with many (but correctible) bit errors
 - slow data transmission between NAND and CPU

Disable USB and other features in your kernel and keep flash support
enabled. Try this kernel, if the long pause really happens due to NAND
flash access.

I've got  to the conclusion that the problem is due to the network
initialization.
Even do set "ip=none" in kernel parameters, the kernel always try to get ip
by dhcp.
So I add to linux-3.6/net/ipv4/ipconfig.c file a "return 0" statement in
the beginning. By this way the kernel doesn't try to get ip.

I'm having a lot of problems with DM9000cep ethernet chip (reset problems,
identificator read problems, .... ).

On the other hand I have a very strange behaviour. I'm using "ifplugd"
daemon for controlling the link status of the ETH and WLAN.
But when I run ifplugd, the backlight of the touchscreen turn off and I
can't turn on it again. Only if I kill ifplugd daemon, I can turn  on/off
the backlight  again.

Do you know why this could be happen?

Longer time ago Dave reported a strange behaviour when no network
connection is available. I never noticed that, because I'm always using my
Mini2440 with network attached.
It seems the DM9000 driver cannot handle the no-network case correctly and
always needs much time to timeout.
Needs some effort to find out what is wrong with the driver.