JFFS2 - speed up while booting

Joakim Tjernlund joakim.tjernlund at transmode.se
Wed Jan 6 16:24:47 EST 2010



hedwin <hedwin.koning at gmail.com> wrote on 06/01/2010 22:16:27:
>
> Interesting, when was this added to JFFS2? Need to catch up a bit I guess.
>
Please don't top post.

This isn't in JFFS2(yes). Basically the empty check need to be move to the chip driver.
Then the driver knows if the chip has a blank check command and use that or fall
back to old method.

Alternatively one could export a Blank Check command from the driver and
test for it in JFFS2.

> On Wed, Jan 6, 2010 at 9:59 PM, Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
> Ricard Wanderlof <ricard.wanderlof at axis.com> wrote on 06/01/2010 20:54:58:
> >
> >
> > On Tue, 5 Jan 2010, Joakim Tjernlund wrote:
> >
> > >> The real reason for the long delay is not the erase time, but the time to
> > >> validate that the erase actually worked and that all the data is 0xff.
> > >> If you comment out the jffs2_block_check_erase function below
> > >> as shown, then in my case, the 4.5 minute pdflush delay dropped to 2-3
> > >> seconds! I was using a 16Gbit large page flash for this test.
> > >
> > > Ah, that make sense. Some new NOR parts form Numonyx has a new CFI command,
> > > Blank Check, that indicates if it is all ones or not. That could be handy
> > > to use in this case. You could even use that instead of erasing empty
> > > block because they miss a clean marker.
> >
> > It is my understanding that the reason the blocks are erased when no
> > cleanmarker is found, is that a potentially uncompleted previous erase may
> > have left the block in an appearantly erased state, making future
> > programming unreliable unless the block is erased properly. So the blocks
> > would still have to be erased, but of course the checking function (which
> > seems to be the main reason for the delay) could be considerably
> > optimized.

> I know but from a quick reading of the blank check feature, you don't have to.
> The blank check is reliable w.r.t power loss and such. Seems like it
> was designed for this purpose.
>
>  Jocke
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




More information about the linux-mtd mailing list