Handling multiple NAND chips

Handling multiple NAND chips

[J.D. Bakker]

Hi all,

I have an expansion board for the LART (an embedded computer based on 
the DEC/Intel StrongARM) with eight NAND flash devices on it. As 
suggested by the Toshiba datasheet, they share data, CLE, ALE, nWE 
and nRE and RDY. Each chip has its own nCE line.

I would like to use all eight chips with mtdconcat and YAFFS. Given 
the above, how should I hook the eight NANDs up to the mtd layer ? 
I've gone through CVS, but haven't found any hints in The Source.

By the way, is mtd multi-threaded whne using multiple devices ? 
Should I worry about overlapping address/data phases to separate NAND 
chips ?

Thanks,

Jan-Derk Bakker
[who inflicted the LART_ENDIAN_BYTE ordering on mtd]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: Handling multiple NAND chips

[David Woodhouse]

On Fri, 2003-07-25 at 11:12, J.D. Bakker wrote:
> Hi all,
> 
> I have an expansion board for the LART (an embedded computer based on 
> the DEC/Intel StrongARM) with eight NAND flash devices on it. As 
> suggested by the Toshiba datasheet, they share data, CLE, ALE, nWE 
> and nRE and RDY. Each chip has its own nCE line.
> 

If they each had their own data/CLE/ALE etc you'd use mtdconcat. As it
is, you want the code I've half-written to handle multiple chips in one
MTD device.

> I would like to use all eight chips with mtdconcat and YAFFS. Given 
> the above, how should I hook the eight NANDs up to the mtd layer ? 
> I've gone through CVS, but haven't found any hints in The Source.

Look at the changes I've made recently. They're the first half of what's
needed.

> By the way, is mtd multi-threaded whne using multiple devices ? 
> Should I worry about overlapping address/data phases to separate NAND 
> chips ?

It will be, yes -- but at the moment it doesn't actually _use_ multiple
devices; it only manages the probe. We need to fix the read/write/erase
methods to handle multiple chips; selecting the right chip, etc.

> [who inflicted the LART_ENDIAN_BYTE ordering on mtd]

:)

-- 
dwmw2

Re: Handling multiple NAND chips

[David Woodhouse]

On Fri, 2003-07-25 at 11:12, J.D. Bakker wrote:
> Hi all,
> 
> I have an expansion board for the LART (an embedded computer based on 
> the DEC/Intel StrongARM) with eight NAND flash devices on it. As 
> suggested by the Toshiba datasheet, they share data, CLE, ALE, nWE 
> and nRE and RDY. Each chip has its own nCE line.

Btw, I suspect that when we come to implement this, we'll find you'd get
much more parallelism if you had _separate_ FR/B# lines for each chip. 

If you can hook your FR/B# lines up to an IRQ-capable GPIO, that'd be
cute too.

-- 
dwmw2

Re: Handling multiple NAND chips

[J.D. Bakker]

At 11:36 -0400 25-07-2003, David Woodhouse wrote:
>On Fri, 2003-07-25 at 11:12, J.D. Bakker wrote:
>>  Hi all,
>>
>>  I have an expansion board for the LART (an embedded computer based on
>>  the DEC/Intel StrongARM) with eight NAND flash devices on it. As
>>  suggested by the Toshiba datasheet, they share data, CLE, ALE, nWE
>>  and nRE and RDY. Each chip has its own nCE line.
>>
>
>If they each had their own data/CLE/ALE etc you'd use mtdconcat. As it
>is, you want the code I've half-written to handle multiple chips in one
>MTD device.

I have a two-hour old CVS; where should I look ?

Does it *help* to have separate data/CLE/ALE ? I've read the recent 
thread on using address lines for CLE/ALE, and there's a big CPLD 
between the CPU and the NANDs, so I could make them appear to be 
separate devices. Note that all devices share the same data bus, so 
they're not attached to different byte lanes as I've seen discussed 
in the source.

Thanks again,

