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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.