[U-Boot-Users] U-boot 1.2.0 JFFS2, and NAND flash

[Matt Gessner]

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 at lists.sourceforge.net [mailto:u-boot-users-
> bounces at lists.sourceforge.net] On Behalf Of Joakim Tjernlund
> Sent: Monday, October 15, 2007 8:44 AM
> To: Detlev Zundel
> Cc: u-boot-users at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users