Scott Wood <scottw...@freescale.com> wrote on 2010/12/08 21:25:51: > > On Wed, 8 Dec 2010 21:11:08 +0100 > Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote: > > > Scott Wood <scottw...@freescale.com> wrote on 2010/12/08 20:59:28: > > > > > > On Wed, 8 Dec 2010 20:57:03 +0100 > > > Joakim Tjernlund <joakim.tjernl...@transmode.se> wrote: > > > > > > > Can you think of any workaround such as not connecting the BUSY pin at > > > > all? > > > > > > Maybe connect the busy pin to a gpio? > > > > Is BUSY required for sane operation or it an optimization? > > You could probably get away without it by inserting delays if you know > the chip specs well enough.
Urgh, that does not feel like a good solution. One would have add big margins to the delays mking the NAND much slower. > > > Is there any risk that the NAND device will drive the LB and corrupt > > the bus for other devices? > > I think the only thing the NAND chip should be driving is the busy pin, OK, good. What function is actually lost if one uses an GPIO instead of BUSY? You think Freescale could test and validate a GPIO solution? I don't think we will be very happy to design our board around an unproven workaround. An even better workaround would be if one could add logic between the NAND and the CPU which would compensate for this defect without needing special SW fixes. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
