MPC831x (and others?) NAND erase performance improvements

Scott Wood scottwood at freescale.com
Thu Dec 9 09:05:31 EST 2010


On Wed, 8 Dec 2010 22:26:59 +0100
Joakim Tjernlund <joakim.tjernlund at transmode.se> wrote:

> 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.

No, but you asked if it could be done, and if it was just a
performance issue. :-)

> > > 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?

Not much, if you enable interrupts on the GPIO pin.  The driver would
have to be reworked a bit, of course.

> 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.

Ask your sales/support contacts.

> 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.

The problem with that is when would you assert the chipselect again to
check if it's done?  Current SW depends on being able to tell the LBC
to interrupt (or take other action) when busy goes away.

I suppose you could poll with status reads, which could at least be
preempted if you've got something higher priority to do with the LBC.

-Scott



More information about the Linuxppc-dev mailing list