[Yaffs1] mkyaffs exits with "MTD Erase failure"

[Yaffs1] mkyaffs exits with "MTD Erase failure"

[Martin Egholm Nielsen]

Hi,

I have run into a problem: By "accident", we changed the die of our NAND 
  without paying attention to the new timing parameters.
Hence, the read-operation (with fixed timing!) reported ready before 
data was actually ready on the NAND. Consequently, this caused checksum 
errors, and several blocks was erroneously marked bad!

So, I fixed the timing in the kernel and tried erasing the flash again. 
But with no luck - mkyaffs refuses to erase/program the flash:

# flash_eraseall /dev/mtd0
....
Skipping bad block at 0x0179c000
Erasing 16 Kibyte @ 1ffc000 -- 99 % complete.
# mkyaffs -e /dev/mtd0
argc 3 sh 0 optcnt 2
Erasing and programming NAND
Erasing block at 0x080
Erasing block at 0x084000
...
Erasing block at 0x0874000
nand_erase: attempt to erase a bad block at page 0x000004e0

Erasing block at 0x087c000
...
Erasing block at 0x089c000

MTD Erase failure
: Input/output error
#


And then my question - why do I get the I/O error?

BR,
  Martin Egholm

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Ricard Wanderlof]

On Mon, 4 Jun 2007, Martin Egholm Nielsen wrote:

> I have run into a problem: By "accident", we changed the die of our NAND
>  without paying attention to the new timing parameters.
> Hence, the read-operation (with fixed timing!) reported ready before
> data was actually ready on the NAND. Consequently, this caused checksum
> errors, and several blocks was erroneously marked bad!
>
> So, I fixed the timing in the kernel and tried erasing the flash again.
> But with no luck - mkyaffs refuses to erase/program the flash:

Mtd refuses to erase blocks that have been marked bad. There is no 
workaround on a running kernel, but it is possible to patch the kernel to
do this.

The patch depends on whether or not you have a flash-based bad block 
table. Most do, but my only experience has been without the flash-based 
BBT. In this case, you simply remove the if clause around 
nand_block_checkbad() in mtd/nand/nand_base:nand_erase_nand(), recompile, 
and use that kernel to erase the blocks that have accidentally been marked 
bad.

If you're using a flash-based BBT you need to fiddle with the table to 
unmark the bad blocks. Probably not too difficult, but I've never done 
that myself. AFAIK, mtd doesn't mark the actual blocks as bad, so you 
don't need to erase the bad block markers in the offending blocks in this 
case, only clear the blocks in the BBT.

/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

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Martin Egholm Nielsen]

Hi,

Ricard Wanderlof wrote:
> On Mon, 4 Jun 2007, Martin Egholm Nielsen wrote:
>> I have run into a problem: By "accident", we changed the die of our
>> NAND without paying attention to the new timing parameters. Hence,
>> the read-operation (with fixed timing!) reported ready before data
>> was actually ready on the NAND. Consequently, this caused checksum 
>> errors, and several blocks was erroneously marked bad!
>> 
>> So, I fixed the timing in the kernel and tried erasing the flash
>> again. But with no luck - mkyaffs refuses to erase/program the
>> flash:

> Mtd refuses to erase blocks that have been marked bad. There is no 
> workaround on a running kernel, but it is possible to patch the
> kernel to do this.

But as you see, flash_eraseall on the same device works perfectly fine:

flash_eraseall /dev/mtd0
....
Skipping bad block at 0x0179c000
Erasing 16 Kibyte @ 1ffc000 -- 99 % complete.


> The patch depends on whether or not you have a flash-based bad block
> table. Most do, but my only experience has been without the
> flash-based BBT. In this case, you simply remove the if clause around
> nand_block_checkbad() in mtd/nand/nand_base:nand_erase_nand(),
> recompile, and use that kernel to erase the blocks that have
> accidentally been marked bad.

I have a kernel with this patch, yes - and it does work. However, then I 
remove the factory-marked ones, as well. Not a good idea!


// Egholm

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Ricard Wanderlof]

On Mon, 4 Jun 2007, Martin Egholm Nielsen wrote:

>>> So, I fixed the timing in the kernel and tried erasing the flash
>>> again. But with no luck - mkyaffs refuses to erase/program the
>>> flash:
>
>> Mtd refuses to erase blocks that have been marked bad. There is no
>> workaround on a running kernel, but it is possible to patch the
>> kernel to do this.
>
> But as you see, flash_eraseall on the same device works perfectly fine:
>
> flash_eraseall /dev/mtd0
> ....
> Skipping bad block at 0x0179c000
> Erasing 16 Kibyte @ 1ffc000 -- 99 % complete.

