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