nand flash driver

nand flash driver

[gjx]

hi,linux-mtd

	 The hardware designer connects the control pins(CLE、ALE、R/B) of nand flash to the data bus, The CE、WE、RE pins to corresponding pin of CPU. Nedd I get the address of control pins? separate the data from data bus? How to implement controlling of nand.   Please give me some advice, thanks!


　　　　　　　　gjx
　　　　　　　　marchguo@yahoo.com.cn
　　　　　　　　　　2003-07-07

Re: nand flash driver

[Charles Manning]

On Monday 07 July 2003 14:33, gjx wrote:
> hi,linux-mtd
>
> 	 The hardware designer connects the control pins(CLE¡¢ALE¡¢R/B) of nand
> flash to the data bus, The CE¡¢WE¡¢RE pins to corresponding pin of CPU.
> Nedd I get the address of control pins? separate the data from data bus?
> How to implement controlling of nand.   Please give me some advice, thanks!

R/B is an open collector that is driven from the NAND. You should not be 
connecting this to the address bus. You can just leave this unconnected (R/B 
detection not available) or connect it to a GPIO.

I think most people connect CLE and ALE to GPIO pins, but some application 
notes describe driving these via the address bus. you should then be able to 
drive the lines the way you want by accessing the corresponding addresses.

-- CHarles

Re: nand flash driver

[jasmine]

On Wed, 9 Jul 2003, Charles Manning wrote:

> I think most people connect CLE and ALE to GPIO pins, but some application 
> notes describe driving these via the address bus. you should then be able to 
> drive the lines the way you want by accessing the corresponding addresses.

Most people running NAND flash on general-purpose designs use GPIO lines 
to drive their ALE, CLE and to read the RNB line.  Some of these designs 
also use a GPIO to generate read and write strobes.  This is a very simple 
design to implement.

Some custom SoCs and logic-array-based implementations put all this logic 
inside the chip, decoding ALE and CLE cycles to different addresses, so 
that you write the address latch bytes to one address and the command 
latch bytes to a different one.  This is slightly neater, though can have 
complications with interrupt latency (requirement to stretch read and 
write cycles to some parts of the address map, etc.)

Some devices take all this stuff and put it inside a piece of logic that 
manages a pipeline of bytes in and out of the NAND.  Some SoCs do this, 
and of course DiskOnChip does something like this, resolving NAND access 
into cycles that look like conventional NOR or ROM cycles.  This is, in 
some ways, the easiest to implement, though it seems to have caused MTD 
the most problems, though that is mostly because of M-Systems' intentional 
obfuscation tactics.

-Jas.

Re: nand flash driver

[David Woodhouse]

On Thu, 2003-07-10 at 14:05, jasmine@regolith.co.uk wrote:
> On Wed, 9 Jul 2003, Charles Manning wrote:
> > I think most people connect CLE and ALE to GPIO pins, but some application 
> > notes describe driving these via the address bus. you should then be able to 
> > drive the lines the way you want by accessing the corresponding addresses.

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?

>  This is, in some ways, the easiest to implement, though it seems to
> have caused MTD the most problems, though that is mostly because of
> M-Systems' intentional obfuscation tactics.

The main problem wasn't intentional obfuscation. It wasn't really even
lack of documentation either -- we've had docs for the DiskOnChip 2000
and Millennium hardware since 1999.

The problem was really that the DiskOnChip drivers long predated the
generic NAND driver code we have now, and indeed a real understanding of
NAND flash. So all the perceived bizarreness of NAND flash helped to
obfuscate the DiskOnChip driver unnecessarily.

Take a look at the new drivers/mtd/nand/diskonchip.c and it's really not
that obfuscated at all. It'll get a bit more cluttered when I make it
support multiple chips and the DiskOnChip hardware ECC, but it's still
not too bad.

All M-Systems' current devices are supported by Linux¹, and they seem
interested in ensuring that remains the case. I've been very frustrated
by them in the past, as I know have you -- but they seem to be playing
nicely now.

-- 
dwmw2

¹ Well OK, with one or two exceptions which we're currently working on fixing.

Re: nand flash driver

[jasmine]

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.

-J.

Re: nand flash driver

[David Woodhouse]

On Thu, 2003-07-10 at 16:12, jasmine@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.

-- 
dwmw2

Re: nand flash driver

[Thomas Gleixner]

On Thursday 10 July 2003 17:32, David Woodhouse wrote:
> On Thu, 2003-07-10 at 16:12, jasmine@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@linutronix.de

RE: nand flash driver

[Stephan Linke]

Hi,

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

I don't know exactly what our hardware guys did but from softer perspective I can say the most "difficult" part is to copy nand_command() and modify it so it uses your addresses to switch between data, address and command mode. You can remove a few calls of hwcontrol(). Write your own hwcontrol() and dev_ready() function, that's it. Few magic in there.
The important question is: did the hardware designer a good job? And I hope ours did. ;-)

Stephan

Re: nand flash driver

[Russ Dill]

On Thu, 2003-07-10 at 08:12, jasmine@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.

yup, and a CPLD only costs about $1 (32 io, 32 mc) or $2.65 for a
72io/72 mc. Makes this sort of thing pretty trivial, although for 2 or 3
signals, discrete logic will do just fine.

-- 
Russ Dill <Russ.Dill@asu.edu>

Re: nand flash driver

[Charles Manning]

On Friday 11 July 2003 03:12, jasmine@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.

Certainly this will work, as would using GPIOs, FPGAs etc.

Maybe I misread the original posting, but my understanding is that the bloke 
has hardware connected to address lines. This should work, from what I read, 
although I would be more inclined to use IO pins of some sort.

Having the R/B line connected to an address line is broken for sure.

-- CHarles

Re: nand flash driver -> ALE etc

[Charles Manning]

On Friday 11 July 2003 02:20, David Woodhouse wrote:
> On Thu, 2003-07-10 at 14:05, jasmine@regolith.co.uk wrote:
> > On Wed, 9 Jul 2003, Charles Manning wrote:
> > > I think most people connect CLE and ALE to GPIO pins, but some
> > > application notes describe driving these via the address bus. you
> > > should then be able to drive the lines the way you want by accessing
> > > the corresponding addresses.
>
> 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?

I always thought so too, but someone brought to my attention a discussion 
about using address lines in a Toshiba doc.

The timing diagrams in the Toshiba datasheet I have open right now 
(TC58128AFT) state  that ALE and friends are don't care except during the 
actual read/write cycles.

I looked at a Samsung datasheet and saw the same thing.


-- Charles

Nand flash driver

[Spinelli, Claudio (Claudio)]

Hi,

I am using a Micron nand flash part number MT29F8G08AAA. It is a SLC part. This MICRON nand flash is 1GByte.

I was wondering if anybody wrote a driver for it, and if anybody implemented the cache option read/write that Micron offers.

Thanks

Claudio