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

[Ricard Wanderlof]

On Thu, 26 Mar 2009, Sebastian Andrzej Siewior wrote:

> I'm sorry. That is actually my point. The layout of the cleanmarker 
> (which are used only by JFFS2) depends on a specific kernel switch in 
> case of NOR flash which is not BIT_WRITEABLE and userland can't know 
> that. I've sent a patch to remove the -j option because the generated 
> cleanmaker *may* be wrong. Artem replied that he would like to see this 
> fixed. So here is an attempt to fix this: black listed ubi & data flash 
> but I dunno how fix the NOR case where does not have BIT_WRITEABLE bit. 
> A commandline switch for those who know what they do? Why don't rip out 
> -j and let the kernel create clean marker if it needs it?

There can be a performance benefit to having the image contain 
cleanmarkers rather than the kernel having to do it. Specifically, if a 
cleanmarker is missing, the kernel doesn't know if it's because it's a 
virgin image or because a previous erase failed (typically because of a 
power fail during 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.

For a given application it may be possible to skip the 
erase-before-writing-cleanmarker, but in the general case it is necessary, 
which slows system startup (the flash cannot be used while it is being 
erased).

/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