JDB.
[can you tell I'm a hardware guy ? ;-)]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: Handling multiple NAND chips

[David Woodhouse]

On Fri, 2003-07-25 at 11:51, J.D. Bakker wrote:
> I have a two-hour old CVS; where should I look ?

The fact that select_chip() now takes a 'chip_number' argument, that
nand_scan() now takes a 'max_chips' argument and probes for up to that
many... next is to fix the read/write/erase functions to select the
_correct_ chip according to the address, etc. 

> Does it *help* to have separate data/CLE/ALE ?

Probably not. What may help, and to be honest I won't be 100% sure till
we actually come to implement it, is having separate FR/B# so you can
happily poll for completion and leave multiple chips _busy_
independently.

-- 
dwmw2

Re: Handling multiple NAND chips

[Charles Manning]

On Saturday 26 July 2003 03:12, J.D. Bakker wrote:
> Hi all,
>
> I have an expansion board for the LART (an embedded computer based on
> the DEC/Intel StrongARM) with eight NAND flash devices on it. As
> suggested by the Toshiba datasheet, they share data, CLE, ALE, nWE
> and nRE and RDY. Each chip has its own nCE line.
>
> I would like to use all eight chips with mtdconcat and YAFFS. Given
> the above, how should I hook the eight NANDs up to the mtd layer ?
> I've gone through CVS, but haven't found any hints in The Source.
>
David has given some answaers.

One thing to watch out for: some NAND chips have very high pin capacitance 
and a fan-out of 8 might get a bit freaky.

You'll need quite a bit of RAM for holding various data structures. :-).

-- CHarles

Re: Handling multiple NAND chips

[J.D. Bakker]

At 11:56 -0400 25-07-2003, David Woodhouse wrote:
>On Fri, 2003-07-25 at 11:51, J.D. Bakker wrote:
>>  I have a two-hour old CVS; where should I look ?
>
>The fact that select_chip() now takes a 'chip_number' argument, that
>nand_scan() now takes a 'max_chips' argument and probes for up to that
>many... next is to fix the read/write/erase functions to select the
>_correct_ chip according to the address, etc.

/me grep(2)s source...

Ah, I see. Are you planning to always treat the NANDs as a linear 
array ? As I obviously have access to multi-NAND hardware, I'll 
happily beta-test this WIP.

>  > Does it *help* to have separate data/CLE/ALE ?
>
>Probably not. What may help, and to be honest I won't be 100% sure till
>we actually come to implement it, is having separate FR/B# so you can
>happily poll for completion and leave multiple chips _busy_
>independently.

Polling should be possible through the Status Read command 
(0x70/0x71) anyway, right ? Or would you want hardware to generate an 
interrupt when any of the FR/B# lines change ? Hmmm...

JDB
[now testing the CVS code with a single 1Gb NAND chip]
-- 
"There is a style of design I call "wishful thinking engineering."  It starts
  with something like "pigs can fly if you feed them enough beans" and develops
  utopian plans such as like having everyone commute to work riding on personal
  pigs, and along the way ignores minor details such as the consequent rain of
  the non-gaseous byproducts."

  (Vernon Schryver in n.a.n-a.e)

Re: Handling multiple NAND chips

[J.D. Bakker]

At 12:27 +1200 26-07-2003, Charles Manning wrote:
>One thing to watch out for: some NAND chips have very high pin capacitance
>and a fan-out of 8 might get a bit freaky.

The Toshiba TH58100s I'm using have 20pf pin capacitance. On a fully 
populated board (8 chips) this increases the access time by 5-10ns. 
I'm not too worried about this -- the main purpose for this design is 
solid state data recording, which is already limited by program/erase 
time.

Thanks for reminding me, though; I need to increase the processor's 
access time to these memory regions.

>You'll need quite a bit of RAM for holding various data structures. :-).

I have 160MB, will that do for a 1GB yaffs mount ?

By the way, does yaffs have inherent limitations wrt file system size 
I should worry about ?

JDB
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: Handling multiple NAND chips

[Thomas Gleixner]

On Saturday 26 July 2003 12:22, J.D. Bakker wrote:
> At 11:56 -0400 25-07-2003, David Woodhouse wrote:
> >On Fri, 2003-07-25 at 11:51, J.D. Bakker wrote:
> >>  I have a two-hour old CVS; where should I look ?
> >  > Does it *help* to have separate data/CLE/ALE ?
> >
> >Probably not. What may help, and to be honest I won't be 100% sure till
> >we actually come to implement it, is having separate FR/B# so you can
> >happily poll for completion and leave multiple chips _busy_
> >independently.
>
> Polling should be possible through the Status Read command
> (0x70/0x71) anyway, right ? 

Yep, that works always and you don't have to have seperate FR/B# lines.

> Or would you want hardware to generate an
> interrupt when any of the FR/B# lines change ? Hmmm...

You can do this, but the question is, if it is really an advantage.

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

Re: Handling multiple NAND chips

[David Woodhouse]

On Sat, 2003-07-26 at 06:22, J.D. Bakker wrote:
> Ah, I see. Are you planning to always treat the NANDs as a linear 
> array ? 

Yeah -- I think so. Any reason not to?

> As I obviously have access to multi-NAND hardware, I'll 
> happily beta-test this WIP.

Thanks ;)

