From: David Hawkins <dwh@ovro•caltech.edu>
To: Leon Woestenberg <leon.woestenberg@gmail•com>
Cc: Linux PPC <linuxppc-dev@ozlabs•org>
Subject: Re: MPC83xx watchdog reset board dead lock
Date: Tue, 16 Jun 2009 09:30:07 -0700 [thread overview]
Message-ID: <4A37C88F.8040701@ovro.caltech.edu> (raw)
In-Reply-To: <c384c5ea0906160852l4845760cp8594463a866683dc@mail.gmail.com>
Hi Leon,
> 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.
What do you do in the case of blank flash on a board?
I'm not sure that this will work for you, but it might ...
on my boards, the PowerPC connects to an FPGA on the local
bus, and the flash is connected to that FPGA (it made
routing easier to go through the FPGA). When the board
powers up, a small FSM in the FPGA reads from the first
word in Flash, and checks it is not blank. If it is
blank, the configuration pins are asserted such that
the processor uses a hard-coded reset configuration word,
and the processor reset is deasserted. If the flash is
not blank, the processor is allowed to boot from Flash.
An alternative method for firmware updates would be
to use the boot from high-mem versus low-mem flag
in the RCWs. On a number of the Freescale EVMs, you
can have two images in the Flash; one at low mem,
and one at high mem. Toggling a dip switch selects
the value of the BMS bit in the RCWs, and lets you boot
from one image or the other. This is a good trick that
avoids having to have a debugger to recover back
to a sane image - note that a CPLD delivers the RCWs,
not the flash.
So in either of these examples, the RCWs source is
sometimes not the Flash image ... which requires
that feature designed into the original hardware.
Those two ideas should get you thinking :)
Cheers,
Dave
next prev parent reply other threads:[~2009-06-16 16:30 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 [this message]
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
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=4A37C88F.8040701@ovro.caltech.edu \
--to=dwh@ovro$(echo .)caltech.edu \
--cc=leon.woestenberg@gmail$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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