flash_eraseall skips bad blocks while erasing. I don't know how mkyaffs 
works though.

>> The patch depends on whether or not you have a flash-based bad block
>> table. Most do, but my only experience has been without the
>> flash-based BBT. In this case, you simply remove the if clause around
>> nand_block_checkbad() in mtd/nand/nand_base:nand_erase_nand(),
>> recompile, and use that kernel to erase the blocks that have
>> accidentally been marked bad.
>
> I have a kernel with this patch, yes - and it does work. However, then I 
> remove the factory-marked ones, as well. Not a good idea!

You can always re-mark the factory bad ones, given that you have written 
down which they were once... if you are using a flash-based BBT, erasing 
the BBT blocks would suffice, as the bad block management in jffs2 when 
using a flash-based BBT doesn't touch bad block markers. I would assume 
from your reasoning that you are not using a flash-based BBT?

In a lab environment, erasing the factory-marked bad blocks will probably 
work well enough not to cause a hassle, as long as you don't use the flash 
for long-term storage.

/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

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Martin Egholm Nielsen]

Hi,

Ricard Wanderlof wrote:
> On Mon, 4 Jun 2007, Martin Egholm Nielsen wrote:
>>>>So, I fixed the timing in the kernel and tried erasing the flash
>>>>again. But with no luck - mkyaffs refuses to erase/program the
>>>>flash:

>>>Mtd refuses to erase blocks that have been marked bad. There is no
>>>workaround on a running kernel, but it is possible to patch the
>>>kernel to do this.

>>But as you see, flash_eraseall on the same device works perfectly fine:
>>flash_eraseall /dev/mtd0
>>....
>>Skipping bad block at 0x0179c000
>>Erasing 16 Kibyte @ 1ffc000 -- 99 % complete.

> flash_eraseall skips bad blocks while erasing. I don't know how mkyaffs 
> works though.

Well, glancing at the code, it should be doing something like it:

