[U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash
Hello,
I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash, partitioned into 3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB partition, and doesn't go searching in the others unless it's necessary.
The JFFS2 scan for this takes 1:45. I believe I followed all the instructions in the docs for setting up the NAND flash, and other than seeming to be really slow, it seems to operate just fine.
When I use nand write.jffs2 to write the image, it doesn't take nearly this long.
Has anyone else had a similar experience? Is there some configuration or other tip someone might be able to give me as to why this is so slow?
Thanks in advance,
Matt Gessner
Hi Matt,
I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash, partitioned into 3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB partition, and doesn't go searching in the others unless it's necessary.
The JFFS2 scan for this takes 1:45. I believe I followed all the instructions in the docs for setting up the NAND flash, and other than seeming to be really slow, it seems to operate just fine.
When I use nand write.jffs2 to write the image, it doesn't take nearly this long.
Has anyone else had a similar experience? Is there some configuration or other tip someone might be able to give me as to why this is so slow?
As mentioned several times on this mailing list, this is a "feature" of the data structures used by JFFS2. So as not to repeat myself too much, JFFS2 has to find the "current" data blocks for the files urging it to scan the whole partition.
A simple workaround - also mentioned a few times already - is to use a small partition for what is needed during booting.
Cheers Detlev
On Mon, 2007-10-15 at 12:32 +0200, Detlev Zundel wrote:
Hi Matt,
I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash, partitioned into 3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB partition, and doesn't go searching in the others unless it's necessary.
The JFFS2 scan for this takes 1:45. I believe I followed all the instructions in the docs for setting up the NAND flash, and other than seeming to be really slow, it seems to operate just fine.
When I use nand write.jffs2 to write the image, it doesn't take nearly this long.
Has anyone else had a similar experience? Is there some configuration or other tip someone might be able to give me as to why this is so slow?
As mentioned several times on this mailing list, this is a "feature" of the data structures used by JFFS2. So as not to repeat myself too much, JFFS2 has to find the "current" data blocks for the files urging it to scan the whole partition.
This is not entierly true. The scaning can be made much faster. There was/is a patch on the ML that improves the scaning speed significantly. Search for subject "jffs2 fsload - SOLVED" Not sure if that patch impl. reduced scanning of empty EBs, scanning all empty space is very time consuming.
Jocke
A simple workaround - also mentioned a few times already - is to use a small partition for what is needed during booting.
Cheers Detlev
Thank you both for your reply.
In my reading of the code [shudder] I pretty much came to the same conclusion: make the partition smaller.
Unfortunately for me, it's already as small as it can be. Because of the way that the field software updates occur, we need this space to be about 8MB. The image is currently a little under 3MB, but is going to grow as we add to it, and we need to keep two copies in the flash bank at one time during one point in the process. I suppose I could revisit the process, and make it require 4MB, which would (hopefully) halve the time I need.
I'll also check into the patch.
Thanks, both,
Regards,
Matt Gessner
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: Monday, October 15, 2007 8:44 AM To: Detlev Zundel Cc: u-boot-users@lists.sourceforge.net; Matt Gessner Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash
On Mon, 2007-10-15 at 12:32 +0200, Detlev Zundel wrote:
Hi Matt,
I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash,
partitioned
into
3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB partition, and doesn't go searching in the others unless it's
necessary.
The JFFS2 scan for this takes 1:45. I believe I followed all the instructions in the docs for setting up the NAND flash, and other
than
seeming to be really slow, it seems to operate just fine.
When I use nand write.jffs2 to write the image, it doesn't take
nearly
this long.
Has anyone else had a similar experience? Is there some
configuration
or other tip someone might be able to give me as to why this is so
slow?
As mentioned several times on this mailing list, this is a "feature" of the data structures used by JFFS2. So as not to repeat myself
too
much, JFFS2 has to find the "current" data blocks for the files
urging
it to scan the whole partition.
This is not entierly true. The scaning can be made much faster. There was/is a patch on the ML that improves the scaning speed significantly. Search for subject "jffs2 fsload - SOLVED" Not sure if that patch impl. reduced scanning of empty EBs, scanning all empty space is very time consuming.
Jocke
A simple workaround - also mentioned a few times already - is to use
a
small partition for what is needed during booting.
Cheers Detlev
------------------------------------------------------------------------ -
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
OK, more on this.
I don't have CFG_JFFS2_SORT_FRAGMENTS set, so I don't think this is the issue.
Linux *can* mount this partition, but it only does so when the software is being updated. The rest of the time, the system ignores this partition.
So, I'm wondering if the sorting is even an issue.
Any ideas?
Thanks,
Matt
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: Monday, October 15, 2007 8:44 AM To: Detlev Zundel Cc: u-boot-users@lists.sourceforge.net; Matt Gessner Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash
On Mon, 2007-10-15 at 12:32 +0200, Detlev Zundel wrote:
Hi Matt,
I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash,
partitioned
into
3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB partition, and doesn't go searching in the others unless it's
necessary.
The JFFS2 scan for this takes 1:45. I believe I followed all the instructions in the docs for setting up the NAND flash, and other
than
seeming to be really slow, it seems to operate just fine.
When I use nand write.jffs2 to write the image, it doesn't take
nearly
this long.
Has anyone else had a similar experience? Is there some
configuration
or other tip someone might be able to give me as to why this is so
slow?
As mentioned several times on this mailing list, this is a "feature" of the data structures used by JFFS2. So as not to repeat myself
too
much, JFFS2 has to find the "current" data blocks for the files
urging
it to scan the whole partition.
This is not entierly true. The scaning can be made much faster. There was/is a patch on the ML that improves the scaning speed significantly. Search for subject "jffs2 fsload - SOLVED" Not sure if that patch impl. reduced scanning of empty EBs, scanning all empty space is very time consuming.
Jocke
A simple workaround - also mentioned a few times already - is to use
a
small partition for what is needed during booting.
Cheers Detlev
------------------------------------------------------------------------ -
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a
browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
I am experiencing similar delays using an AMCC 440EP PowerPC and trying to boot Linux from the NAND flash via JFFS2. I initially had 16 MB partition devoted to booting the Linux kernel and found that he JFFS2 scan time took several minutes. Turning ON CFG_JFFS2_SORT_FRAGMENTS made matters even worse. I finally reduced the partition size dedicated to the Linux kernel down to 5 MB and the JFFS2 scan time is now ONLY 30 sec. Does anyone have any experience using YAFFS in a UBOOT environment? I have heard that the YAFFS file system does not suffer the long scan times of JFFS2. Can anyone confirm this rumor?
Daniel Batryn Shoretel Inc. 960 Stewart Sunnyvale, CA 94085 (408) 331-3575 Phone (408) 331-3333 Fax
|-----Original Message----- |From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- |bounces@lists.sourceforge.net] On Behalf Of Matt Gessner |Sent: Monday, October 15, 2007 8:50 AM |To: u-boot-users@lists.sourceforge.net |Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash | |OK, more on this. | |I don't have CFG_JFFS2_SORT_FRAGMENTS set, so I don't think this is the |issue. | |Linux *can* mount this partition, but it only does so when the software |is being updated. The rest of the time, the system ignores this |partition. | |So, I'm wondering if the sorting is even an issue. | |Any ideas? | |Thanks, | |Matt | |> -----Original Message----- |> From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- |> bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund |> Sent: Monday, October 15, 2007 8:44 AM |> To: Detlev Zundel |> Cc: u-boot-users@lists.sourceforge.net; Matt Gessner |> Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash |> |> On Mon, 2007-10-15 at 12:32 +0200, Detlev Zundel wrote: |> > Hi Matt, |> > |> > > I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash, |partitioned |> into |> > > 3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB |> > > partition, and doesn't go searching in the others unless it's |> necessary. |> > > |> > > The JFFS2 scan for this takes 1:45. I believe I followed all the |> > > instructions in the docs for setting up the NAND flash, and other |than |> > > seeming to be really slow, it seems to operate just fine. |> > > |> > > When I use nand write.jffs2 to write the image, it doesn't take |nearly |> > > this long. |> > > |> > > Has anyone else had a similar experience? Is there some |configuration |> > > or other tip someone might be able to give me as to why this is so |> slow? |> > |> > As mentioned several times on this mailing list, this is a "feature" |> > of the data structures used by JFFS2. So as not to repeat myself |too |> > much, JFFS2 has to find the "current" data blocks for the files |urging |> > it to scan the whole partition. |> |> This is not entierly true. The scaning can be made much faster. |> There was/is a patch on the ML that improves the scaning speed |> significantly. Search for subject "jffs2 fsload - SOLVED" |> Not sure if that patch impl. reduced scanning of empty EBs, scanning |> all empty space is very time consuming. |> |> Jocke |> |> > |> > A simple workaround - also mentioned a few times already - is to use |a |> > small partition for what is needed during booting. |> > |> > Cheers |> > Detlev |> > |> |> |----------------------------------------------------------------------- - |- |> This SF.net email is sponsored by: Splunk Inc. |> Still grepping through log files to find problems? Stop. |> Now Search log events and configuration files using AJAX and a |browser. |> Download your FREE copy of Splunk now >> http://get.splunk.com/ |> _______________________________________________ |> U-Boot-Users mailing list |> U-Boot-Users@lists.sourceforge.net |> https://lists.sourceforge.net/lists/listinfo/u-boot-users | |----------------------------------------------------------------------- -- |This SF.net email is sponsored by: Splunk Inc. |Still grepping through log files to find problems? Stop. |Now Search log events and configuration files using AJAX and a browser. |Download your FREE copy of Splunk now >> http://get.splunk.com/ |_______________________________________________ |U-Boot-Users mailing list |U-Boot-Users@lists.sourceforge.net |https://lists.sourceforge.net/lists/listinfo/u-boot-users CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may be protected by legal privilege and/or are otherwise exempt from disclosure. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system.
On two custom designs (ARM and PPC based) we switched from JFFS to YAFFS after experiencing the same problem. Now we use YAFFS in U-Boot and Linux.
Since YAFFS is very fast we saw no reason to partition the device and we have one partition on 1 and 2 GB respectively. The scan/mount times are almost negligible when using checkpoints. Without checkpoints we are still experiencing scan/mount times below/around 1s.
Implementing YAFFS on U-boot and Linux we had problems configuring YAFFS/MTD in such a way that we could use the same partition in both places. That made us upgrade MTD in U-boot to correspond with our version of Linux. I will suggest an upgrade of U-boot MTD in a separate thread. However, if you are only using a boot-partition from U-boot you should not experience such problems.
Best regards William ------------------------------------------------- William Juul, Senior Development Engineer Data Respons Norge AS Sandviksveien 26 P.O. Box 489 NO-1323 Høvik, Norway
Tel: +47 67 11 20 00 Fax: +47 67 11 20 50 Dir: +47 67 11 20 26 Mob: +47 95 79 32 53
www.datarespons.no -------------------------------------------------
On 10/15/07, Dan Batryn DBatryn@shoretel.com wrote:
I am experiencing similar delays using an AMCC 440EP PowerPC andtrying to boot Linux from the NAND flash via JFFS2. I initially had 16 MB partition devoted to booting the Linux kernel and found that he JFFS2 scan time took several minutes. Turning ON CFG_JFFS2_SORT_FRAGMENTS made matters even worse. I finally reduced the partition size dedicated to the Linux kernel down to 5 MB and the JFFS2 scan time is now ONLY 30 sec. Does anyone have any experience using YAFFS in a UBOOT environment? I have heard that the YAFFS file system does not suffer the long scan times of JFFS2. Can anyone confirm this rumor?
Daniel Batryn Shoretel Inc. 960 Stewart Sunnyvale, CA 94085 (408) 331-3575 Phone (408) 331-3333 Fax
|-----Original Message----- |From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- |bounces@lists.sourceforge.net] On Behalf Of Matt Gessner |Sent: Monday, October 15, 2007 8:50 AM |To: u-boot-users@lists.sourceforge.net |Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash | |OK, more on this. | |I don't have CFG_JFFS2_SORT_FRAGMENTS set, so I don't think this is the |issue. | |Linux *can* mount this partition, but it only does so when the software |is being updated. The rest of the time, the system ignores this |partition. | |So, I'm wondering if the sorting is even an issue. | |Any ideas? | |Thanks, | |Matt | |> -----Original Message----- |> From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users- |> bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund |> Sent: Monday, October 15, 2007 8:44 AM |> To: Detlev Zundel |> Cc: u-boot-users@lists.sourceforge.net; Matt Gessner |> Subject: Re: [U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash |> |> On Mon, 2007-10-15 at 12:32 +0200, Detlev Zundel wrote: |> > Hi Matt, |> > |> > > I'm got an AT91RM9200 and an 16 MB ST Micro NAND flash, |partitioned |> into |> > > 3 blocks of 8, 4 and 4 MB. U-boot boots linux from the first 8MB |> > > partition, and doesn't go searching in the others unless it's |> necessary. |> > > |> > > The JFFS2 scan for this takes 1:45. I believe I followed all the |> > > instructions in the docs for setting up the NAND flash, and other |than |> > > seeming to be really slow, it seems to operate just fine. |> > > |> > > When I use nand write.jffs2 to write the image, it doesn't take |nearly |> > > this long. |> > > |> > > Has anyone else had a similar experience? Is there some |configuration |> > > or other tip someone might be able to give me as to why this is so |> slow? |> > |> > As mentioned several times on this mailing list, this is a "feature" |> > of the data structures used by JFFS2. So as not to repeat myself |too |> > much, JFFS2 has to find the "current" data blocks for the files |urging |> > it to scan the whole partition. |> |> This is not entierly true. The scaning can be made much faster. |> There was/is a patch on the ML that improves the scaning speed |> significantly. Search for subject "jffs2 fsload - SOLVED" |> Not sure if that patch impl. reduced scanning of empty EBs, scanning |> all empty space is very time consuming. |> |> Jocke |> |> > |> > A simple workaround - also mentioned a few times already - is to use |a |> > small partition for what is needed during booting. |> > |> > Cheers |> > Detlev |> > |> |> |-----------------------------------------------------------------------
|- |> This SF.net email is sponsored by: Splunk Inc. |> Still grepping through log files to find problems? Stop. |> Now Search log events and configuration files using AJAX and a |browser. |> Download your FREE copy of Splunk now >> http://get.splunk.com/ |> _______________________________________________ |> U-Boot-Users mailing list |> U-Boot-Users@lists.sourceforge.net |> https://lists.sourceforge.net/lists/listinfo/u-boot-users | |----------------------------------------------------------------------- -- |This SF.net email is sponsored by: Splunk Inc. |Still grepping through log files to find problems? Stop. |Now Search log events and configuration files using AJAX and a browser. |Download your FREE copy of Splunk now >> http://get.splunk.com/ |_______________________________________________ |U-Boot-Users mailing list |U-Boot-Users@lists.sourceforge.net |https://lists.sourceforge.net/lists/listinfo/u-boot-users CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may be protected by legal privilege and/or are otherwise exempt from disclosure. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system.
This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On 13:55 Wed 17 Oct , William Juul wrote:
On two custom designs (ARM and PPC based) we switched from JFFS to YAFFS after experiencing the same problem. Now we use YAFFS in U-Boot and Linux.
Since YAFFS is very fast we saw no reason to partition the device and we have one partition on 1 and 2 GB respectively. The scan/mount times are almost negligible when using checkpoints. Without checkpoints we are still experiencing scan/mount times below/around 1s.
Implementing YAFFS on U-boot and Linux we had problems configuring YAFFS/MTD in such a way that we could use the same partition in both places. That made us upgrade MTD in U-boot to correspond with our version of Linux. I will suggest an upgrade of U-boot MTD in a separate thread. However, if you are only using a boot-partition from U-boot you should not experience such problems.
An other file system is faster than YAFFS, it's LOGFS which is accepted to be integradted in the kernel tree.
Best Regards
J.
In message 20071017110752.GA16656@game.jcrosoft.org you wrote:
An other file system is faster than YAFFS, it's LOGFS which is accepted to be integradted in the kernel tree.
Patches welcome...
Also for UBI, while we are at this...
Best regards,
Wolfgang Denk
participants (7)
-
Dan Batryn -
Detlev Zundel -
Jean-Christophe PLAGNIOL-VILLARD -
Joakim Tjernlund -
Matt Gessner -
William Juul -
Wolfgang Denk