This is a library which allows NAND flash devices to be accessed by the eCos kernel and applications. It is analogous to the eCos FLASH library, but for NAND devices. It exists as a separate library because of the fundamental differences between the two types of flash memory.

This library provides the following functionality:

	Note
	The spare area, ECC and bad block table have been deliberately created with the intention of compatibility with current versions of the Linux MTD layer. For example, this would allow a single NAND device to be accessed by RedBoot to load a Linux kernel, which could then go on to use another partition as its root filesystem.

	Tip
	This library is also used as glue to allow appropriate filesystems to use NAND devices. This allows more useful higher-level access by applications and RedBoot via the File I/O and POSIX interfaces. In other words, your application may not need to invoke this library directly, though of course you may still have to write a driver for your chip and/or board.

53.1.1. Structure of the library

This library has two principal interfaces: one for applications to call into it, and another to call out to the chip-specific drivers. (The chip drivers themselves then require support from the relevant platform HAL to allow them to access the physical chip in an appropriate manner for the board - such as the memory-mapped I/O range to use.)

The following diagram illustrates the calls from two applications all the way to an underlying NAND device. Application 1 uses the NAND library directly, whereas application 2 is using a filesystem and the eCos File I/O layer.

Figure 53.1. Library layout diagram

Unlike nearly every other aspect of embedded system programming, getting it wrong with FLASH devices can render your target system useless. Most targets have a boot loader in the FLASH. Without this boot loader the target will obviously not boot. So before starting to play with this library its 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 boards or must it be thrown into the rubbish bin? How does killing the board affect your project schedule?

Most flash devices supported by the eCos Flash library are categorised as NOR flash. These are fundamentally different from NAND flash devices, both in terms of the storage cells deep within the chip, and how they are addressed and used by applications.

Since a NAND chip can in general only be read indirectly, its contents must be copied to RAM before they can be executed. This means that the caveats in the eCos FLASH library about disabling interrupts whilst programming do not apply here, except in special cases such as OneNAND devices.

It is generally not recommended to hard-code physical on-NAND locations in case of factory bad blocks or block failures in the field. ^[1] Instead it is preferable to set up partitions on the chip with a generous safety margin and to store data in a location-independent way. This is commonly achieved by placing logical tags in the spare area of each page, or using a log-structured filesystem such as YAFFS. Such strategies remove the dependence on physical addressing, at the cost of increased complexity.

The upshot of this is that you cannot reliably create a simple binary image to bulk-program in the factory. A more complicated programming operation is required to take account of your chip partitions, logical addressing strategy and any bad blocks which may be encountered during write.