[RFC/PATCH] flash_eraseall: extra care if NOR flash is not BIT_WRITEABLE

Ricard Wanderlof ricard.wanderlof at axis.com
Mon Apr 6 04:09:37 EDT 2009

On Sun, 5 Apr 2009, Sebastian Andrzej Siewior wrote:

>> erase). In the case of a failed erase, the sector might not be properly
>> erased (i.e. even though the bytes might read 0xFF they might not be
>> properly erase, resulting in spurious bitflips later). So, the kernel must
>> erase the sector (which for a NOR flash is a slow operation) before writing
>> the cleanmarker.
> and this can happen anyway so your clean-marker support in
> flash_eraseall does not help here.

Yes, it can happen anyway, but if there are no cleanmarkers in the image, 
you get a performance penalty on every boot from a virgin image. While 
not often in the course of a product's lifetime, imagine someone 
upgrading a bunch of identical products, the rewriting of cleanmarkers can 
make the boot after each upgrade much slower, thus significantly 
increasing the upgrade time. Similarly in production, where time is a 
premium, any lengthening of the product boot time (e.g. before final 
testing) is bad.

Of course, it must still be present in the kernel to handle the case of 
failed erase, but that doesn't it stop it from being very handy in 
flash_eraseall as well.

One thing that would be handy would be if one could give a 
"jffs2-cleanmarker" flag to the erase ioctl which would automatically 
write a cleanmarker after erasing the block, in accordance with the custom 
of the day for the particular kernel version in question. However, apart 
from the fact that it may be difficult to extend the ioctl functionality, 
mixing driver levels (i.e. mtd and jffs2) in this way is probably not 
considered too clean.

> Please don't get me wrong. I don't want to rip clean-markers out from
> jffs2. I just thought, that it is enough to have it in kernel since it is
> the only place where the final layout is known.

I didn't misunderstand you. I just want to argue that putting down 
cleanmarkers when the flash is erased rather than later is an optimization 
that can be useful in practice.

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