Re: [U-Boot-Users] fsload questions
-----Original Message----- From: Stefan Roese [mailto:sr@denx.de] Sent: Thursday, December 21, 2006 11:18 AM To: u-boot-users@lists.sourceforge.net Cc: Charles Krinke; Randy Brown; Kevin Smith Subject: Re: [U-Boot-Users] fsload questions
On Thursday 21 December 2006 19:47, Charles Krinke wrote:
I8000E> bootm 100000 ## Booting image at 00100000 ... Image Name: Linux-2.6.17.11 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 936926 Bytes = 915 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... Error: inflate() returned -3 GUNZIP ERROR - must RESET board to recover
Use a bigger address (e.g. 0x400000) since the uncompressing can overwrite the original image.
Best regards, Stefan
Thank you Stefan, that cleared up one mystery. Given an offset of 0x1000000 instead of 0x100000, uImage can be loaded by fsload and will now bootm to a bash prompt.
This leaves the time question. It seems that the fsload starts out saying
Scanning JFFS2 FS
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 the boot of the embedded system, which is clearly a problem.
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.
Charles
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?
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).
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
participants (2)
-
Charles Krinke -
Wolfgang Denk