* 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
[parent not found: <48E14DAE.9040101@matrix-vision.de>]
* 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).