==== ORIGINAL mkyaffs.c ====
for(addr = 0; addr < meminfo.size; addr += meminfo.erasesize)
{
   /* 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.
    */
   oob.start = addr;
   oob.length = 16;
   oob.ptr = oobbuf;
   if (ioctl(fd, MEMREADOOB, &oob) != 0)
   {
     perror("ioctl(MEMREADOOB)");
     close(fd);
     exit(1);
   }

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

However, it doesn't seem to do the trick. So I copied the check from 
"flash_eraseall" and put in, as well:

==== NEW mkyaffs.c ====
for(addr = 0; addr < meminfo.size; addr += meminfo.erasesize)
{
   /* MEN 2007-06-06 */
   loff_t bah = addr;
   int ret = ioctl(fd, MEMGETBADBLOCK, &bah);
   if (ret > 0)
   {
     printf( "Block at 0x08%lx would have been ignored by 
flash_eraseall!\n", addr );
     continue;
   } // if

   // OLD CODE HERE
=======================


And now it seems to work:

# mkyaffs-hacked-2007-06-06 -e /dev/mtd0
argc 3 sh 0 optcnt 2
Erasing and programming NAND
Erasing block at 0x080
Erasing block at 0x084000
...
Erasing block at 0x0898000
Block at 0x089c000 would have been ignored by flash_eraseall!
....


So that's good!? Unless there is a reason why that check was not there 
originally!
Charles Manning, do you care for a comment?


> You can always re-mark the factory bad ones, given that you have written 
> down which they were once... if you are using a flash-based BBT, erasing 
> the BBT blocks would suffice, as the bad block management in jffs2 when 
> using a flash-based BBT doesn't touch bad block markers. I would assume 
> from your reasoning that you are not using a flash-based BBT?

I don't, no. And I didn't write down the factory ones...


BR,
  Martin

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Ian McDonnell]

On Wednesday 06 June 2007 08:40, Martin Egholm Nielsen wrote:
> Well, glancing at the code, it should be doing something like
> it:
>
> ==== ORIGINAL mkyaffs.c ====
> for(addr = 0; addr < meminfo.size; addr += meminfo.erasesize)
> {
>    /* 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.
>     */
>    oob.start = addr;
>    oob.length = 16;
>    oob.ptr = oobbuf;
>    if (ioctl(fd, MEMREADOOB, &oob) != 0)
>    {
>      perror("ioctl(MEMREADOOB)");
>      close(fd);
>      exit(1);
>    }
>
>    if(countBits[oobbuf[5]] < 7)
>    {
>      printf("Block at 0x08%lx is damaged and is not being
> formatted\n",addr);
>    }
> =======================
>
> However, it doesn't seem to do the trick. So I copied the
> check from "flash_eraseall" and put in, as well:
>
> ==== NEW mkyaffs.c ====
> for(addr = 0; addr < meminfo.size; addr += meminfo.erasesize)
> {
>    /* MEN 2007-06-06 */
>    loff_t bah = addr;
>    int ret = ioctl(fd, MEMGETBADBLOCK, &bah);
>    if (ret > 0)
>    {
>      printf( "Block at 0x08%lx would have been ignored by
> flash_eraseall!\n", addr );
>      continue;
>    } // if
>
>    // OLD CODE HERE
> =======================
>
>
> And now it seems to work:
>
> # mkyaffs-hacked-2007-06-06 -e /dev/mtd0
> argc 3 sh 0 optcnt 2
> Erasing and programming NAND
> Erasing block at 0x080
> Erasing block at 0x084000
> ...
> Erasing block at 0x0898000
> Block at 0x089c000 would have been ignored by flash_eraseall!
> ....
>
>
> So that's good!? Unless there is a reason why that check was
> not there originally!
> Charles Manning, do you care for a comment?

mkyaffs.c coding is from way back when reading the OOB was more
transparent (originally written to run on 'raw' NAND without MTD, 
non-linux). These days (post 2.6.17 mtd, perhaps earlier) this 
technique is not successful.  The OOB bytes returned by MTD will 
have been gathered using the nand_ecclayout policy from the nand 
driver or nand_base.c and the byte *returned* at offset 5 is not 
(necessarily) the block/page status byte and physical offset 5,
as with old mtd api.

See the yaffs mail archive regarding issues with constructing 
Yaffs images using mkyaffs.c etc.  Replacing this old test for a 
bad-block with MEMGETBADBLOCK is fine, but might only take you 
to the next road block.

-imcd

Re: [Yaffs1] mkyaffs exits with "MTD Erase failure"

[Martin Egholm Nielsen]

Ian McDonnell wrote:
> On Wednesday 06 June 2007 08:40, Martin Egholm Nielsen wrote:
>>Well, glancing at the code, it should be doing something like
>>it:

>>==== ORIGINAL mkyaffs.c ====
>>for(addr = 0; addr < meminfo.size; addr += meminfo.erasesize)
>>{
>>   /* 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.
>>    */
--- 8< 8< 8< ---
>>=======================

>>However, it doesn't seem to do the trick. So I copied the
>>check from "flash_eraseall" and put in, as well:
--- 8< 8< 8< ---
>>   int ret = ioctl(fd, MEMGETBADBLOCK, &bah);
>>   if (ret > 0)
>>   {
>>     printf( "Block at 0x08%lx would have been ignored by
>>flash_eraseall!\n", addr );
>>     continue;
>>   } // if
>>=======================

>>And now it seems to work:
--- 8< 8< 8< ---
>>So that's good!? Unless there is a reason why that check was
>>not there originally!
>>Charles Manning, do you care for a comment?

> mkyaffs.c coding is from way back when reading the OOB was more
> transparent (originally written to run on 'raw' NAND without MTD, 
> non-linux). These days (post 2.6.17 mtd, perhaps earlier) this 
> technique is not successful.  

Heh! Actually, I'm running with MTD from 2005-07-22 (2005!)... But, 
still there could be some issues!


> The OOB bytes returned by MTD will have been gathered using the
> nand_ecclayout policy from the nand driver or nand_base.c and the
> byte *returned* at offset 5 is not (necessarily) the block/page
> status byte and physical offset 5, as with old mtd api.

Oh! That's a shame ;-)


> See the yaffs mail archive regarding issues with constructing 
> Yaffs images using mkyaffs.c etc.  

Well, gave it 10 minutes - didn't have any luck searching for mkyaffs 
and/or nand_ecclayout policy...


> Replacing this old test for a bad-block with MEMGETBADBLOCK is fine,
> but might only take you to the next road block.

It only seems to be a problem for the boards that I messed up by setting 
the timing parameters for the chip incorrectly!
But I will look some more to find the "correct" solution...

Thanks Ian!

// Martin