MPC831x (and others?) NAND erase performance improvements

[Joakim Tjernlund]

Scott Wood <scottwood at freescale.com> wrote on 2010/12/08 21:25:51:
>
> On Wed, 8 Dec 2010 21:11:08 +0100
> Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:
>
> > Scott Wood <scottwood at freescale.com> wrote on 2010/12/08 20:59:28:
> > >
> > > On Wed, 8 Dec 2010 20:57:03 +0100
> > > Joakim Tjernlund <joakim.tjernlund at 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.