* Erasebug on AMD flashes @ 2004-03-17 19:51 dkey 2004-03-17 22:39 ` Shawn Jin 2004-03-18 10:25 ` David Vrabel 0 siblings, 2 replies; 6+ messages in thread From: dkey @ 2004-03-17 19:51 UTC (permalink / raw) To: linux-mtd, dvrabel Hi list! we are using jffs2 on the dbox2 and AMD flash chips, but since rev. 1.96 of cfi_cmdset_0002.c we can't erase the flashes. rev. 1.94 works without problems. here are some debug infos, tell me if you need more! when we want to erase the flashes with MEMERASE ioctl, we get these errors: Erase at 0x00080000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout Erase at 0x00060000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout Erase at 0x00040000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout Erase at 0x00020000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout Erase at 0x00000000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout Erase at 0x000c0000 failed immediately: errno -5 MTD do_erase_oneblock(): flash internal timeout when we do erase with "eraseall" binary: eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 20000 -- 14 % complete.MTD do_erase_oneblock(): flash inter nal timeout eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 40000 -- 28 % complete.MTD do_erase_oneblock(): flash inter nal timeout eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 60000 -- 42 % complete.MTD do_erase_oneblock(): flash inter nal timeout eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ 80000 -- 57 % complete.MTD do_erase_oneblock(): flash inter nal timeout eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ a0000 -- 71 % complete.MTD do_erase_oneblock(): flash inter nal timeout eraseall: /dev/mtd/3: MTD Erase failure: Input/output error Erasing 128 Kibyte @ c0000 -- 85 % complete.MTD do_erase_oneblock(): flash inter nal timeout would be please if anybody can take a look over the code or revert revision of cfi_cmdset_0002.c to 1.94. thx! greets dkey ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Erasebug on AMD flashes 2004-03-17 19:51 Erasebug on AMD flashes dkey @ 2004-03-17 22:39 ` Shawn Jin 2004-03-18 10:25 ` David Vrabel 1 sibling, 0 replies; 6+ messages in thread From: Shawn Jin @ 2004-03-17 22:39 UTC (permalink / raw) To: dkey; +Cc: linux-mtd dkey wrote: >> we are using jffs2 on the dbox2 and AMD flash chips, but since rev. 1.96 of > cfi_cmdset_0002.c we can't erase the flashes. rev. 1.94 works without > problems. > here are some debug infos, tell me if you need more! > > when we want to erase the flashes with MEMERASE ioctl, we get these errors: > > > Erase at 0x00080000 failed immediately: errno -5 > MTD do_erase_oneblock(): flash internal timeout FYI. I guess you have chips interleaved, right? I have the same problem with erase and even worse since write doesn't work for me either. According to David Vrabel, it may be broken when chips are interleaved. -Regards, Shawn. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Erasebug on AMD flashes 2004-03-17 19:51 Erasebug on AMD flashes dkey 2004-03-17 22:39 ` Shawn Jin @ 2004-03-18 10:25 ` David Vrabel 1 sibling, 0 replies; 6+ messages in thread From: David Vrabel @ 2004-03-18 10:25 UTC (permalink / raw) To: linux-mtd dkey wrote: > > we are using jffs2 on the dbox2 and AMD flash chips, but since rev. 1.96 of > cfi_cmdset_0002.c we can't erase the flashes. rev. 1.94 works without > problems. "since 1.96" doesn't make sense. Any breakage would be from 1.95. > here are some debug infos, tell me if you need more! Part numbers of the flash chips and their configuration (interleaved etc.). > would be please if anybody can take a look over the code or revert revision of > cfi_cmdset_0002.c to 1.94. There's no reason why you can't revert to 1.94 yourself. FWIW, I'm now of the opinion that chip_status() is definately broken for interleaved chips and probably cannot be made to work without ending up with a mess. I would suggest using the data polling algorithm instead (where applicable). Also, ignoring the internal flash timeout (DQ5 toggling) and instead relying on the software timeout might be acceptable. However, a repeatedly suspended erase keeps getting its software timeout extended and thus there is a possibility of the software timeout never occuring. Hmmm. An internal timeout requires a chip reset and thus we can't actually suspend an internally timed-out erase so the software timeout won't be extended. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <E1B3wBv-0005HA-9d@pentafluge.infradead.org>]
* Re: Erasebug on AMD flashes [not found] <E1B3wBv-0005HA-9d@pentafluge.infradead.org> @ 2004-03-18 22:02 ` dkey 2004-03-19 10:20 ` David Vrabel 0 siblings, 1 reply; 6+ messages in thread From: dkey @ 2004-03-18 22:02 UTC (permalink / raw) To: linux-mtd, dvrabel here is a picture of the flashes http://www.dietmar-h.net/img/nokia_2xAMD_Pin12.jpg and their configuration http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/21534.pdf greets On Thursday 18 March 2004 13:00, linux-mtd-request@lists.infradead.org wrote: > Message: 4 > Date: Thu, 18 Mar 2004 10:25:17 +0000 > From: David Vrabel <dvrabel@arcom.com> > Subject: Re: Erasebug on AMD flashes > To: linux-mtd@lists.infradead.org > Message-ID: <4059790D.4020904@arcom.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > dkey wrote: > > we are using jffs2 on the dbox2 and AMD flash chips, but since rev. 1.96 > > of cfi_cmdset_0002.c we can't erase the flashes. rev. 1.94 works without > > problems. > > "since 1.96" doesn't make sense. Any breakage would be from 1.95. > > > here are some debug infos, tell me if you need more! > > Part numbers of the flash chips and their configuration (interleaved etc.). > > > would be please if anybody can take a look over the code or revert > > revision of cfi_cmdset_0002.c to 1.94. > > There's no reason why you can't revert to 1.94 yourself. > > FWIW, I'm now of the opinion that chip_status() is definately broken for > interleaved chips and probably cannot be made to work without ending up > with a mess. > > I would suggest using the data polling algorithm instead (where > applicable). > > Also, ignoring the internal flash timeout (DQ5 toggling) and instead > relying on the software timeout might be acceptable. However, a > repeatedly suspended erase keeps getting its software timeout extended > and thus there is a possibility of the software timeout never occuring. > Hmmm. An internal timeout requires a chip reset and thus we can't > actually suspend an internally timed-out erase so the software timeout > won't be extended. > > David Vrabel > -- > David Vrabel, Design Engineer > > Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 > Cambridge CB1 7EA, UK Web: http://www.arcom.com/ > > > > ------------------------------ > > Message: 5 > Date: Thu, 18 Mar 2004 11:56:47 +0100 > From: Thomas Gleixner <tglx@linutronix.de> > Subject: Re: Bug in nand_select_chip? > To: llandre <r&d@wawnet.biz>, David Woodhouse <dwmw2@infradead.org> > Cc: Andrea Scian <andrea.scian@wawnet.biz> > Message-ID: <200403181156.47289.tglx@linutronix.de> > Content-Type: text/plain; charset=iso-8859-1 > > On Thursday 18 March 2004 10:56, llandre wrote: > > >That's correct, but you unfortunaly relied on code, which was in a heavy > > >modifciation phase. If you use leading edge code, be aware, that things > > > might be broken from time to time. The fix for this was committed 10 > > > days after the first rework. > > > > Ok, thanks for the advice. > > To avoid such problems, is it possible to download "stable" releases? Are > > they tagged in the CVS repository? > > Yep, but the NAND stuff is quite new and not always up to date in the > stable versions. > > You can subscribe on the CVS mailinglist, which informs you of all changes > in the repository. > http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Erasebug on AMD flashes 2004-03-18 22:02 ` dkey @ 2004-03-19 10:20 ` David Vrabel 2004-03-19 12:27 ` Re[2]: " barthezz 0 siblings, 1 reply; 6+ messages in thread From: David Vrabel @ 2004-03-19 10:20 UTC (permalink / raw) To: linux-mtd >> Part numbers of the flash chips and their configuration (interleaved etc.). > [AM29DL322D] Okay. Are there two chips in parallel forming a 32 bit data bus (i.e. interleaved); or two chips in series forming a 16 bit data bus (i.e. non-interleaved); or some other weird scheme? David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re[2]: Erasebug on AMD flashes 2004-03-19 10:20 ` David Vrabel @ 2004-03-19 12:27 ` barthezz 2004-03-22 10:41 ` David Vrabel 0 siblings, 1 reply; 6+ messages in thread From: barthezz @ 2004-03-19 12:27 UTC (permalink / raw) To: linux-mtd Hallo David, Friday, March 19, 2004, 11:20:57 AM, du hast geschrieben: >>> Part numbers of the flash chips and their configuration (interleaved etc.). >> [AM29DL322D] DV> Okay. Are there two chips in parallel forming a 32 bit data bus (i.e. DV> interleaved); or two chips in series forming a 16 bit data bus (i.e. DV> non-interleaved); or some other weird scheme? DV> David Vrabel There are two chips in parallel forming a 32 bit data bus (i.e. interleaved) Mit freundlichen Grüssen, barthezz ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Erasebug on AMD flashes 2004-03-19 12:27 ` Re[2]: " barthezz @ 2004-03-22 10:41 ` David Vrabel 0 siblings, 0 replies; 6+ messages in thread From: David Vrabel @ 2004-03-22 10:41 UTC (permalink / raw) To: linux-mtd [-- Attachment #1: Type: text/plain, Size: 515 bytes --] > There are two AM29DL322D chips in parallel forming a 32 bit data bus (i.e. interleaved) It's as I suspected. Someone with interleaved AMD chips will have to fix the status checking code. [30 mins later] Find a patch attached. It's not been tested or even been passed through a compiler. Let me know if it works or doesn't work, please. David Vrabel -- David Vrabel, Design Engineer Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233 Cambridge CB1 7EA, UK Web: http://www.arcom.com/ [-- Attachment #2: mtd-interleaved-amd-chip-status-fix.patch --] [-- Type: text/plain, Size: 5433 bytes --] Index: drivers/mtd/chips/cfi_cmdset_0002.c =================================================================== RCS file: /home/cvs/mtd/drivers/mtd/chips/cfi_cmdset_0002.c,v retrieving revision 1.97 diff -u -B -p -r1.97 cfi_cmdset_0002.c --- drivers/mtd/chips/cfi_cmdset_0002.c 24 Feb 2004 13:50:21 -0000 1.97 +++ drivers/mtd/chips/cfi_cmdset_0002.c 22 Mar 2004 10:37:32 -0000 @@ -451,6 +451,16 @@ static int chip_status(struct map_info * return CHIP_ERROR; } +static int chip_ready(struct map_info *map, unsigned long addr) +{ + cf_word d, t; + + d = cfi_read(map, addr); + t = d ^ cfi_read(map, addr); + + return t == 0; +} + static int get_chip(struct map_info *map, struct flchip *chip, unsigned long adr, int mode) { DECLARE_WAITQUEUE(wait, current); @@ -465,7 +475,7 @@ static int get_chip(struct map_info *map case FL_STATUS: for (;;) { - if (chip_status(map, adr) == CHIP_READY) + if (chip_ready(map, adr)) break; if (time_after(jiffies, timeo)) { @@ -506,7 +516,7 @@ static int get_chip(struct map_info *map chip->state = FL_ERASE_SUSPENDING; chip->erase_suspended = 1; for (;;) { - if (chip_status(map, adr) == CHIP_READY) + if (chip_ready(map, adr)) break; if (time_after(jiffies, timeo)) { @@ -821,8 +831,11 @@ static int do_write_oneword(struct map_i continue; } - if ((status = chip_status(map, adr)) != CHIP_BUSY) - break; + if (chip_ready(map, adr)) + goto op_done; + + if (time_after(jiffies, timeo)) + break; /* Latency issues. Drop the lock, wait a while and retry */ cfi_spin_unlock(chip->mutex); @@ -830,18 +843,8 @@ static int do_write_oneword(struct map_i cfi_spin_lock(chip->mutex); } - if (status == CHIP_READY) - goto op_done; - - if (status == CHIP_TIMEDOUT) - printk(KERN_WARNING "MTD %s(): flash internal timeout\n", - __func__); - else if (ta) - printk(KERN_WARNING "MTD %s(): software timeout\n", - __func__ ); - else - printk(KERN_WARNING "MTD %s(): unexpected failure. status = %d\n", - __func__, status); + printk(KERN_WARNING "MTD %s(): software timeout\n", + __func__ ); op_failed: /* reset on all failures. */ @@ -1185,10 +1188,11 @@ static inline int do_write_buffer(struct continue; } - if( (status = chip_status(map, adr)) != CHIP_BUSY - || ( ta = time_after(jiffies, timeo)) ) { + if (chip_ready(map, adr)) + goto op_done; + + if( time_after(jiffies, timeo)) break; - } /* Latency issues. Drop the lock, wait a while and retry */ cfi_spin_unlock(chip->mutex); @@ -1196,20 +1200,8 @@ static inline int do_write_buffer(struct cfi_spin_lock(chip->mutex); } - - if (status == CHIP_READY) - goto op_done; - - if (status == CHIP_TIMEDOUT) { - printk(KERN_WARNING "MTD %s(): flash internal timeout\n", - __func__); - } - else if (ta) - printk(KERN_WARNING "MTD %s(): software timeout\n", - __func__ ); - else - printk(KERN_WARNING "MTD %s(): unexpected failure. status = %d\n", - __func__, status); + printk(KERN_WARNING "MTD %s(): software timeout\n", + __func__ ); op_failed: /* reset on all failures. */ @@ -1356,10 +1348,12 @@ static inline int do_erase_chip(struct m chip->erase_suspended = 0; } - if ((status = chip_status(map, adr)) != CHIP_BUSY - || ( ta = time_after(jiffies, timeo)) ) + if (chip_ready(map, adr)) + goto op_done; + + if (time_after(jiffies, timeo)) break; - + /* Latency issues. Drop the lock, wait a while and retry */ cfi_spin_unlock(chip->mutex); set_current_state(TASK_UNINTERRUPTIBLE); @@ -1367,18 +1361,8 @@ static inline int do_erase_chip(struct m cfi_spin_lock(chip->mutex); } - if (status == CHIP_READY) - goto op_done; - - if (status == CHIP_TIMEDOUT) - printk(KERN_WARNING "MTD %s(): flash internal timeout\n", - __func__); - else if (ta) - printk(KERN_WARNING "MTD %s(): software timeout\n", - __func__ ); - else - printk(KERN_WARNING "MTD %s(): unexpected failure. status = %d\n", - __func__, status); + printk(KERN_WARNING "MTD %s(): software timeout\n", + __func__ ); op_failed: /* reset on all failures. */ @@ -1546,8 +1530,10 @@ static inline int do_erase_oneblock(stru chip->erase_suspended = 0; } - if ((status = chip_status(map, adr)) != CHIP_BUSY - || ( ta = time_after(jiffies, timeo)) ) + if (chip_ready(map, adr)) + goto op_done; + + if (time_after(jiffies, timeo)) break; /* Latency issues. Drop the lock, wait a while and retry */ @@ -1556,20 +1542,10 @@ static inline int do_erase_oneblock(stru schedule_timeout(1); cfi_spin_lock(chip->mutex); } - - if (status == CHIP_READY) - goto op_done; - - if (status == CHIP_TIMEDOUT) - printk(KERN_WARNING "MTD %s(): flash internal timeout\n", - __func__); - else if (ta) - printk(KERN_WARNING "MTD %s(): software timeout\n", - __func__ ); - else - printk(KERN_WARNING "MTD %s(): unexpected failure. status = %d\n", - __func__, status); - + + printk(KERN_WARNING "MTD %s(): software timeout\n", + __func__ ); + op_failed: /* reset on all failures. */ cfi_write( map, CMD(0xF0), chip->start ); ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-03-22 10:41 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-17 19:51 Erasebug on AMD flashes dkey
2004-03-17 22:39 ` Shawn Jin
2004-03-18 10:25 ` David Vrabel
[not found] <E1B3wBv-0005HA-9d@pentafluge.infradead.org>
2004-03-18 22:02 ` dkey
2004-03-19 10:20 ` David Vrabel
2004-03-19 12:27 ` Re[2]: " barthezz
2004-03-22 10:41 ` David Vrabel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox