linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
@ 2008-09-29 21:33 Leon Woestenberg
       [not found] ` <48E14DAE.9040101@matrix-vision.de>
  0 siblings, 1 reply; 3+ messages in thread
From: Leon Woestenberg @ 2008-09-29 21:33 UTC (permalink / raw)
  To: linuxppc-dev

Hello all,

not Linux related per se*, but I wonder how your board designs deal
with the reset circuitry for embedded PowerPC processors (MPC8313E in
my case).
My requirement is that both a processor-external hard reset and
processor-internal hard reset must both reset the boot device NOR
FlashROM, so that it does not remain in write mode (if it is).

Given those processor pins:

PORESET# (input pin to the processor, power on reset)
HRESET# (bidirectional pin on the processor, asserted by processor on
hard reset such as watchdog)

I see many designs (even the Freescale reference designs) where the
HRESET# resets some of the board, but not the FlashROM, and where
PORESET# resets the FlashROM. This can cause a deadlock in the case
where the watchdog resets during writing to FlashROM, as the FlashROM
is not reset and remains in write mode, not allowing the processor to
boot from it.

I am thinking of using this approach: PORESET# -> processor <-->
HRESET# -> board reset.

Would that work? or why not?

Regards,
-- 
Leon

* to make this Linux related: suppose MTD is writing new firmware to
your NOR FlashROM and then /dev/wdg is not petted due to some
programmer bug in the firmware update code.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
       [not found] ` <48E14DAE.9040101@matrix-vision.de>
@ 2008-09-29 22:05   ` Leon Woestenberg
  2008-09-30 11:07     ` Leon Woestenberg
  0 siblings, 1 reply; 3+ messages in thread
From: Leon Woestenberg @ 2008-09-29 22:05 UTC (permalink / raw)
  To: André Schwarz, linuxppc-dev

Hello Andr=E9,

On Mon, Sep 29, 2008 at 11:50 PM, Andr=E9 Schwarz
<Andre.Schwarz@matrix-vision.de> wrote:
> Leon,
>
> you're right.
> PORESET is just there to prevent the core from running as long as power m=
ay
> be unstable and/or PLLs are out of lock.
> HRESET is the signal that should reset everything. I did it on my board a=
nd
> it works fine.
>
Understood so far.

> Since you also have to assert HRESET when you assert PORESET
>
But when I assert PORESET, the processor will assert HRESET itself
AFAIK, so why do this?

> you can wire-or them with a low drop schottky diode.
>
Ooh, analog electronics, long time ago. Let me think: arrow of diode
symbol pointing from HRESET# to PORESET#, right, so that PORESET#
going low will pull HRESET# low enough, right?

> Hope this helps.
>
Yes it does, thanks.

Regards, Leon.


> Leon Woestenberg wrote:
>>
>> Hello all,
>>
>> not Linux related per se*, but I wonder how your board designs deal
>> with the reset circuitry for embedded PowerPC processors (MPC8313E in
>> my case).
>> My requirement is that both a processor-external hard reset and
>> processor-internal hard reset must both reset the boot device NOR
>> FlashROM, so that it does not remain in write mode (if it is).
>>
>> Given those processor pins:
>>
>> PORESET# (input pin to the processor, power on reset)
>> HRESET# (bidirectional pin on the processor, asserted by processor on
>> hard reset such as watchdog)
>>
>> I see many designs (even the Freescale reference designs) where the
>> HRESET# resets some of the board, but not the FlashROM, and where
>> PORESET# resets the FlashROM. This can cause a deadlock in the case
>> where the watchdog resets during writing to FlashROM, as the FlashROM
>> is not reset and remains in write mode, not allowing the processor to
>> boot from it.
>>
>> I am thinking of using this approach: PORESET# -> processor <-->
>> HRESET# -> board reset.
>>
>> Would that work? or why not?
>>
>> Regards,
>>
>
>
> MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=
ht:
> Amtsgericht Stuttgart, HRB 271090
> Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
>



--=20
Leon

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)
  2008-09-29 22:05   ` Leon Woestenberg
@ 2008-09-30 11:07     ` Leon Woestenberg
  0 siblings, 0 replies; 3+ messages in thread
From: Leon Woestenberg @ 2008-09-30 11:07 UTC (permalink / raw)
  To: André Schwarz, linuxppc-dev

Andr=E9,

On Tue, Sep 30, 2008 at 12:05 AM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
>> Since you also have to assert HRESET when you assert PORESET
>>
> But when I assert PORESET, the processor will assert HRESET itself
> AFAIK, so why do this?
>
>> you can wire-or them with a low drop schottky diode.
>>

MPC8313E PowerQUICC II Pro Integrated Processor Family Reference
Manual, Rev. 1, section 4.2.2, page 4-6:

"Directly after the negation of PORESET, the device starts the
configuration process. The device asserts HRESET throughout the
power-on reset process, including configuration"

So, I will not drive HRESET myself but depend on the ppc to drive it for me=
.

Regards,
--=20
Leon

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-09-30 11:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-29 21:33 How to prevent embedded ppc reset deadlock? (MPC83xx/85xx) Leon Woestenberg
     [not found] ` <48E14DAE.9040101@matrix-vision.de>
2008-09-29 22:05   ` Leon Woestenberg
2008-09-30 11:07     ` Leon Woestenberg

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).