Hi Ian,

> On Tuesday 14 August 2007 11:45, Raj Kumar Yadav wrote:
> > 1) Now on unmount the ~450MB partition, on one particular block the
> > NAND verify failed,
> > but the YAFFS did not write the data of the block into some other
> > block. And during the next mount, it took time more(15second) than
> > expected (~1sec).
>
> I just looked at the checkpoint code and there is no test of the
> return code from dev->writeChunkWithTagsToNAND() called by
> yaffs_CheckpointFlushBuffer().  So it won't notice the write failure.
> Not sure if this is intentional or not -- perhaps a failure during
> checkpoint is just that, and the next mount has to do a full scan.

Thanks for the clarification.

> > 2) It is found that
> > the block on which NAND verify failed, is
> > actually bad, as I am unable to erase/write on that block
> > using nand-utils or the custom bootloader commands.
> >
> > NAND Controller shows status as success after erase/write.
> >
> > But after the erase, all bytes on the 1st, 3rd, 5th, ... page
> > are 0xFF. and all bytes on the 2nd, 4th, 6th,... page are
> > 0x00.
> >
> > Similarily, writing data pattern on any of the pages in that
> > block have no effect on the page data.
> >
> > This also means that, I cannot mark the block bad, as the
> > first page is all 0xff and nand write on the page has no
> > effect on page data.
> >
> > So, it is ending up in a situation, where the block will never
> > be marked bad, and the write will always fail (due to MTD NAND
> > verify) on the block pages.

> Perhaps you could try posting this question to the linux-mtd.
> The ARM Linux list is also a good place to ask for platform
> specific (NAND controller) help.

I have asked about it in the linux-mtd mailing list, David Woodhouse suggested
to use the 'bad block table' policy provided in MTD layer to keep the
track of such
blocks. Addition to the 'bbt' can be made on every nand verify failure
(even after the applied ECC correction).


Thanks,
Raj Kumar Yadav