> Polling should be possible through the Status Read command 
> (0x70/0x71) anyway, right ? Or would you want hardware to generate an 
> interrupt when any of the FR/B# lines change ? Hmmm...

During an erase, polling should be possible -- but what about waiting
for the chip to be ready after a reset, etc.? If another chip is
erasing, your FR/B# line is pulled low, I assume?

-- 
dwmw2

Re: Handling multiple NAND chips

[David Woodhouse]

On Sat, 2003-07-26 at 07:39, Thomas Gleixner wrote:
> You can do this, but the question is, if it is really an advantage.

Dunno. In general, interrupt-driven operation is an advantage over
polling -- it lets us get on with something else while we're waiting for
the flash, and come straight back to the flash driver when it's done.
Given the latencies involved on NAND, though, it might not really be
worth the effort -- but I'd like to investigate.

-- 
dwmw2

Re: Handling multiple NAND chips

[Thomas Gleixner]

On Saturday 26 July 2003 17:08, David Woodhouse wrote:
> On Sat, 2003-07-26 at 07:39, Thomas Gleixner wrote:
> > You can do this, but the question is, if it is really an advantage.
>
> Dunno. In general, interrupt-driven operation is an advantage over
> polling -- it lets us get on with something else while we're waiting for
> the flash, and come straight back to the flash driver when it's done.
> Given the latencies involved on NAND, though, it might not really be
> worth the effort -- but I'd like to investigate.

For write it has really no advantage. All chips I have tested so far work near  
the min. timings. 

For erase it could be useful, as it can last a little bit longer. But I know 
for sure, that the current yield and some polling code has better performance 
than most ide drives.

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

Re: Handling multiple NAND chips

[J.D. Bakker]

At 11:06 -0400 26-07-2003, David Woodhouse wrote:
>On Sat, 2003-07-26 at 06:22, J.D. Bakker wrote:
>>  Ah, I see. Are you planning to always treat the NANDs as a linear
>>  array ?
>
>Yeah -- I think so. Any reason not to?

Not really, if you exclude braindead setups like multiple 
hot-swappable SmartMedia cards. The only sane setup I could imagine 
is having one partition per NAND device, but it's not one I would be 
using myself.

Would you expect all devices to have the same size ?

