Hi Leon, ...
Most designs do not care about the watchdog, or only pet in their non-critical paths... That's not what the watchdog is for. Also, I don't care about u-boot. I care about a design where the Flash NOR could be in write mode at any time when the watchdog triggers, when the hardware is running critical software. No lifes in danger when it happens, only jobs, so no biggy :-)
true, I was just looking from SW/u-boot perspective. Ideally the dead-lock is prevented on board/HW level.
David has been helpful in thinking this through, but we followed-up offline, and we independently came up with the following design, so this must therefore work (disclaimer applies). Note, it DOES require a NOR flash that has a RY/BUSY# pin. Quoting David Hawkins, who gave a very clear explanation: --- How about using the RDY/BUSY# pin on the Flash in conjunction with PORESET#. If the flash is busy, then the processor gets PORESET#, otherwise, the HRESET# just does its normal thing. That way PORESET# only ever asserts when you have the combo of the Flash being busy and HRESET# asserting. <...> If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. --- Kudos to David. I'll be testing the design tomorrow on the reference board, I'll report results in this thread.
Interesting. Looking forward to the results. --- N. van Bolhuis. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
