Re: [Yaffs] yaffs failure on writing to a bad block

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: ian@brightstareng.com
Date:  
To: yaffs
Subject: Re: [Yaffs] yaffs failure on writing to a bad block
Raj,

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.

> 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.
>
> Does anybody faces similar problem, please suggest any
> solution.


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.

-imcd