Numonyx NOR bug

[Leo]

It happens only sometimes when there is an erase suspend. I read the 
AppNote from Numonyx and i seems to be the "Delay after resume" bug of 
M29EW devices, because the chip_good() fails as described there. Their 
patch works, but also mine works, so i think it's the same bug, but it 
happens only when a suspend is done before the time-out. Their patch 
adds a udelay of 100 usecs (i tried with 50 but the problem is still 
there) after each resume, when there are a lot of suspend-resume 
sequences this could decrease the performance.

Leo

On 13/04/2011 08:26, Markus Niebel wrote:
> Hello Leo,
>
> can you isolate the problem? I mean, can it happen all time when you 
> erase or only if there is an erase suspend? As far as I know these 
> chips have a timout after erase / erase resume before erase suspend is 
> accepted. If this timeout is not noticed, the erase may fail.
>
> It would be better for file system performance to use this timeout 
> before waiting using the INVALIDATE_CACHE_UDELAY macro.
>
> just another question: Does the error happen on SLC or on MLC or on 
> both kind of devices? (The smaller ones are SLC the larger MLC).
>
> There is an AppNote from Numonyx ("Patching the Linux Kernel for 
> Micron Axcell™ M29 Flash Memory").
>
> Markus
>
> Am 12.04.2011 23:18, schrieb Leo:
>> I found a little problem with mtd drivers running on a LTIB linux
>> distribution on a custom board equipped with a Freescale Coldfire and a
>> Numonyx NOR Axcell M29EW flash memory. The do_erase_oneblock() function
>> sometimes fails because the chip_good() functions returns zero reading a
>> data word different from 0xffff. I spent some time debugging and finally
>> I solved the problem adding a new chip state "FL_ERASE_STARTING" and
>> setting it after the erase block command sequence as follows :
>>
>> cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> cfi_send_gen_cmd(0x80, cfi->addr_unlock1, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> cfi_send_gen_cmd(0xAA, cfi->addr_unlock1, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> cfi_send_gen_cmd(0x55, cfi->addr_unlock2, chip->start, map, cfi,
>> cfi->device_type, NULL);
>> map_write(map, CMD(0x30), adr);
>>
>> chip->state = FL_ERASE_STARTING;
>>
>> INVALIDATE_CACHE_UDELAY(map, chip,
>> adr, len,
>> chip->erase_time);
>>
>> chip->state = FL_ERASING;
>> chip->erase_suspended = 0;
>> chip->in_progress_block_addr = adr;
>>
>> timeo = jiffies + (HZ*20);
>>
>> for (;;) {
>>
>> This works because the Numonyx chip probably does not accept the erase
>> suspend command during the erase block time-out (the 50 us after the
>> command sequence has been sent and before the erase starts). In fact the
>> INVALIDATE_CACHE_UDELAY() macro unlocks the mutex and lets
>> reading/writing functions to suspend the erasing too soon calling the
>> get_chip(). With the FL_ERASE_STARTING state get_chip() does not give
>> the access to reading/writing functions during the
>> INVALIDATE_CACHE_UDELAY() sleeping period (chip->erase_time).
>> Anyone into the same problem?
>>
>> Thanks for reading!
>> Leonardo
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/