Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)

2008-09-30 Thread Leon Woestenberg
André,

On Tue, Sep 30, 2008 at 12:05 AM, Leon Woestenberg
[EMAIL PROTECTED] 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,
-- 
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: How to prevent embedded ppc reset deadlock? (MPC83xx/85xx)

2008-09-29 Thread Leon Woestenberg
Hello André,

On Mon, Sep 29, 2008 at 11:50 PM, André Schwarz
[EMAIL PROTECTED] wrote:
 Leon,

 you're right.
 PORESET is just there to prevent the core from running as long as power may
 be unstable and/or PLLs are out of lock.
 HRESET is the signal that should reset everything. I did it on my board and
 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ße 16, DE-71570 Oppenweiler  - Registergericht:
 Amtsgericht Stuttgart, HRB 271090
 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner




-- 
Leon
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev