From: Leon Woestenberg <leon.woestenberg@gmail.com>
To: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
Cc: Linux PPC <linuxppc-dev@ozlabs.org>
Subject: Re: MPC83xx watchdog reset board dead lock
Date: Wed, 17 Jun 2009 12:09:21 +0200 [thread overview]
Message-ID: <c384c5ea0906170309j6fdf28f5qc38129e82649ef28@mail.gmail.com> (raw)
In-Reply-To: <4A38AADD.3070801@aimvalley.nl>
Hello all,
On Wed, Jun 17, 2009 at 10:35 AM, Norbert van
Bolhuis<nvbolhuis@aimvalley.nl> wrote:
> Hi Leon,
>
> I doubt if there are working designs for this.
> ...
> In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally
> strobed in the decrementer interrupt routine (timer_interrupt). So
> I guess there's not a big chance it triggers a reset.
> ...
>
Most designs do not care about the watchdog, or only pet in their
non-critical paths... That's not what the watchdog is for.
Also, I don't care about u-boot.
I care about a design where the Flash NOR could be in write mode at
any time when the watchdog triggers, when the hardware is running
critical software.
No lifes in danger when it happens, only jobs, so no biggy :-)
David has been helpful in thinking this through, but we followed-up
offline, and we independently came up with the following design, so
this must therefore work (disclaimer applies).
Note, it DOES require a NOR flash that has a RY/BUSY# pin.
Quoting David Hawkins, who gave a very clear explanation:
---
How about using the RDY/BUSY# pin on the Flash in conjunction
with PORESET#. If the flash is busy, then the processor gets
PORESET#, otherwise, the HRESET# just does its normal thing.
That way PORESET# only ever asserts when you have the
combo of the Flash being busy and HRESET# asserting.
<...>
If you have the Flash BUSY# signal, then this scheme works
great, since using HRESET# low and BUSY# low to create a
PORESET# source is only active until the Flash RESET#
is asserted long enough for it to get out of the BUSY#
state and back into read-array mode.
---
Kudos to David.
I'll be testing the design tomorrow on the reference board, I'll
report results in this thread.
Regards / Groeten,
--
Leon
next prev parent reply other threads:[~2009-06-17 10:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-16 15:52 MPC83xx watchdog reset board dead lock Leon Woestenberg
2009-06-16 16:30 ` David Hawkins
2009-06-16 16:59 ` Leon Woestenberg
2009-06-16 19:02 ` David Hawkins
2009-06-17 8:35 ` Norbert van Bolhuis
2009-06-17 10:09 ` Leon Woestenberg [this message]
2009-06-17 11:07 ` Leon Woestenberg
2009-06-17 12:16 ` Norbert van Bolhuis
2009-06-18 23:01 ` Leon Woestenberg
2009-06-18 23:22 ` David Hawkins
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=c384c5ea0906170309j6fdf28f5qc38129e82649ef28@mail.gmail.com \
--to=leon.woestenberg@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=nvbolhuis@aimvalley.nl \
/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;
as well as URLs for NNTP newsgroup(s).