Subject: Re: MPC831x (and others?) NAND erase performance improvements

From: Mark Mason <[email-masked]>
Date: Wed, 8 Dec 2010 17:02:45 -0500

Joakim Tjernlund <[email-masked]> wrote:

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

I tried to take this route, since it was a fairly minor board change.
Unfortunately all the GPIOs were already used.

I looked long and hard for a way to not have the NAND hold the bus
with BUSY.  If you don't connect BUSY then you can't use the LBC's
flash controller (FCM mode).

I haven't done it personally, but I believe that connecting BUSY to a
GPIO is very common thing to do, since this is the route you'd have to
take if you didn't have a built-in flash controller.  The Linux MTD
layer supports it.

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

That probably won't work.  Presumably you're talking about something
like a gate so the BUSY is only passed from the NAND when the NAND's
chip select is asserted.  Unfortunately the NAND controller is
monitoring the BUSY line, and if it sees the signal deassert then it
will think the NAND is done.

I don't think that using a software NAND controller instead of the LBC
FCM mode is all that bad.  Again, I haven't actually done it, so check
the MTD docs, but I'm pretty sure the software is meant to do that, so
it doesn't even really constitute a "fix".  Assuming that it is
supported then I doubt that configuring the NAND layer to use your
setup would be any harder than configuring the FCM.  And, U-Boot uses
the Linux MTD code, so you'd get the same support there.

There might also be a way to keep the BUSY and find a workaround with
the other chips on the bus, depending on what they are.  Chances are
that they have a BUSY, but maybe you could move the peripheral's BUSY
to another LBC line and use UPM mode to interpret that line as a BUSY.
Writing UPM programs isn't really all that difficult (well, not the
second time you do it anyway).  That's getting into kludge territory,
though.