From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
To: Leon Woestenberg <leon.woestenberg@gmail.com>
Cc: Linux PPC <linuxppc-dev@ozlabs.org>
Subject: Re: MPC83xx watchdog reset board dead lock
Date: Wed, 17 Jun 2009 14:16:03 +0200 [thread overview]
Message-ID: <4A38DE83.1010405@aimvalley.nl> (raw)
In-Reply-To: <c384c5ea0906170309j6fdf28f5qc38129e82649ef28@mail.gmail.com>
Hi Leon,
...
> 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 :-)
>
true, I was just looking from SW/u-boot perspective.
Ideally the dead-lock is prevented on board/HW level.
>
> 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.
>
Interesting.
Looking forward to the results.
---
N. van Bolhuis.
next prev parent reply other threads:[~2009-06-17 12:16 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
2009-06-17 11:07 ` Leon Woestenberg
2009-06-17 12:16 ` Norbert van Bolhuis [this message]
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=4A38DE83.1010405@aimvalley.nl \
--to=nvbolhuis@aimvalley.nl \
--cc=leon.woestenberg@gmail.com \
--cc=linuxppc-dev@ozlabs.org \
/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.