[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
--
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