Chapter 52. The eCos NAND Flash Library

52.1. Description

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:

  • Interrogation to confirm that the expected device is present
  • Reading from and writing to flash pages
  • Erasing flash blocks
  • The ability to divide a single device into multiple partitions, like those of a hard drive
  • Creation and maintenance of a Bad Block Table
  • Use of an Error Correcting Code to detect and correct single-bit errors, and to detect multiple-bit errors
  • Packing of the ECC and application out-of-band data into the spare area on the device

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.


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.

52.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 52.1. Library layout diagram

Library layout diagram

52.1.2. Device support

Before this library can be used on a given board, an appropriate device driver must be created. Each driver is for a particular NAND part or family of parts; the HAL for each board then instantiates the relevant driver(s) appropriately with board-specific glue such as the memory-mapped I/O range to use. Full details on creating a driver are presented in Chapter 54, Writing NAND device drivers.

There is also a Synthetic Target NAND Flash Device for testing purposes, which is present on the synth target.

52.2. Danger, Will Robinson! Danger!

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?

52.3. Differences between NAND and NOR flash

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.

Addressing of data By byte address within the device. Usually expressed as memory-mapped addresses. By row (page) number. Pages are a power of two; commonly 512 or 2048 bytes. Optimised for reading and writing a page at a time. Sometimes supports column (byte) addressing, but this library does not expose such functionality.
Are direct reads and writes possible? [a] Usually Not in general, though a few special-case exceptions exist such as OneNAND devices.
Erase block sizeMay vary across the chipA fixed number of pages, typically 64
Out-of-band dataNot supported A small number of bytes per page - typically 16 "spare" per 512 "data" bytes - are usable by the application. They are read, written and erased at the same time as the "real" page data.
May factory-bad regions [b] exist on the chip? No Typically up to 20 eraseblocks are marked as factory-bad in their OOB area. The OS is expected to scan these to create a Bad Block Table. [c]
May data be rewritten without being erased first?Usually (but only by resetting 1-bits to 0)Usually, on SLC NAND chips; not on MLC chips.
Error detection and correctionNot present Usually automatic. Typically this involves an Error Correcting Code, automatically calculated and stored in the OOB area, then checked on read.

[a] In other words, can the application read flash directly as if it was RAM, or does it have to invoke the driver to copy data in and out?

[b] Regions which were found during manufacture to be bad and marked in some way - usually by placing a special code in the Out Of Band area.

[c] Once a BBT exists it can then be used to keep track of any blocks which fail through wear during the lifetime of the device.

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.

52.4. Preparing for deployment

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.

[1] Usually the first block is guaranteed to be defect free for a certain number of erase cycles. This tends to be necessary if bootstrapping the CPU off NAND, and is an obvious exception to this rule.