nand flash driver

[Thomas Gleixner]

On Thursday 10 July 2003 17:32, David Woodhouse wrote:
> On Thu, 2003-07-10 at 16:12, jasmine at regolith.co.uk wrote:
> > On Thu, 10 Jul 2003, David Woodhouse wrote:
> > > Hmmm. When sending multiple bytes of address, isn't ALE supposed to
> > > remain high for the entire duration, without going low again between
> > > cycles? How do you achieve this if it's on the address bus?
> >
> > By waiting to see if the next write is to the same address-  it's not
> > hard to do that sort of thing in an FPGA or SoC.  Since the only line
> > involved is the ALE to the NAND, there's no downside in hanging on a
> > little longer before dropping it.
>
> Hmmm. So you deassert ALE only when the _next_ cycle happens and it's
> not another write with the appropriate address bit set?
>
> According to the Toshiba datasheet in front of me there are timing
> constraints on how long you must delay between deasserting ALE and
> performing the subsequent read cycle.
>
> After a READ command and address sending cycle, you must deassert ALE at
> least 50ns before subsequently asserting RE#, and after a READID command
> it's 100ns.
>
> The naïve implementation would probably get that wrong. You could
> probably arrange to deassert ALE with a _read_ cycle to the 'address'
> address, though.

It will work with addresslines, if

1. All datasheets are reliable
2. Your hardwaredesigner can precalculate all the timings in details even 
under high interrupt load !!!!
3. the softwareguy is aware of the above problems

My experience is (I have a bunch of different solutions here on top of my 
desk):

Either you have a genius in hardware and software design available or you have 
a rock solid solution with GPIO/FPGA/CPLD. The second one will either 
increase your production costs by <1$ per piece or decrease your performance 
by about 8%.
Both negatives will be less than the debugging and redesign costs.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de