This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: NAND technical review

Ross Younger wrote:
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.


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


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


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 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
* 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]