JFFS2 - speed up while booting

Ricard Wanderlof ricard.wanderlof at axis.com
Wed Jan 6 14:54:58 EST 2010


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.

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30



More information about the linux-mtd mailing list