Numonyx NOR bug

Numonyx NOR bug

[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

Re: Numonyx NOR bug

[Joakim Tjernlund]

>
> 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

Sounds similar to what we found some time ago, check out
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecf3fde07c8dcb92a1bf3fbdfe70905d85cd00e1
for a fix

Re: Numonyx NOR bug

[Markus Niebel]

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/

Re: 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/