Numonyx NOR bug

DISCUSSION Leo 3 participants 4 messages Apr 12, 2011 – Apr 14, 2011 Memory technology devices (MTD)

Share & tools

Leo

author

2011-04-12 21:18 UTC #0 lore raw

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

Joakim Tjernlund

2011-04-12 22:56 UTC #1 lore raw

Quoted 45 lines

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?

Quoted 2 lines

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

Markus Niebel

2011-04-13 06:26 UTC #2 lore raw

In reply to Leo

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:

Quoted 50 lines

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/

Leo

author

2011-04-14 19:43 UTC #3 lore raw

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

Quoted 68 lines · 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:
Quoted 44 lines
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?
Quoted 6 lines
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/