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

[Martin Egholm Nielsen <martin@egholm-nielsen.dk>]

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