JFFS2 - speed up while booting

[Joakim Tjernlund]

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