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