In message A590D28B5042C041BCC880094CB6172E33DF45@mail1irv.inside.istor.com you wrote:

But it takes almost 2 minutes to scan the flash before the fsload completes and loads the uImage. So, this adds an additional 2 minutes

to

How big is your file system, and how heavily fragmented might it be (how long have you been using it, especially appending to existing files?). And which version of the MTD code are you using?

Charles comment to Wolfgang's comment:

It is a 16Mbyte flash partition consisting of a single file currently, which is uImage. There should be no fragmentation at all as the flash was formatted with 'flash_eraseall -j', then the kernel image was copied to it. No other writes, rm's or copies were done.

The issue becomes the customer desiring to have one root file system partition containing the uImage kernel and the contents of /bin, /sbin and the like. The single kernel file is just to test fsload.

the boot of the embedded system, which is clearly a problem.

Indeed. This is why I try to avoid loading a Linux kernel image from a JFFS2 file system (not to mention the fact that it makes little sense to compress and already compressed image - it just adds to the delay).

Charles comment to Wolfgang's comment:

So, would this mean that you would not expect U-Boot to do an fsload from a flash formatted with flash_eraseall in a timely fashion. Perhaps there is some inconsistency between the formatting of the flash in Linux and the reading of the flash in U-boot?

The flash was formatted in Linux using the flash_eraseall utility. I

am

hoping that you, or someone else, can tell me that there is some configuration constant missing or that the flash may be formatted in a way that is not quite consistent with U-Boot's needs.

There are a lot of potential causes. Enable debugging and check what's taking so much time...

Best regards,

Wolfgang Denk