Re: Numonyx NOR bug

[Markus Niebel <list-09_linux_mtd@tqsc.de>]

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/