mtd-utils/nandwrite: what if write fails?

[Ricard Wanderlof]

On Tue, 17 Oct 2006, Artem Bityutskiy wrote:

>On Tue, 2006-10-17 at 16:17 +0200, Ricard Wanderlof wrote:
>> I have a question regarding writes to NAND flash; for instance, in 
>> mtd-utils/nandwrite.c, prior to writing to a block, it is checked so that 
>> it isn't bad (using the MEMGETBADBLOCK ioctl). However, what happens if 
>> the block goes bad during write? If the pwrite() call which writes out the 
>> page data fails, the application says perror() and exits. Shouldn't it 
>> mark the block as bad, and re-write the data so far written to the block 
>> to the next good block? 
>
> If we are talking about nandwrite - I would prefer it not to do this. Or 
> do this if an this was specified via an explicit option ...

I could live with an option.

>> As I understand it, mtd doesn't mark a block bad,
>> it is up to the application or overlying file system (e.g. JFFS2).
>
> Yes, not only JFFS2, just any software which works on top of MTD and 
> knows what it does. For example, UBI can do this. Or some user-space 
> tools.

I assume that the mtd block devices don't provide any bad block management 
either? (Hm, one could imagine a device which when written to simply 
skipped bad blocks ... ?)

>> So it won't even help to run nandwrite again as the block has not been 
>> marked bad.
>
> Not sure, put probably yes. You may explore fix this adding a 
> corresponding option to nandwrite. Or you may write an utility which 
> does flash torturing and identifies bad eraseblocks, e.g., flash_check. 
> [...] but I personally used it only for debugging purposes.

I would like to use it for writing filesystem images to nand flash, i.e. a 
more production-oriented environment. Either during initial production, or 
during upgrades. So some form of (perhaps option-controlled) bad block 
management would be nice.

A torture test would be nice too, but it's not really the same thing. 
Blocks can go bad with time, and when one actually does go bad, it has to 
be handled at that time.

Another option would be to integrate erasure into nandwrite, so that it 
could erase blocks prior to writing them, to give a completely integrated 
utility. Writing to a non-erased (nand) flash is rather pointless anyway 
isn't it? Naturally, one would want to set limits for the erasure so that 
not the whole flash would have to be erased just to write a small image.

One would still have to handle the case of erase or write failing though.

/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