Missing: tests for small-page NAND flash chips
Missing: tests for multiple (homogeneous or heterogeneous) NAND Flash Controllers
Missing: tests for multiple (homogeneous or heterogeneous) NAND Flash chips
The NAND Flash library is an optional part of eCos, and is only applicable to some platforms.
NAND Flash generally consists of (one or more) NAND Flash chips and (one or more) NAND Flash controller parts. Since both vary in their functionality as well as in their interface, the eCos NAND Flash library has separate component types for them. For ease of access, a layer is provided that hides the existence of multiple controllers and multiple chips: the Abstract NAND Chip (ANC) acts as if there is a single NAND Flash Chip with a built-in controller.
NAND Flash is different from NOR flash, the type that is approached via the eCos Flash Library. NAND Flash stores its data in pages (usually 256, 512, 1K, 2K or 4KByte). Reading and programming (writing) is done per page. A number of pages (64 is a commonly found value) makes up a block. Erasing is done to blocks. NAND Flash chips can have different Logical Units (LUNs), e.g. planes; a LUN consists of a (large) number of blocks.
NAND flash differs also from NOR flash in reliability. The chips acquire errors during their lifetime. For correcting of limited errors (one bit per page), NAND flash chips provide a spare area for each page where an Error Correcting Code (ECC) must be stored. If a page has more than one faulty bit, the block that contains it is marked 'bad'. NAND flash chips are generally already shipped with bad blocks; these blocks are marked with factory-defined markers in their spare area.
The spare area per page (also called 'Out Of Band' (OOB) area) has extra space for the application to store meta-data. NAND flash file systems generally use that spare area for file system information.
A third field where NAND flash differs from NOR flash is in read access. NOR flash can be memory-mapped, which makes it possible to execute code from NOR flash. NAND flash pages must be read through their controller into RAM for read access, so it is impossible to directly execute code from it. This makes a NAND flash boot loader more complicated. The CPU boot code, or a boot-capable NAND flash controller, must read the first page of boot code stored in the NAND flash chip into RAM, and start executing it. That code must then access the NAND flash controller and copy the rest of the boot code into RAM.
The eCos NAND Flash library provides the following functionality:
identifying installed ANC devices;
multiple heterogeneous controllers per ANC device; multiple heterogeneous chips per controller;
an abstraction layer that hides this multiplicity by presenting an ANC with a uniform page size, spare size and spare layout, and block size;
support for a number of chip command sets: ONFI; large-page chips (approximately a subset of ONFI); and small-page chips;
reading and programming (writing) of NAND Flash pages;
erasing of NAND Flash blocks;
identifying marked bad blocks, and marking blocks bad; factory-marked bad blocks are incorporated into an optional Bad Block Table that mimics MTD's and u-boot's Bad Block Table layout;
optional support for ECC calculation and repair of corrupt bits.
Unlike nearly every other aspect of embedded system programming, getting it wrong with NAND Flash devices can render your target system useless. Some targets have a boot loader in the NAND Flash. Without this boot loader the target will obviously not boot. So before starting to play with this library it's worth investigating a few things. How do you recover your target if you delete the boot loader? Do you have the necessary JTAG cable? Or is specialist hardware needed? Is it even possible to recover the target board or must it be thrown into the rubbish bin? How does killing the board affect your project schedule?