[U-Boot-Users] fsload questions

[U-Boot-Users] fsload questions

[Charles Krinke]

I have a setup with u-boot-1.1.6 with the nand/jffs2 subsystem enabled
and I have a flash that has been formatted with 'flash_eraseall -j
/dev/mtd0' in Linux. Additionally a PPC uImage for this 8241 target has
been put on the flash. At this point, I reboot, set the mtdids and
mtdparts and try an fsload and here is the result.

I8000E> setenv mtdids nand0=atx-0
I8000E> setenv mtdparts mtdparts=atx-0:16M at 0M(rootfs1)
I8000E> fsload
### JFFS2 loading 'uImage' to 0x100000
Scanning JFFS2 FS: - ...
read_nand_cached: error reading nand off 0xdfe200 size 8192 bytes
read_nand_cached: error reading nand off 0xdfe000 size 8192 bytes
read_nand_cached: error reading nand off 0xdffe00 size 8192 bytes
off = 0xdffff8 magic 0x0 type 0x0 node.totlen = 0
. done.
### JFFS2 load complete: 936990 bytes loaded to 0x100000
I8000E> md 0x100000
00100000: 27051956 6ed7fc8a 4587f48c 000e4bde    '..Vn...E.....K.
00100010: 00000000 00000000 dd803a34 05070201    ..........:4....
00100020: 4c696e75 782d322e 362e3137 2e313100    Linux-2.6.17.11.
...
I8000E> setenv bootargs root=/dev/nfs
nfsroot=192.168.56.27:/opt/82xxrootfs rw ip=192.168.56.190
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

So, this leads to a few questions:
1. Why might there be occaisional read_nand_cached errors?
2. Why does the load take 5 minutes?
3. Why does the load appear to complete successfully, the bootm start,
but then there is a GUNZIP error and the board reset?

Charles

[U-Boot-Users] fsload questions

[Stefan Roese]

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

[U-Boot-Users] fsload questions

[Charles Krinke]

-----Original Message-----
From: Stefan Roese [mailto:sr at denx.de] 
Sent: Thursday, December 21, 2006 11:18 AM
To: u-boot-users at 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

[U-Boot-Users] fsload questions

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our universe is a fragile house of atoms, held together by the mortar
of cause-and-effect. One magician would be two too many.
                        - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot-Users] fsload questions

[Charles Krinke]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Our universe is a fragile house of atoms, held together by the mortar
of cause-and-effect. One magician would be two too many.
                        - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot-Users] fsload questions

[Wolfgang Denk]

In message <A590D28B5042C041BCC880094CB6172E33DF46@mail1irv.inside.istor.com> you wrote:
> 
> 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,
....

May I recommend to
(1) read http://www.netmeister.org/news/learn2quote.html and stick to
the established quoting rules and
(2) please answer my questions?

Which version of the MTD code are you using?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anything free is worth what you pay for it.

[U-Boot-Users] fsload questions

[Charles Krinke]

Dear Wolfgang:

Our file system is a single Toshiba 256Mb NAND flash which has one
partition defined at the beginning (lowest address). 

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. of 16Mbytes in size. 
Best regards,

We are using the MTD code in the released u-boot-1.1.6 tarball and it
does compile cleanly and runs ls, fsinfo and fsload, albeit there is a
two minute delay whenever it runs.

I am very puzzled why you are avoiding loading a Linux kernel image from
a JFFS2 file system. Is there some set of problems that are not obvious
that need to be addressed, or some incompatibility between U-Boot and
the MTD flash logic in Linux?

I have enabled debugging and I can see that the scanning of the jffs2
starts at the bottom (lowest address) and works its way up. I also
enabled debugging in the Linux kernel and can see that it starts at the
top (highest address) and works its way towards the bottom.

It is beginning to appear the time is spent mostly in U-boot working its
way from the bottom of the flash to the top of the flash to find the
file system one block at a time, which is what appears to be taking the
two minutes. Perhaps you could comment on this.

Charles

[U-Boot-Users] fsload questions

[Wolfgang Denk]

In message <A590D28B5042C041BCC880094CB6172E33DF48@mail1irv.inside.istor.com> you wrote:
> 
> We are using the MTD code in the released u-boot-1.1.6 tarball and it
> does compile cleanly and runs ls, fsinfo and fsload, albeit there is a
> two minute delay whenever it runs.

Which MTD code are you using in your Linux kernel and for the tools
you use to format the file system?

How long does mounting the file system take under Linux?

> I am very puzzled why you are avoiding loading a Linux kernel image from
> a JFFS2 file system. Is there some set of problems that are not obvious

Because it's one of the slowest ways to boot a system.

> that need to be addressed, or some incompatibility between U-Boot and
> the MTD flash logic in Linux?

No, it's just inherently slow.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Where people stand is not as important as which way they face.
        - Terry Pratchett & Stephen Briggs, _The Discworld Companion_

[U-Boot-Users] fsload questions

[Charles Krinke]

-----Original Message-----
From: wd@denx.de [mailto:wd at denx.de] 
Sent: Thursday, December 21, 2006 4:40 PM
To: Charles Krinke
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] fsload questions 

In message
<A590D28B5042C041BCC880094CB6172E33DF48@mail1irv.inside.istor.com> you
wrote:
> 
> We are using the MTD code in the released u-boot-1.1.6 tarball and it
> does compile cleanly and runs ls, fsinfo and fsload, albeit there is a
> two minute delay whenever it runs.

Which MTD code are you using in your Linux kernel and for the tools
you use to format the file system?

How long does mounting the file system take under Linux?

> I am very puzzled why you are avoiding loading a Linux kernel image
from
> a JFFS2 file system. Is there some set of problems that are not
obvious

Because it's one of the slowest ways to boot a system.

> that need to be addressed, or some incompatibility between U-Boot and
> the MTD flash logic in Linux?

No, it's just inherently slow.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Where people stand is not as important as which way they face.
        - Terry Pratchett & Stephen Briggs, _The Discworld Companion_

Dear Wolfgang:

We are using Linux-2.6.17.11 with the MTD support provided in the
released kernel from kernel.org with no modifications. Is this
potentially a part of the problem?

I am somewhat puzzled by the fact that the Linux kernel writes files
from the top towards the bottom and U-Boot tries to read files from the
bottom towards the top. Is this potentially the reason for U-Boot's
slowness in reading a NAND/JFFS2 file system?

Charles

[U-Boot-Users] fsload questions

[Charles Krinke]

Dear Wolfgang:

In Linux, the same flash mounts in the blink of an eye. That is less
then 500ms. This is the reason that I have started focusing back on
U-Boot as there seems to be some incompatibility.

As said earlier, we are using kernel.orgs linux-2.6.17.11 kernel source.
We are also using Montavista 85xx toolchain to compile both the Linux
kernel and U-boot.

In formatting the flash, we use the utility flash_eraseall with a -j
option, like this from bash

# flash_eraseall -j /dev/mtd0
# mount -t jffs2 /dev/mtdblock0 /mnt/flash1

Charles