MPC831x (and others?) NAND erase performance improvements

[Joakim Tjernlund]

Andre Schwarz <andre.schwarz at matrix-vision.de> wrote on 2010/12/10 09:47:10:
>
> Scott,
>
> do you think this issue also applies to MPC8377 ?

Probably, I think this is so for all eLBC controllers.

>
> I'm in the middle of a small redesign for series production and would
> like not to miss a thing.
> We have Nand, Nor and MRAM connected to LBC.
>
> Since RFS is running from NAND and we use the MRAM as a non-volatile
> SRAM I'd like to avoid being hit by this issue.

Please report back, I really want to know if this works and if there
are any drawbacks.

>
> Any comments from your side ?
>
> Regards,
> André
>
> > 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
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
> MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
> Registergericht: Amtsgericht Stuttgart, HRB 271090
> Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner