[RFC/PATCH] flash_eraseall: extra care if NOR flash is not BIT_WRITEABLE
Sebastian Andrzej Siewior
sebastian at breakpoint.cc
Sun Apr 5 15:43:35 EDT 2009
* 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
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.
More information about the linux-mtd