MPC831x (and others?) NAND erase performance improvements

[Andre Schwarz]

Scott,

do you think this issue also applies to MPC8377 ?

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.

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