From: Jaap-Jan Boor <jjboor@aimsys.nl>
To: "Stefan Stürke" <sst@pandatel.com>, "Josh Boyer" <jdub@us.ibm.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: MTD and 28F128J3A
Date: Fri, 20 Aug 2004 09:53:40 +0200 [thread overview]
Message-ID: <1092988420.23187.45.camel@linpc003.aimsys.nl> (raw)
In-Reply-To: <1092930561.2991.8.camel@weaponx.rchland.ibm.com>
On Thu, 2004-08-19 at 17:49, Josh Boyer wrote:
> On Thu, 2004-08-19 at 10:33, Stefan StÃŒrke wrote:
>
> > Thank you, nice idea. I just tested it but unfortunatly at
> > my hardware the reset pin of the flash is only triggered
> > by power on reset and not by processor reset. So the
> > checkstop just kills the processor but it still can not
> > read valid code from flash :-(
>
> I had a situation like that once. Some may tell you that it's a broken
> board design, which is mostly true. But we don't always have a say in
> the design of the boards we use ;).
>
> >
> > Of course as 'dirty' solution I could write a 0xFF to
> > the flash device before executing 'm8260_gorom()'.
> > In this way the problem should be solved.
> >
> > But I am afraid that the code in cfi_cmset_0001 has a bug
> > leaving the chip in query mode after writing to it. And that
> > this bug has side effects which I can't see know but which will
> > be seen by our customers.
> > Has anybody ever heard of such behavior of cfi_cmset_0001?
>
> Is it in CFI query mode, or in Read Status mode? I have seen it be left
> in Read Status mode after a write, but never CFI query mode.
Yes, that's what I also see. That should be ok.
>
> Leaving it in Read Status mode shouldn't have any side effects during
> runtime operation, since the MTD code expects that. It's probably more
> efficient anyway, since the code can't be sure of what the next
> operation will be.
>
> To solve your reset issue, you could do what you said above. Or you can
> put the chip in Read Array mode after every write is completed (erase
> too for that matter). That won't catch all the corner cases though.
>
> josh
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum mailto:jjboor@aimsys.nl
next prev parent reply other threads:[~2004-08-20 7:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-19 11:46 MTD and 28F128J3A Stefan Stürke
2004-08-19 12:48 ` Jaap-Jan Boor
2004-08-19 12:50 ` Jaap-Jan Boor
2004-08-19 15:33 ` Stefan Stürke
2004-08-19 15:49 ` Josh Boyer
2004-08-20 7:53 ` Jaap-Jan Boor [this message]
2004-08-20 8:17 ` Stefan Stürke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1092988420.23187.45.camel@linpc003.aimsys.nl \
--to=jjboor@aimsys.nl \
--cc=jdub@us.ibm.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sst@pandatel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox