Numonyx NOR bug
Leo
leo.costa77 at gmail.com
Tue Apr 12 17:18:34 EDT 2011
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
More information about the linux-mtd
mailing list