NAND bad blocks

NAND bad blocks

[J.D. Bakker]

Hi all,

There's a slight discrepancy between what mtd and mkyaffs consider a bad block.

 From mtd/drivers/mtd/nand/nand.c:

   static int nand_block_bad(struct mtd_info *mtd, unsigned long page)
   {
         struct nand_chip *this = mtd->priv;

         this->cmdfunc (mtd, NAND_CMD_READOOB, NAND_BADBLOCK_POS, page);
         if (this->read_byte(mtd) != 0xff)
                 return 1;

         return 0;
   }

...which would indicate that even one bit set to zero would mark the 
block bad. However, mkyaffs.c has this code:

   /* Read the OOB data to determine if the block is valid.
    * If the block is damaged, then byte 5 of the OOB data will
    * have at least 2 zero bits.
    */

..snip..

   if(countBits[oobbuf[5]] < 7)
   {
	printf("Block at 0x08%lx is damaged and is not being 
formatted\n",addr);
   }

So, which is it ?

JDB
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: NAND bad blocks

[Thomas Gleixner]

On Thursday 15 April 2004 18:39, J.D. Bakker wrote:
> Hi all,
>
> There's a slight discrepancy between what mtd and mkyaffs consider a bad
> block.
> ...which would indicate that even one bit set to zero would mark the
> block bad. However, mkyaffs.c has this code:
>
>    /* Read the OOB data to determine if the block is valid.
>     * If the block is damaged, then byte 5 of the OOB data will
>     * have at least 2 zero bits.
>     */

Thats hard to say, as the datasheets tell different stories.
But most of them say, that any bit set to zero marks the block bad

-- 
Thomas
________________________________________________________________________
"Free software" is a matter of liberty, not price. To understand the concept,
you should think of "free" as in "free speech,'' not as in "free beer".
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de

Re: NAND bad blocks

[Charles Manning]

On Friday 16 April 2004 04:39, J.D. Bakker wrote:
> Hi all,
>
> There's a slight discrepancy between what mtd and mkyaffs consider a bad
> block.
>
>  From mtd/drivers/mtd/nand/nand.c:
>
>    static int nand_block_bad(struct mtd_info *mtd, unsigned long page)
>    {
>          struct nand_chip *this = mtd->priv;
>
>          this->cmdfunc (mtd, NAND_CMD_READOOB, NAND_BADBLOCK_POS, page);
>          if (this->read_byte(mtd) != 0xff)
>                  return 1;
>
>          return 0;
>    }
>
> ...which would indicate that even one bit set to zero would mark the
> block bad. However, mkyaffs.c has this code:
>
>    /* Read the OOB data to determine if the block is valid.
>     * If the block is damaged, then byte 5 of the OOB data will
>     * have at least 2 zero bits.
>     */
>
> ..snip..
>
>    if(countBits[oobbuf[5]] < 7)
>    {
> 	printf("Block at 0x08%lx is damaged and is not being
> formatted\n",addr);
>    }

The idea with the bit counting in YAFFS is to prevent a single bad bit 
causing a block to be erroneously marked bad, thereby losing your data.

In reality this situation hardly ever, if ever, arises and the two code 
sequences are pretty much equivalent.

-- Charles

Re: NAND bad blocks

[J.D. Bakker]

At 10:35 AM +1200 16/4/04, Charles Manning wrote:
>On Friday 16 April 2004 04:39, J.D. Bakker wrote:

[Recap: I noticed that mtd considers a NAND block to be bad if byte 5 
of the OOB data has one or more zero-bits in it; YAFFS looks for two 
or more zero-bits before considering a block to be damaged]

>The idea with the bit counting in YAFFS is to prevent a single bad bit
>causing a block to be erroneously marked bad, thereby losing your data.

Fair enough, but...

>In reality this situation hardly ever, if ever, arises and the two code
>sequences are pretty much equivalent.

I have a Flash device which has a block which triggers this boundary 
condition, resulting in a

"nand_erase: attempt to erase a bad block at page 0x00000420"

when running mkyaffs.

Maybe it would be a good idea to have mkyaffs be more conservative, 
ie adhere to the 'one strike out' policy when erasing a chip. 
Something like:

   if(oobbuf[5] != 0xFF)
   {
     oobbuf[5] = BAD_BLOCK_MARKER_WHICH_IS_ACCEPTED_BY_BOTH_MTD_AND_YAFFS;
     write_oob_to_nand(oobbuf);
   }

Does that look reasonable ? I'd expect it to be likely for a block 
with a single-bit error in the OOB to be going bad RSN anyway; might 
as well mark it bad when there's no user data to be lost.

JDB
[yes, I know, -ENOPATCH. Excuses:
* I don't know the NAND code well enough to pick a good value for 
BAD_BLOCK_MARKER
* it's WAY past my bedtime, especially since the UPS guy has a nice 
little wake-up call planned for me]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/