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)