JDB
[working around oddities in Lattice's ABEL compiler...]
-- 
Riddoch's Myth of computing:
         Any computer problem is invariably the fault of the closest
         sysadmin.

Re: Handling multiple NAND chips

[David Woodhouse]

On Sat, 2003-07-26 at 14:20, J.D. Bakker wrote:
> Not really, if you exclude braindead setups like multiple 
> hot-swappable SmartMedia cards. The only sane setup I could imagine 
> is having one partition per NAND device, but it's not one I would be 
> using myself.

True, but in that case you can still do it as separate devices. 

> Would you expect all devices to have the same size ?

Yes. I made that optimisation for NOR chips and nobody's bitched about
it yet, IIRC. 

-- 
dwmw2

Re: Handling multiple NAND chips

[J.D. Bakker]

At 11:56 -0400 25-07-2003, David Woodhouse wrote:
>On Fri, 2003-07-25 at 11:51, J.D. Bakker wrote:
>>  I have a two-hour old CVS; where should I look ?
>
>The fact that select_chip() now takes a 'chip_number' argument,

What is the return value for select_chip supposed to be ? Current CVS 
is a bit ambiguous in this regard (understandably, considering the 
newness).

Style question: unsigned char, __u8, u_char, u_int8_t or uint8_t ? 
The kernel part of CVS uses all five in different places.

JDB
[sticking with unsigned char for the time being]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/

Re: Handling multiple NAND chips

[David Woodhouse]

On Sun, 2003-07-27 at 08:54, J.D. Bakker wrote:
> What is the return value for select_chip supposed to be ? Current CVS 
> is a bit ambiguous in this regard (understandably, considering the 
> newness).

Currently void -- I can't imagine cases where it could fail. I suppose
I'll probably turn out to be wrong though...

> Style question: unsigned char, __u8, u_char, u_int8_t or uint8_t ? 
> The kernel part of CVS uses all five in different places.

unsigned char, uint8_t and u_char are the only ones I'd want to see --
and the latter only if it's already in use. One of the former two in new
code, please -- preferably 'unsigned char' I think.

I reserve the right to do otherwise, and to change my mind -- not
necessarily in that order. 

-- 
dwmw2

Re: Handling multiple NAND chips

[J.D. Bakker]

At 9:42 -0400 27-07-2003, David Woodhouse wrote:
>On Sun, 2003-07-27 at 08:54, J.D. Bakker wrote:
>>  What is the return value for select_chip supposed to be ? Current CVS
>>  is a bit ambiguous in this regard (understandably, considering the
>>  newness).
>
>Currently void -- I can't imagine cases where it could fail. I suppose
>I'll probably turn out to be wrong though...

I was wondering what to do when 'chip' is larger than the maximum 
number of NANDs. Currently I silently deselect all devices when that 
happens.

>  > Style question: unsigned char, __u8, u_char, u_int8_t or uint8_t ?
>>  The kernel part of CVS uses all five in different places.
>
>unsigned char, uint8_t and u_char are the only ones I'd want to see --
>and the latter only if it's already in use. One of the former two in new
>code, please -- preferably 'unsigned char' I think.

unsigned char it is then.

>I reserve the right to do otherwise, and to change my mind -- not
>necessarily in that order.

HEY! I resemble that remark !

Thanks,

JDB
[just tried to insmod my first cut of the lartcan NAND driver -- blew 
up with 'partition extends beyond the end of device "<NULL>"' and a 
bunch of divisions by zero. Back to the drawing board...]
-- 
Your eyes are weary from staring at the CRT. You feel sleepy. Notice 
how restful it is to watch the cursor blink. Close your eyes. The 
opinions stated above are yours. You cannot imagine why you ever felt 
otherwise.

Re: Handling multiple NAND chips

[David Woodhouse]

On Sun, 2003-07-27 at 09:58, J.D. Bakker wrote:
> I was wondering what to do when 'chip' is larger than the maximum 
> number of NANDs. Currently I silently deselect all devices when that 
> happens.

Well, it'll never be higher than the maximum number passed into
nand_scan(). It's a should-never-happen case; I'd rather you BUG() if
you're going to check for it at all.

> [just tried to insmod my first cut of the lartcan NAND driver -- blew 
> up with 'partition extends beyond the end of device "<NULL>"' and a 
> bunch of divisions by zero. Back to the drawing board...]

Leave out the partitioning until the basic NAND code is working?

-- 
dwmw2