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

[Sebastian Andrzej Siewior]

* Ricard Wanderlof | 2009-03-26 16:54:21 [+0100]:

> 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 

okay. So providing clean-markers is here a one-time optimization.


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

>
> 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).

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. 


> /Ricard
Sebastian