Re: NAND technical review

[Rutger Hofman <rutger@cs.vu.nl>]

Ross Younger wrote:
[snip]
> Getting data into and out of the chip involves a simple protocol sequence.
> 
> Commands are single bytes; addresses are sequences of a few bytes depending
> on the chip size and the operation invoked.
> 
> For example, to read a page of data on the spec sheet I have to hand is:
> * Write 0x00 into the command latch
> * Write the four address bytes in turn into the address latch
> * Write 0x30 into the command latch
> * Chip signals Busy; wait for it to signal Ready
> * Read out (up to) 2112 bytes of data.

AFAIK, there are two kinds of chips on the market: Large-page chips (2K 
data pages) and Small-page chips (512B pages). These speak a different 
command language, but in their wiring they are the same. The large-page 
chips are (nearly) ONFI-compliant, the Small-page chip command language 
is different. Ancient chips aside, if a chip gives its Device Type Byte, 
NAND flash code can look up in its tables what the chip parameters are 
(page size, block size, number of blocks, 8 or 16 bit data bus, etc). 
Miracle: Device Type Bytes are shared across manufacturers, so the table 
is limited in size.

I saw an annoucement of 4K-page chips, but the datasheets are 
confidential. Is there anybody who can comment on these?

> However, not all chips are quite the same. The ONFI initiative is an attempt
> to standardise chip protocols and most new chips should comply with it. A
> number of chips on the market are _nearly_ ONFI-compliant: deviations
> typically occur over the format of the ReadID response and that of an
> address. I believe that older chips did their own thing entirely.

[snip]

> 3. Driver model --------------------------------------------------------
> 
> The major architectural difference between the two NAND layers is in their
> driver models and the degree of abstraction enforced.
> 
> In Rutger's layer, controllers and chips are both formally abstracted. The
> application talks to the Abstract NAND Chip, which has (hard-coded) the
> basic sequences of commands, addresses and data required to talk to a NAND
> chip. This layer talks to a controller driver, which provides the nuts and
> bolts of reading and writing to the device. The chip driver is also called
> by the ANC layer, and provides the really chip-specific parts.
> 
> The call flow looks something like this (best viewed in fixed-width font):
> 
> Application --(H)-> ANC --(L)-> Controller driver
>                        \
>                         \-(C)-> Chip driver

The code attempts at both flexibility and code reuse. Its structure is 
as follows:

Application --(H)-> ANC --(H2)-> Controller Common --(L)-> Controller 
device-specific --(L)-> Chip

= ANC just wants to hide the presence of multiple controllers and 
multiple chips, in any degree of heterogeneity.

= Controller Common implements the command languages for Large-page 
chips and Small-page chips, does ECC generation/checking/repair. Its API 
is much like the ANC's API: page_read, page_write, block_erase, but on a 
specific controller+chip.

= Controller device-specific is (usually) the only part that must be 
ported for a new controller/board/setup. Its API is in terms of the 
commands described by Ross: push a command on the chip's bus, push/read 
data on the chip's bus etc. The sample GPIO driver that I bundled shows 
how little work can be involved in doing a port. I think that support 
for hardware ECC of some controllers may add more to the device-specific 
code than the command implementation!

= Chip has support for ONFI, Large-page, and Small page. Only for chips 
that don't fit in these categories (and there will be museums that have 
them) require writing a chip driver.

I realize that support for various chip and ECC types increases the 
code. It will be trivial to add a few #ifdef's to disable unneeded code 
for your configuration; the .cdl can specify what is needed (like: only 
large-page 'regular' chips, which means: no small-page, no ONFI 
interrogation).

[snip]

> - E's high-level driver interface makes it harder to add new functions
> later, necessitating a change to that API (H2 above). R's does not; the
> requisite logic would only need to be added to the ANC.

'ANC' should read: Controller Common code.

> ... (As a case in point, support
> for hardware ECC is currently work-in-progress within eCosCentric, and does
> require such a change, but now is not the right time to discuss that.)

Use of the hardware ECC support for R's BlackFin's on-board ECC was 
included in R from the start. The interface between Common Controller 
and device-specific controller code is designed to support this flexibly.

> It would perhaps be interesting to compare the complexities of drivers for
> the two models, but it's not readily apparent how we would do that fairly.
> 
> Perhaps porting a driver from one NAND layer to the other would be a useful
> exercise, and would also allow us to compare code sizes. Any suggestions or
> (he says hopefully) volunteers? I've got a lot on my plate this month...

Yes, this would definitely be interesting. Would there be benefits in 
R's attempts at ease-of-port and code reuse.

> (b) Availability of drivers
> 
> R provides support for:
> - One board: BlackFin EZ-Kit BF548 (which is not in anoncvs?)
> - One chip: the ST Micro 0xG chip (large page, x8 and x16 present but
> presumably only tested on the x8 chip on the BlackFin board?)

Correction: any 'regular' chip, of which the ST Micro is an example.

I tested on my synth target with x8 and x16 chips, also different ones 
in one 'board'. I tested with various page sizes, also different ones on 
one 'board'.

> - A synthetic controller/chip package
> - A template for a GPIO-based controller (untested, intended as an example only)
> 
> I seem to remember rumours of the existence of a driver for a further
> chip+board combination, but I haven't seen it.

See Jurgen Lambrecht's response.

[snip]

> 5. Works in progress -----------------------------------------------------
> 
> I can of course only comment on eCosCentric's plans, but the following work
> is in the pipeline:
> 
> * Expansion of the device interface to better allow efficient hardware ECC
> support (in progress)
> * Hardware ECC for the STM3210E board driver
> * Performance tuning of software ECC and of NAND low-level drivers
> * Partition addressing: make addressing relative to the start of the
> partition, once and for all
> * Simple raw NAND "filesystem" for use by RedBoot (see
> http://ecos.sourceware.org/ml/ecos-devel/2009-07/msg00004.html et seq; those
> are the latest public mails but not the latest version of my thinking, which
> I will update in due course)
> * More RedBoot NAND utility commands
> * Support for booting Linux off NAND and for sharing a (YAFFS) NAND-resident
> filesystem
> * Part-page read support (would provide a big speed-up to parts of YAFFS2
> inbandTags mode as needed by small-page devices like that on the STM3210E)

R is designed with support for hardware ECC in mind.

R has part-read and part-write support. One thing that has always 
puzzled me is how this interacts with ECC. ECC often works on a complete 
subpage, like 256 bytes on a 2KB page chip; then I understand. But what 
if the read/write is not of such a subpage?

Rutger