Hello,

On Wed, Jun 17, 2009 at 12:09 PM, Leon
Woestenberg<leon.woestenb...@gmail.com> wrote:
> Quoting David Hawkins, who gave a very clear explanation:
> <...>
> 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.
>

I just found out from a Spansion datasheet that the RY/BUSY# of a
typical Flash NOR is enabled by CE#, and tri-state otherwise.
CE# in turn is driven by the LCS# from the PowerPC.

So basically, the first configuration access cycle while the NOR is in
write mode, will pull CE# low, which results in RY/BUSY#
being driven.

I have measured this pulse is ~1.9 us. So the reset circuitry needs a
maximum minimum pulse duration of 1.9 us.

Our reset controller (DS1818) fulfills this requirement, with a T,PB of 1 us.

A reset controller will extend the reset pulse. This is needed because:

for Flash NOR: I have seen a mininum of 35 us reset pulse.
(for the PowerPC: PORESET# should be asserted externally for at least
32 input clock cycles)


Regards,
-- 
Leon
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to