* DQ7 vs DQ6 in flash erase/write
@ 2004-03-12 20:52 Shawn Jin
2004-03-15 10:32 ` David Vrabel
0 siblings, 1 reply; 4+ messages in thread
From: Shawn Jin @ 2004-03-12 20:52 UTC (permalink / raw)
To: linuxmtd
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 2538 bytes --]
Hi,
For AMD flash chips, in order to check if programing (erase or write) is
complete, you can either poll data (DQ7) or the toggle bits (DQ6/DQ2).
These two algorithms should be equivalent. However the toggle bit algorithm
seems not working on some chips for erase, write, or both. If the current
CVS code is used, which only supports the toggle bit algorithm, the symptom
is that chip is not writable or erasable. I'm "lucky" enough to have two
types of AMD flash chips (Am29PL320D and Am29LV256M) experiencing this kind
of problem.
The problems I experienced on Am29PL320D with a MPC8245 board are
1. No data can be written into the flash
2. If you try to erase several sectors continuously, only the first sector
can be erased. No error messages are shown.
On Am29LV256M with the same board, the chip is writable but not erasable.
The error message shows flash internal timeout. However the first sector is
actually erased if you do multiple sector erasure.
After long time investigation on the problem I found the following comment
on ver 1.3 of cfi_cmdset_0002.c.
/* The dq6 toggling method of determining whether the erase is finished
* doesn't seem to work for the Fujistu flash chips populated on the
* TQM8260 board. We poll dq7 instead.
*/
Someone had the similar problem long time ago! But I'm "luckier" because he
didn't have write problem.
So I used the old cfi_cmdset_002.c to solve the erase problem. I tried to
implement DQ7 algorithm for write on ver 1.3 of cfi_cmdset_002.c but
haven't succeeded. Files can be copied to flash by "cp files /dev/mtd?" but
JFFS2 is broken.
Since the toggle bit algorithm does not work on some chips with some
boards, I am wondering:
1. Why does it not work? On my custom MPC8245 board, I tried different
settings of memory control registers to adjust flash timing but had no
success. Maybe the problem is really in flash itself? Has anyone else had
the similar problem when using Am29PL320D and Am29LV256M on other boards?
2. Why was the data polling algorithm (DQ7) removed? Although it's not
prevailing, it does happen sometimes. If there is no plan to support it, at
least it's worth to be mentioned that sometimes you have to poll DQ7 to
check if erase/write is complete.
3. Will polling DQ7 be supported later? I tried to simply change
chip_status() to poll DQ7 but failed.
Any comments, suggestions? Thank you very much.
-Shawn.
__________________________________
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: DQ7 vs DQ6 in flash erase/write
2004-03-12 20:52 DQ7 vs DQ6 in flash erase/write Shawn Jin
@ 2004-03-15 10:32 ` David Vrabel
2004-03-15 20:14 ` Shawn Jin
0 siblings, 1 reply; 4+ messages in thread
From: David Vrabel @ 2004-03-15 10:32 UTC (permalink / raw)
To: linuxmtd
Hi,
> On Am29LV256M with the same board, the chip is writable but not erasable.
I have this part and it works. I suspect a board specific issue.
> After long time investigation on the problem I found the following comment
> on ver 1.3 of cfi_cmdset_0002.c.
1.3? That's fossilized.
>
> /* The dq6 toggling method of determining whether the erase is finished
> * doesn't seem to work for the Fujistu flash chips populated on the
> * TQM8260 board. We poll dq7 instead.
> */
This sounds like a problem with a particular Fujitsu chip. It would
have been helpful for the person writing that comment to have mentioned
which chip had the problem.
> 2. Why was the data polling algorithm (DQ7) removed?
Earlier versions were a mess with code for reading the chip status all
over the place. I refactored it for easier maintainance.
> 3. Will polling DQ7 be supported later?
If someone implements it in a clean way I don't see why not.
A quick look at the AM29PL320 datasheet indicates that the chip supports
the DQ6 toggle algorithm. I'm leaning towards a board specific issue
unless you have information from AMD regarding non-functionality of the
toggle-bit algorithm on this chip?
Are the chips interleaved? I've never tested interleaving so that may
be broken.
Other than that all I can suggest is that maybe something other than the
MTD driver is accessing the flash. This would certainly mess up the
toggle bit algorithm. Perhaps the chip selects are setup incorrectly?
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] 4+ messages in thread
* Re: DQ7 vs DQ6 in flash erase/write
2004-03-15 10:32 ` David Vrabel
@ 2004-03-15 20:14 ` Shawn Jin
0 siblings, 0 replies; 4+ messages in thread
From: Shawn Jin @ 2004-03-15 20:14 UTC (permalink / raw)
To: David Vrabel; +Cc: linuxmtd
David Vrabel wrote:
>>On Am29LV256M with the same board, the chip is writable but not erasable.
> I have this part and it works. I suspect a board specific issue.
Two Am29LV256M chips are interleaved to form a 32-bit data bus.
>>After long time investigation on the problem I found the following comment
>>on ver 1.3 of cfi_cmdset_0002.c.
>
> 1.3? That's fossilized.
Right, :(. But it works for me. It comes from Denx's linux-ppc distribution.
>> /* The dq6 toggling method of determining whether the erase is finished
>> * doesn't seem to work for the Fujistu flash chips populated on the
>> * TQM8260 board. We poll dq7 instead.
>> */
>
> This sounds like a problem with a particular Fujitsu chip. It would
> have been helpful for the person writing that comment to have mentioned
> which chip had the problem.
I guess it's Wolfgang Denk. I'll ask him about this.
>>2. Why was the data polling algorithm (DQ7) removed?
> Earlier versions were a mess with code for reading the chip status all
> over the place. I refactored it for easier maintainance.
The code is much easier to understand than before. It'll be much better
if the same functionalities are supported. ;)
> Are the chips interleaved? I've never tested interleaving so that may
> be broken.
Yes. The chips are interleaved. That may be the problem.
> MTD driver is accessing the flash. This would certainly mess up the
> toggle bit algorithm. Perhaps the chip selects are setup incorrectly?
I don't think so far the chip selects would be messed up.
-Shawn.
^ permalink raw reply [flat|nested] 4+ messages in thread
* DQ7 vs DQ6 in flash erase/write
@ 2004-10-20 14:19 York Sun
0 siblings, 0 replies; 4+ messages in thread
From: York Sun @ 2004-10-20 14:19 UTC (permalink / raw)
To: linux-mtd
Shawn,
I have the same problem you had for AMD flash. Polling DQ6 doesn't
always work while polling DQ7 does. I have two board, one is with
AM29LV641D, the other is with AM29LV641M. The latter one always work for
both polling.
Did you figure it out?
--
Best regards,
York Sun, Ph.D
Metrowerks
Freescale Semiconductor Inc.
Phone: (512) 996-5252
Email: yorksun@freescale.com
This email, and any associated attachments have been classified as:
[x] Freescale Semiconductor General Business
[ ] Freescale Semiconductor Internal Use Only
[ ] Freescale Semiconductor Confidential Proprietary
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-10-20 14:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-12 20:52 DQ7 vs DQ6 in flash erase/write Shawn Jin
2004-03-15 10:32 ` David Vrabel
2004-03-15 20:14 ` Shawn Jin
-- strict thread matches above, loose matches on Subject: below --
2004-10-20 14:19 York Sun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox