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 10:35:41 +0200 [thread overview]
Message-ID: <4A38AADD.3070801@aimvalley.nl> (raw)
In-Reply-To: <c384c5ea0906160852l4845760cp8594463a866683dc@mail.gmail.com>
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.
It is possible to configure the WD to issue a machine check interrupt
(i.s.o. HRESET). Maybe it's possible (or even done already) to put the
flash into READ-mode from the isr ?
---
N. van Bolhuis.
Leon Woestenberg wrote:
> Hello,
>
> this is a hardware, even board issue, but I hope to find the right
> target audience here.
>
>
> In our MPC83xx design I would like to prevent dead lock in case where
> a field upgrade is performed, i.e. NOR Flash is erased or written, and
> the MPC83xx built-in hardware watchdog triggers.
>
> In u-boot the scenario can be easily reproduced by running this
> command (WARNING, erases some sectors!) on an MPC8313E-RDB:
>
> erase_wdg=mw.l 0xe0000204 0x10000007 1;mw.w 0xe000020e 0x556c 1;mw.w
> 0xe000020e 0xaa39 1;erase 1:10-30
>
> This sets up the watchdog to reset soonish, then starts erasing NOR
> sectors. Watchdog triggers and resets -> Dead lock.
>
>
> Most MPC8xxx board designs I have seen suffer from this possible dead lock:
> - NOR Flash is put in erase mode or write mode
> - Hardware watchdog triggers
> - HRESET# is asserted by the processor, during which the configuration
> words are read from NOR Flash.
>
> Either
> HRESET# is not attached to NOR, NOR stays in erase/write mode and
> invalid words will be read -> dead lock
>
> or either:
> HRESET# is attached to NOR reset, NOR is reset, but stays in reset as
> HRESET# stays asserted.
>
>
>
> We have been looking at several solutions hardware wise that reset the
> NOR flash on HRESET# going low, but the processors are stubborn,
> read the config words only once, than dead lock.
>
> I wonder if there are known-working designs for this.
>
> Regards,
next prev parent reply other threads:[~2009-06-17 8:35 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 [this message]
2009-06-17 10:09 ` Leon Woestenberg
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=4A38AADD.3070801@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.