Subject: Re: NAND flash support
To: None <email@example.com>
From: Toru Nishimura <firstname.lastname@example.org>
Date: 03/09/2007 17:45:09
David Young email@example.com wrote;
> Once there are drivers for two or more NAND chips in NetBSD, we can
> extract the functions that the drivers have in common and produce a
> NAND framework.
Let's go in a smart way. I realized L* MTD is not a good example after all
when I started NAND block device code.
There are number of ways to control NAND chip;
1. bare GPIO fiddling,
2. ALE / CLE by address control signal,
3. dedicated HW supports by SoC. The simplest is to have extra wires
to replace GPIOs. The most sophisticated one can perform DMA xfer
with automatic ECC generation and verification. We can see the wide
variety of NAND circuit support in modern SoC; Toshiba TX49, AMCC
PPC440, MesDigital MMSP2, Sharp LH and a flock of other ARM7/9 SoC.
And there are design distinctions among 3/4 address control, 512/2048
data page size, of course.
So, I think it'd be beneficial to have a combination of two "ops" set
for coherent encapsulation;
A. the way to control chip, this is, issuing CMD, ADDR4/3/2/1 or some.
B. the way to read/write page, erase block, retrieve prodID or WP status.
The sophisticated HW support, if ever, can reduce or eliminate A ops,
and make B ops very small, just a thin layer to access NAND chip. A ops
is mostly for GPIO fiddling case (rather poor design, compared to today's
standard, I think).
Toru Nishimura/ALKYL Technology