Flash memory is an electronic (i.e.

no moving parts) non-volatile computer storage device that can be electrically erased and reprogrammed. Flash memory was developed from EEPROM (electrically erasable programmable read-only memory). There are two main types of flash memory, which are named after the NAND and NOR logic gates. The internal characteristics of the individual flash memory cells exhibit characteristics similar to those of the corresponding gates. Whereas EEPROMs had to be completely erased before being rewritten, NAND type flash memory may be written and read in blocks (or pages) which are generally much smaller than the entire device. The NOR type allows a single machine word (byte) to be written or read independently. The NAND type is primarily used in main memory memory cards, USB flash drives, solid-state drives, and similar products, for general storage and transfer of data. The NOR type, which allows true random access and therefore direct code execution, is used as a replacement for the older EPROM and as an alternative to certain kinds of ROM applications. However, NOR flash memory may emulate ROM primarily at the machine code level; many digital designs need ROM (or PLA) structures for other uses, often at significantly higher speeds than (economical) flash memory may achieve. NAND or NOR flash memory is also often used to store configuration data in numerous digital products, a task previously made possible by EEPROMs or battery-powered static RAM. Example applications of both types of flash memory include personal computers, PDAs, digital audio players, digital cameras, mobile phones, synthesizers, video games, scientific instrumentation, industrial robotics, medical electronics, and so on. In addition to being nonvolatile, flash memory offers fast read access times, as fast as dynamic RAM, although not as fast as static RAM or ROM. Its mechanical shock resistance helps explain its popularity over hard disks in portable devices; as does its high durability, being able to withstand high pressure, temperature, immersion in water, etc.[1]

NOR memories
Reading from NOR flash is similar to reading from random-access memory, provided the address and data bus are mapped correctly. Because of this, most microprocessors can use NOR flash memory as execute in place (XIP) memory, meaning that programs stored in NOR flash can be executed directly from the NOR flash without needing to be copied into RAM first. NOR flash may be programmed in a random-access manner similar to reading. Programming changes bits from a logical one to a zero. Bits that are already zero are left unchanged. Erasure must happen a block at a time, and resets all the bits in the erased block back to one. Typical block sizes are 64, 128, or 256 KB. Bad block management is a relatively new feature in NOR chips. In older NOR devices not supporting bad block management, the software or device driver controlling the memory chip must correct for blocks that wear out, or the device will cease to work reliably.

The specific commands used to lock, unlock, program, or erase NOR memories differ for each manufacturer. To avoid needing unique driver software for every device made, special Common Flash Memory Interface (CFI) commands allow the device to identify itself and its critical operating parameters. Besides using NOR memory as random-access ROM, you can use it as a storage device, by taking advantage of random-access programming. Some devices offer read-while-write functionality so that code continues to execute even while a program or erase operation is occurring in the background. For sequential data writes, NOR flash chips typically have slow write speeds, compared with NAND flash.

NAND memories
NAND flash architecture was introduced by Toshiba in 1989.[17] These memories are accessed much like block devices, such as hard disks or memory cards. Each block consists of a number of pages. The pages are typically 512[18] or 2,048 or 4,096 bytes in size. Associated with each page are a few bytes (typically 1/32 of the data size) that can be used for storage of an error correcting code (ECC) checksum. Typical block sizes include:

32 pages of 512+16 bytes each for a block size of 16 KB 64 pages of 2,048+64 bytes each for a block size of 128 KB[19] 64 pages of 4,096+128 bytes each for a block size of 256 KB[20] 128 pages of 4,096+128 bytes each for a block size of 512 KB.

While reading and programming is performed on a page basis, erasure can only be performed on a block basis.[21] Number of Operations (NOPs) is the number of times the pages can be programmed. So far, this number for MLC flash is always one, whereas for SLC flash, it is four.
[citation needed]

NAND devices also require bad block management by the device driver software, or by a separate controller chip. SD cards, for example, include controller circuitry to perform bad block management and wear leveling. When a logical block is accessed by high-level software, it is mapped to a physical block by the device driver or controller. A number of blocks on the flash chip may be set aside for storing mapping tables to deal with bad blocks, or the system may simply check each block at power-up to create a bad block map in RAM. The overall memory capacity gradually shrinks as more blocks are marked as bad. NAND relies on ECC to compensate for bits that may spontaneously fail during normal device operation. A typical ECC will correct a one-bit error in each 2048 bits (256 bytes) using 22 bits of ECC code, or a one-bit error in each 4096 bits (512 bytes) using 24 bits of ECC code.[22] If the ECC cannot correct the error during read, it may still detect the error. When doing erase or program operations, the device can detect blocks that fail to program or erase and mark them bad. The data is then written to a different, good block, and the bad block map is updated.

Most NAND devices are shipped from the factory with some bad blocks. These are typically marked according to a specified bad block marking strategy. By allowing some bad blocks, the manufacturers achieve far higher yields than would be possible if all blocks had to be verified good. This significantly reduces NAND flash costs and only slightly decreases the storage capacity of the parts. When executing software from NAND memories, virtual memory strategies are often used: memory contents must first be paged or copied into memory-mapped RAM and executed there (leading to the common combination of NAND + RAM). A memory management unit (MMU) in the system is helpful, but this can also be accomplished with overlays. For this reason, some systems will use a combination of NOR and NAND memories, where a smaller NOR memory is used as software ROM and a larger NAND memory is partitioned with a file system for use as a non-volatile data storage area. NAND sacrifices the random-access and execute-in-place advantages of NOR. NAND is best suited to systems requiring high capacity data storage. It offers higher densities, larger capacities, and lower cost. It has faster erases, sequential writes, and sequential reads.

Distinction between NOR and NAND flash

NOR and NAND flash differ in two important ways:

the connections of the individual memory cells are different the interface provided for reading and writing the memory is different (NOR allows random-access for reading, NAND allows only page access)

These two are linked by the design choices made in the development of NAND flash. A goal of NAND flash development was to reduce the chip area required to implement a given capacity of flash memory, and thereby to reduce cost per bit and increase maximum chip capacity so that flash memory could compete with magnetic storage devices like hard disks.[citation needed] NOR and NAND flash get their names from the structure of the interconnections between memory cells.[26] In NOR flash, cells are connected in parallel to the bit lines, allowing cells to be read and programmed individually. The parallel connection of cells resembles the parallel connection of transistors in a CMOS NOR gate. In NAND flash, cells are connected in series, resembling a NAND gate. The series connections consume less space than parallel ones, reducing the cost of NAND flash. It does not, by itself, prevent NAND cells from being read and programmed individually. When NOR flash was developed, it was envisioned as a more economical and conveniently rewritable ROM than contemporary EPROM and EEPROM memories. Thus random-access reading circuitry was necessary. However, it was expected that NOR flash ROM would be read much more often than written, so the write circuitry included was fairly slow and could only erase in a block-wise fashion. On the other hand, applications that use flash as a replacement for disk drives do not require word-level write address, which would only add to the complexity and cost unnecessarily.[citation needed]

Flash file systems The basic concept behind flash file systems is the following: when the flash store is to be updated, the file system will write a new copy of the changed data to a fresh block, remap the file pointers, then erase the old block later when it has time.

Transfer rates
NAND flash memory cards are much faster at reading than writing so it is the maximum read speed that is commonly advertised. As a chip wears out, its erase/program operations slow down considerably,[citation needed] requiring more retries and bad block remapping. Transferring multiple small files, each smaller than the chip-specific block size, could lead to a much lower rate. Access latency also influences performance, but less so than with their hard drive counterpart.

Flash file system

From Wikipedia, the free encyclopedia Jump to: navigation, search

A flash file system is a file system designed for storing files on flash memory devices. These are becoming more prevalent as the number of mobile devices is increasing, the cost per memory size decreases, and the capacity of flash memories increases. While a block device layer can emulate a disk drive so that a disk file system can be used on a flash device, this is suboptimal for several reasons:

Erasing blocks: Flash memory blocks have to be explicitly erased before they can be written to. The time taken to erase blocks can be significant, thus it is beneficial to erase unused blocks while the device is idle. Random access: Disk file systems are optimized to avoid disk seeks whenever possible, due to the high cost of seeking. Flash memory devices impose no seek latency. Wear leveling: Flash memory devices tend to wear out when a single block is repeatedly overwritten; flash file systems are designed to spread out writes evenly.

Log-structured file systems have all[citation needed] the desirable properties for a flash file system. Such file systems include JFFS2 and YAFFS. Because of the particular characteristics of flash memory, it is best used with either a controller to perform wear leveling and error correction or specifically designed flash file systems, which spread writes over the media and deal with the long erase times of NAND flash blocks. The basic

concept behind flash file systems is: when the flash store is to be updated, the file system will write a new copy of the changed data over to a fresh block, remap the file pointers, then erase the old block later when it has time.

Filesystems

[edit] JFFS/JFFS2/YAFFS
JFFS was the first flash-specific file system for Linux, but it was quickly superseded by JFFS2, originally developed for NOR flash. Then YAFFS was released in 2002, dealing specifically with NAND flash, and JFFS2 was updated to support NAND flash too.

[edit] LogFS
LogFS, another Linux flash-specific file system, is currently being developed to address the scalability issues of JFFS2

Flash memory controller

From Wikipedia, the free encyclopedia Jump to: navigation, search

A flash memory controller (or flash controller) manages the data stored on flash memory and communicates with a computer or electronic device. Flash memory controllers can be designed for operating in low duty-cycle environments like SD cards, CompactFlash cards, or other similar media for use in digital cameras, PDAs, mobile phones, etc. USB flash drives use flash memory controllers designed to communicate with personal computers through the USB port at a low duty-cycle. Flash controllers can also be designed for higher duty-cycle environments like solid-state drives (SSD) used as data storage for laptop computer systems clear up to missioncritical enterprise storage arrays.[1]

Reading, writing, and erasing

Main article: Flash memory#Principles of operation

When the system or device needs to read data from or write data to the flash memory, it will communicate with the flash memory controller. Simpler devices like SD cards and USB flash drives typically have a small number of flash memory die connected simultaneously. Operations are limited to the speed of the individual flash memory die. In contrast, a high-performance solid-state drive will have as many as 100 or more die organized in a matrix with parallel communication paths to enable speeds at many times faster than is possible to a single flash die.
[citation needed]

JFFS2
From Wikipedia, the free encyclopedia Jump to: navigation, search

JFFS2
Developer Full name David Woodhouse Journalling Flash File System version 2 Introduced (Linux 2.4.10) Features Transparent compression Supported operating systems Linux zlib, rubin and rtime

Journalling Flash File System version 2 or JFFS2 is a log-structured file system for use with flash memory devices.[1] It is the successor to JFFS. JFFS2 has been included in the Linux kernel since the 2.4.10 (2001-09-23) release.

Features
JFFS2 introduced:

Support for NAND flash devices. This involved a considerable amount of work as NAND devices have a sequential I/O interface and cannot be memorymapped for reading. Hard links. This was not possible in JFFS because of limitations in the on-disk format. Compression. Four algorithms are available: zlib, rubin, rtime, and lzo. Better performance. JFFS treated the disk as a purely circular log. This generated a great deal of unnecessary I/O. The garbage collection algorithm in JFFS2 makes this mostly unnecessary.

Design
As with JFFS, changes to files and directories are "logged" to flash in nodes, of which there are two types:

inodes: a header with file metadata, followed by a payload of file data (if any). Compressed payloads are limited to one page. dirent nodes: directory entries each holding a name and an inode number. Hard links are represented as different names with the same inode number. The special inode number 0 represents an unlink.

As with JFFS, nodes start out as valid when they are created, and become obsolete when a newer version has been created elsewhere. Unlike JFFS, however, there is no circular log. Instead, JFFS2 deals in blocks, a unit the same size as the erase segment of the flash medium. Blocks are filled, one at a time, with nodes from bottom up. A clean block is one that contains only valid nodes. A dirty block contains at least one obsolete node. A free block contains no nodes. The garbage collector runs in the background, turning dirty blocks into free blocks. It does this by copying valid nodes to a new block and skipping obsolete ones. That done, it erases the dirty block and tags it with a special marker designating it as a free block (to prevent confusion if power is lost during an erase operation). To make wear-levelling more even and prevent erasures from being too concentrated on mostlystatic file systems, the garbage collector will occasionally also consume clean blocks.

Disadvantages

All nodes must still be scanned at mount time. This is slow and is becoming an increasingly serious problem as flash devices scale upward into the gigabyte range. Writing many small blocks of data can even lead to negative compression rates, so it is essential for applications to use large write buffers. There is no practical way to tell how much usable free space is left on a device since this depends both on how well additional data can be compressed, and the writing sequence.

JFFS The Journaling Flash File System (or JFFS) is a log-structured file system for use on NOR flash memory devices on the Linux operating system. It has been superseded by JFFS2.

Design
Flash memory (specifically NOR flash) must be erased prior to writing. The erase process has several limitations:

Erasing is very slow (typically 1-100 ms per erase block, which is 103-105 times slower than reading data from the same region) It is only possible to erase flash in large segments (usually 64 KiB or more), whereas it can be read or written in smaller blocks (often 512 bytes) Flash memory can only be erased a limited number of times (typically 103106) before it becomes worn out

These constraints combine to produce a profound asymmetry between patterns of read and write access to flash memory. In contrast, magnetic hard disk drives offer nearly symmetrical read and write access: read speed and write speed are nearly identical (as both are constrained by the rate at which the disk spins), it is possible to both read and write small blocks or sectors (typically 512 bytes), and there is no practical limit to the number of times magnetic media can be written and rewritten. Traditional file systems, such as ext2 or FAT which were designed for use on magnetic media typically update their data structures in-place, with data structures like inodes and directories updated on-disk after every modification. This concentrated lack of wear-levelling makes conventional file systems unsuitable for read-write use on flash devices.

Disadvantages

At mount time, the file system driver must read the entire inode chain and then keep it in memory. This can be very slow. Memory consumption of JFFS is also proportional to the number of files in the file system. The circular log design means all data in the filesystem is re-written, regardless of whether it is static or not. This generates many unnecessary erase cycles and reduces the life of the flash medium.

YAFFS Yaffs (Yet Another Flash File System) was designed and written by Charles Manning, of Whitecliffs, New Zealand, for the company Aleph One. Yaffs1 is the first version of this file system and works on NAND chips that have 512 byte pages + 16 byte spare (OOB;Out-Of-Band) areas.[clarification needed] These older chips also generally allow 2 or 3 write cycles per page,[clarification needed] which YAFFS takes advantage of - i.e. dirty pages are marked by writing to a specific spare area byte. Newer NAND flash chips have larger pages, 2048 bytes + 64 bytes spare areas, and stricter write requirements. Each page within an erase block (128 kilobytes) must be written to in sequential order, and each page must be written only once. YAFFS2 was designed to accommodate these newer chips. YAFFS2 is based on the YAFFS1 source code, with the major difference being that

internal structures are not fixed to assume 512 byte sizing, and a block sequence number is placed on each written page. In this way older pages can be logically overwritten without violating the "write once" rule.[clarification needed] YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. [citation needed] It is also designed to be portable and has been used on Linux, WinCE, pSOS, eCos, ThreadX, and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes and bootloaders: it has the same core filesystem but simpler interfacing to the OS and NAND flash hardware. The filesystem is licensed both under the GPL and under per-product licenses available from Aleph One. Yaffs (Yet Another Flash File System) was designed and written by Charles Manning, of Whitecliffs, New Zealand, for the company Aleph One. Yaffs1 is the first version of this file system and works on NAND chips that have 512 byte pages + 16 byte spare (OOB;Out-Of-Band) areas.[clarification needed] These older chips also generally allow 2 or 3 write cycles per page,[clarification needed] which YAFFS takes advantage of - i.e. dirty pages are marked by writing to a specific spare area byte. Newer NAND flash chips have larger pages, 2048 bytes + 64 bytes spare areas, and stricter write requirements. Each page within an erase block (128 kilobytes) must be written to in sequential order, and each page must be written only once. YAFFS2 was designed to accommodate these newer chips. YAFFS2 is based on the YAFFS1 source code, with the major difference being that internal structures are not fixed to assume 512 byte sizing, and a block sequence number is placed on each written page. In this way older pages can be logically overwritten without violating the "write once" rule.[clarification needed] YAFFS is a robust log-structured file system that holds data integrity as a high priority. A secondary YAFFS goal is high performance. YAFFS will typically outperform most alternatives. [citation needed] It is also designed to be portable and has been used on Linux, WinCE, pSOS, eCos, ThreadX, and various special-purpose OSes. A variant 'YAFFS/Direct' is used in situations where there is no OS, embedded OSes and bootloaders: it has the same core filesystem but simpler interfacing to the OS and NAND flash hardware. The filesystem is licensed both under the GPL and under per-product licenses available from Aleph One.

YAFFS2
YAFFS2 is similar in concept to YAFFS1, and shares much of the same code; the YAFFS2 code base supports YAFFS1 data formats through backward compatibility. The main difference is that YAFFS2 needs to jump through significant hoops to meet the "write once" requirement of modern NAND flash.[1]

YAFFS2 marks every newly written block with a sequence number that is monotonically increasing. The sequence of the chunks can be inferred from the block sequence number and the chunk offset within the block. Thereby when YAFFS2 scans the flash and detects multiple chunks that have identical ObjectIDs and ChunkNumbers, it can choose which to use by taking the greatest sequence number. For efficiency reasons YAFFS2 also introduces the concept of shrink headers. For example when a file is resized to a smaller size, YAFFS1 will mark all of the affected chunks as dirty - YAFFS2 cannot do this due to the "write once" rule. YAFFS2 instead writes a "shrink header", which indicates that a certain number of pages before that point are invalid. This lets YAFFS2 reconstruct the final state of the filesystem when the system reboots. YAFFS2 uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc. YAFFS2 later added support for checkpointing, which bypasses normal mount scanning, allowing very fast mount times. Mileage will vary, but mount times of 3 seconds for 2 GB have been reported. Unsorted Block Images (UBI) is an erase block management layer for flash memory devices. UBI serves two purposes, tracking NAND flash bad blocks and providing wear leveling. Wear leveling spreads the erases and writes across the entire flash device. UBI presents logical erase blocks to higher layers and maps these to physical flash erase blocks. UBI was written specifically for UbiFs so that it does not have to deal with wear leveling and bad blocks. However, UBI may also be useful with cramfs and NAND flash; cramfs is not aware of NAND flash bad blocks. The Unsorted Block Image File System (UBIFS) is a successor to JFFS2, and competitor to LogFS,[1] as a file system for use with raw flash memory media.[2] Development began in earnest in 2007, with the first stable release made to Linux kernel 2.6.27 in October 2008.[3] The file system is developed by Nokia engineers with help of the University of Szeged, Hungary. Note that UBIFS works on top of an Unsorted Block Images device, which is itself on top of an MTD device. MTDs are not to be used directly.[4] Two major differences on UBIFS (compared to JFFS2) are that UBIFS supports write caching,[5] and UBIFS errs on the pessimistic side of free space calculation.[6] UBIFS tends to perform better than JFFS2 for large NAND FLASH devices. [7] This is a consequence of UBIFS design goals[8]: faster mounting, quicker access to large files, and improved write speeds. UBIFS also preserves or improves upon JFFS2's on-the-fly compression, recoverability and power fail tolerance.[8] UBIFS's on-the-fly data compression allows zlib (Deflate algorithm) or LZO. JFFS2 stores filesystem indexes in memory whereas UBIFS stores indexes in flash.[9] This directly impacts the scalability of JFFS2 as the tables must be rebuilt every time the volume is mounted. Also, the JFFS2 tables may consume enough system RAM that some images may be unusable.

Unsorted Block Images

[10]

Unsorted Block Images (UBI) is an erase block management layer for flash memory devices. UBI serves two purposes, tracking NAND flash bad blocks and providing wear leveling. Wear leveling spreads the erases and writes across the entire flash device. UBI presents logical erase blocks to higher layers and maps these to physical flash erase blocks. UBI was written specifically for UbiFs so that it does not have to deal with wear leveling and bad blocks. However, UBI may also be useful with cramfs and NAND flash; cramfs is not aware of NAND flash bad blocks. NILFS (New Implementation of a Log-structured File System) is a log-structured file system implementation for Linux. It is being developed by Nippon Telegraph and Telephone Corporation (NTT) CyberSpace Laboratories and released under the terms of the GNU General Public License (GPL).

What is NILFS?
NILFS is a new implementation of a log-structured file system (LFS) supporting continuous snapshotting. In addition to versioning capability of the entire file system, users can even restore files mistakenly overwritten or destroyed just a few seconds ago. Since NILFS can keep consistency like conventional LFS, it achieves quick recovery after system crashes. NILFS creates a number of checkpoints every few seconds or per synchronous write basis (unless there is no change). Users can select significant versions among continuously created checkpoints, and can change them into snapshots which will be preserved until they are changed back to checkpoints. There is no limit on the number of snapshots until the volume gets full. Each snapshot is mountable as a read-only file system. It is mountable concurrently with a writable mount and other snapshots, and this feature is convenient to make consistent backups during use. Snapshot administration is easy and quickly performable. NILFS will make snapshotting or versioning of the POSIX filesystem much familiar to you. The possible use of NILFS includes, versioning, tamper detection, SOX compliance logging, and so forth. It can serve as an alternative filesystem for Linux desktop environment, or as a basis of advanced storage appliances. The current major version of NILFS is version 2, which is referred to as NILFS2. NILFS2 realized online garbage collection that reclaims disk space with keeping multiple snapshots. Other NILFS features include:

B-tree based file and inode management. Immediate recovery after system crash.

64-bit data structures; support many files, large files and disks. 64-bit on-disk timestamps which are free of the year 2038 problem. Loadable kernel module; no recompilation of the kernel is required.
With that in mind, let us now concentrate on the creation and installation of a JFFS2 filesystem image. Mainly, we will use the mkfs.jffs2 utility installed in the previous chapter as part of the MTD utilities installation.

The creation of a JFFS2 image is fairly simple:

$ cd ${PRJROOT} $ mkfs.jffs2 -r rootfs/ -o images/rootfs-jffs2.img

We use the -r option to specify the location of the directory containing the root filesystem, and the-o option to specify the name of the output filewhere the filesystem image should be stored. In addition to these options, we could use -l or-b to create little endian or big endian images, respectively. The JFFS2 compression ratio is much smaller than CRAMFS. For a root filesystem containing 7840 KB, for example, the resulting JFFS2 image is 6850 KB in size. The compression ratio is a little above 10%.

Once you create the JFFS2 image, you can write it to its designated MTD device. If this device is accessible on the host, you can carry out the appropriate commands directly on the host. Otherwise, follow the instructions in Section 8.2: boot your target with an NFS-mounted root filesystem, place the JFFS2 image on that filesystem, and issue the commands on the target to write the image to the designated MTD device. Regardless of your setup, you first need to erase the MTD device where the image will be placed:

# eraseall /dev/mtd5 Erased 8192 Kibyte @ 0 -- 100% complete.

Obviously, the space available on the MTD storage device must be equal to or larger than the JFFS2 image you are placing on it. With the MTD device erased, copy the JFFS2 image to the MTD partition:

# cat images/rootfs-jffs2.img > /dev/mtd5

Now, mount the copied filesystem to take a look at it:

# mount -t jffs2 /dev/mtdblock5 /mnt # mount ... /dev/mtdblock5 on /mnt type jffs2 (rw) # ls mnt bin etc linuxrc sbin usr dev lib proc tmp var # umount mnt
Unlike disk filesystems, JFFS2cannot be mounted on loopback using a mount -o loop ... command to view its content. Instead, it must be mounted from a real MTD device as done above. If you have no real MTD

device on your host, such as CFI flash, you could use the virtual memory MTD device presented in Chapter 3. You could also use the jffs2reader command introduced in the previous chapter to view the image's content.

If your target had previously been using an NFS-mounted root filesystem, you are now ready to boot it using the JFFS2 filesystem as its root filesystem.

Flash memory technologies Flash memory, which can come in several different technologies, is non-volatile memory, which means that its contents persist after its source of power is removed. For a great history of flash memory devices, see Resources. Two of the most common types of flash devices are defined by their respective technologies: NOR and NAND. NOR-based flash is the older technology that supported high read performance at the expense of smaller capacities. NAND flash offers higher capacities with significantly faster write and erase performance. NAND also requires a much more complicated input/output (I/O) interface. Flash parts are commonly divided into partitions, which allows multiple operations to occur simultaneously (erasing one partition while reading from another). Partitions are further divided into blocks (commonly 64KB or 128KB in size). Firmware that uses the partitions can further apply unique segmenting to the blocksfor example, 512-byte segments within a block, not including metadata. Flash devices exhibit a common constraint that requires device management when compared to other storage devices such as RAM disks. The only Write operation permitted on a flash memory device is to change a bit from a one to a zero. If the reverse operation is needed, then the block must be erased (to reset all bits to the one state). This means that other valid data within the block must be moved for it to persist. NOR flash memory can typically be programmed a byte at a time, whereas NAND flash memory must be programmed in multi-byte bursts (typically, 512 bytes). The process of erasing a block differs between the two memory types. Each requires a special Erase operation that covers an entire block of the flash memory. NOR technology requires a precursor step to clear all values to zero before the Erase operation can begin. An Erase is a special operation with the flash device and can be time-consuming. Erasing is an electrical operation that drains the electrons from each cell in an entire block. NOR flash devices typically require seconds for the Erase operation, whereas a NAND device can erase in milliseconds. A key characteristic of flash devices is the number of Erase operations that can be performed. In a NOR device, each block in the flash memory can be erased up to 100,000 times. NAND flash memories can be erased up to one million times. Back to top Flash memory challenges In addition to and as a result of the constraints explored in the previous section, managing flash devices presents several challenges. The three most important are garbage collection, managing bad blocks, and wear leveling. Garbage collection

Garbage collection is the process of reclaiming invalid blocks (those that contain some amount of invalid data). Reclamation involves moving the valid data to a new block, and then erasing the invalid block to make it available. This process is commonly done in the background or as needed, if the file system is low on available space. Managing bad blocks Over time, flash devices can develop bad blocks through use and can even ship from the manufacturer with blocks that are bad and cannot be used. You can detect the presence of back blocks from a failed flash operation (such as an Erase) or an invalid Write operation (discovered through an invalid Error Correction Code, or ECC). After bad blocks have been identified, they are marked within the flash itself in a bad block table. How this is done is device-dependent but can be implemented with a separate set of reserved blocks managed separately from normal data blocks. The process of handling bad blockswhether they ship with the device or appear over timeis called bad block management. In some cases, this functionality is implemented in hardware by an internal microcontroller and is therefore transparent to the upper-level file system. Wear leveling Recall that flash devices are consumable parts: You can perform a finite number of Erase cycles on each block before the block becomes bad (and must therefore be tagged by bad block management). To maximize the life of the flash, wear-leveling algorithms are provided. Wear leveling comes in two varieties: dynamic wear leveling and static wear leveling. Dynamic wear leveling addresses the problem of a limited number of Erase cycles for a given block. Rather than randomly using blocks as they are available, dynamic wearleveling algorithms attempt to evenly distribute the use of blocks so that each gets uniform use. Static wear-leveling algorithms address an even more interesting problem. In addition to a maximum number of Erase cycles, certain flash devices suffer from a maximum number of Read cycles between Erase cycles. This means that if data sits for too long in a block and is read too many times, the data can dissipate and result in data loss. Static wear-leveling algorithms address this by periodically moving stale data to new blocks. Back to top System architecture So far, I've explored flash devices and their fundamental challenges. Now, look at how these pieces come together as part of a layered architecture (see Figure 1). At the top is the virtual file system (VFS), which presents a common interface to higher-level applications. The VFS is followed by the flash file system, which will be covered in the next section. Next is the Flash Translation Layer (FTL), which provides for overall management of the flash device, including allocation of blocks from the underlying flash device as well as address translation, dynamic wear leveling, and garbage collection. In some flash devices, a portion of the FTL can be implemented in hardware.

Figure 1. Basic architecture of a flash system

The Linux kernel uses the Memory Technology Device (MTD) interface, which is a generic interface for flash devices. The MTD can automatically detect the width of the flash device bus and the number of devices necessary for implementing the bus width. Back to top Flash file systems Several flash file systems are available for Linux. The next sections explain the design and advantages of each. Journaling Flash File System One of the earliest flash file systems for Linux is called the Journaling Flash File System. JFFS is a log-structured file system that was designed for NOR flash devices. It was unique and addressed a variety of problems with flash devices, but it created another. JFFS viewed the flash device as a circular log of blocks. Data written to the flash is written to the tail, and blocks at the head are reclaimed. The space between the tail and head is free space; when this space becomes low, the garbage collector is executed. The garbage collector moves valid blocks to the tail of the log, skips invalid or obsolete blocks, and erases them (see Figure 2). The result is a file system that is automatically wear leveled both statically and dynamically. The fundamental problem with this architecture is that the flash device is erased too often (instead of an optimal erase strategy), which wears the device out too quickly.

Figure 2. Circular log before and after garbage collection

When a JFFS is mounted, the structural details are read into memory, which can be slow at mount-time and consume more memory than desired. Journaling Flash File System 2 Although JFFS was very useful in its time, its wear-leveling algorithm tended to shorten the life of NOR flash devices. The result was a redesign of the underlying algorithm to remove the circular log. The JFFS2 algorithm was designed for NAND flash devices and also includes improved performance with compression. In JFFS2, each block in the flash is treated independently. JFFS2 maintains block lists to sufficiently wear-level the device. The clean list represents blocks on the device that are full of valid nodes. The dirty list contains blocks with at least one obsoleted node. Finally, the free list represents the blocks that have been erased and are available for use. The garbage collection algorithm can then intelligently decide what to reclaim in a reasonable way. Currently, the algorithm probabilistically selects from the clean or dirty list. The dirty list is selected 99 percent of the time to reclaim blocks (moving the valid contents to another block), and the clean list is selected 1 percent of the time (simply moving the contents to a new block). In both cases, the selected block is erased and placed on the free list (see Figure 3). This allows the garbage collector to re-use blocks that are obsoleted (or partially so) but still move data around the flash to support static wear leveling. Figure 3. Block management and garbage collection in JFFS2

Yet Another Flash File System

YAFFS is another flash file system developed for NAND flash. The initial version (YAFFS) supported flash devices with 512-byte pages, but the newer version (YAFFS2) supports newer devices with larger page sizes and greater Write constraints. In most flash file systems, obsolete blocks are marked as such, but YAFFS2 additionally marks blocks with monotonically increasing sequence numbers. When the file system is scanned at mount time, the valid inodes can be quickly identified. YAFFS also maintains trees in RAM to represent the block structure of the flash device, including fast mounting through checkpointing the process of saving the RAM tree structure to the flash device on a normal unmount so that it can be quickly read and restored to RAM at mount time (see Figure 4). Mount-time performance is a great advantage of YAFFS2 over other flash file systems.

Figure 4. YAFFS2 mount-time optimization through checkpointing

Back to top Read-only compressed file systems In some embedded systems, there's no need to provide a mutable file system: An immutable one will suffice. Linux supports a variety of read-only file systems, two of the most useful are cramfs and SquashFS. Cramfs The cramfs file system is a compressed read-only Linux file system that can exist within flash devices. The primary characteristics of cramfs are that it is both simple and spaceefficient. This file system is used in small-footprint embedded designs. While cramfs metadata is not compressed, cramfs uses zlib compression on a per-page basis to allow random page access (pages are decompressed upon access). You can play with cramfs using the mkcramfs utility and the loopback device. SquashFS SquashFS is another compressed read-only Linux file system that is useful within flash devices. You'll also find SquashFS in numerous Live CD Linux distributions. In addition

to supporting zlib for compression, SquashFS uses Lembel-Ziv-Markov chain Algorithm (LZMA) for improved compression and speed. Like cramfs, you can use SquashFS on a standard Linux system with mksquashfs and the loopback device. Back to top Going further Like most of open source, software continues to evolve, and new flash file systems are under development. An interesting alternative still in development is LogFS, which includes some very novel ideas. For example, LogFS maintains a tree structure on the flash device itself so that the mount times are similar to traditional file systems, such as ext2. It also uses a wandering tree for garbage collection (a form of B+tree). What makes LogFS particularly interesting, however, is that it is very scalable and can support large flash parts. With the growing popularity of flash file systems, you'll see a considerable amount of research being applied toward them. LogFS is one example, but other options, such as UbiFS, are also growing. Flash file systems are interesting architecturally and will continue to be a source of innovation in the future.
u-boot> tftp 0x70000000 rootfs.jffs2 u-boot> nand erase clean 0x500000 $filesize u-boot> nand write.jffs2 0x70000000 0x500000 $filesize ROOTFS programming into the NAND flash for PM9263/PM9261 A. Using PEEDI peedi> flash set 2 peedi> flash erase peedi> flash program
uboot=u-boot-overo.bin uimage=uImage-overo.bin rootfs=omap3-desktop-nand-image-overo.ubi if [ -e $uboot ]; then echo "Erasing u-boot partition ..." flash_erase /dev/mtd1 0 0 echo "Erasing u-boot environment partition ..." flash_erase /dev/mtd2 0 0 echo "Writing u-boot to NAND ..." nandwrite -p /dev/mtd1 $uboot else echo "ERROR: fi if [ -e $uimage ]; then echo "Erasing kernel partition ..." flash_erase /dev/mtd3 0 0 echo "Writing kernel to NAND ..." couldn't find u-boot binary"

Replacing MLO

nandwrite -p /dev/mtd3 $uimage else echo "ERROR: fi if [ -e $rootfs ]; then umount /dev/mtdblock4 echo "Writing rootfs to NAND ..." ubiformat -y /dev/mtd4 -f $rootfs else echo "ERROR: fi couldn't find rootfs ubi" couldn't find kernel binary"

The Overo COM bootstrap loader MLO (x-load) requires hardware error checking which is available within the u-boot environment. The following commands issued at the u-boot prompt write four copies of an MLO (filename="MLO") from the FAT partition of a microSD card to Flash memory on the COM. Four copies are used for redundancy in case of corruption.

Overo # mmc rescan 0 Overo # fatload mmc 0 $loadaddr MLO reading MLO 24220 bytes read Overo # nandecc hw HW ECC selected Overo # nand erase 0 80000 NAND erase: device 0 offset 0x0, size 0x80000 Erasing at 0x60000 -- 100% complete. OK Overo # nand write $loadaddr 0 20000 NAND write: device 0 offset 0x0, size 0x20000 131072 bytes written: OK Overo # nand write $loadaddr 20000 20000 ... Overo # nand write $loadaddr 40000 20000 ... Overo # nand write $loadaddr 60000 20000 ...

Alternatively, you can write a u-boot script to flash MLO. $ nano flash-MLO.cmd fatload mmc 0 $loadaddr MLO nandecc hw nand erase 0 80000 nand write $loadaddr 0 20000 nand write $loadaddr 20000 20000 nand write $loadaddr 40000 20000 nand write $loadaddr 60000 20000 Make the script readable by u-boot. $ mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "flash-MLO" -d flash-MLO.cmd flash-MLO.scr Copy flash-MLO.scr to your boot partition, insert the microSD card in your COM and wait for u-boot to load from mmc. Interrupt the boot process when you see Hit any key to stop autoboot and enter these commands. # mmc rescan 0; fatload mmc 0 ${loadaddr} flash-MLO.scr; source ${loadaddr}

At runtime, you can interrogate the NAND flash to make sure things are detected properly.
bfin> nand info Device 0: NAND 256MiB 3,3V 8-bit, sector size 128 KiB

Here we can see that there is a 2 gigabit NAND flash hooked up. Good times.

Reading
You use the nand read command to read a range of bytes from the NAND flash into memory. From there, you can do anything you like with it. For example, if we want to read 0x1000 bytes at an offset of 0x300 bytes from the start of the NAND flash into external memory at 0x20000, we'd simply run:
bfin> nand read 0x20000 0x300 0x1000 NAND read: device 0 offset 0x300, size 0x1000 4096 bytes read: OK

The nand read command does not support bad blocks. If you want to include bad block handling, just append .jffs2 to the command.
bfin> nand read.jffs2 0x20000 0x300 0x1000 NAND read: device 0 offset 0x300, size 0x1000 Reading data from 0xb00 -- 100% complete. 4096 bytes read: OK

Erasing
Like all other flash devices, you need to erase things before you write them. The nand erase command will do this for you.

Writing
You use the nand write command to write a range of bytes from memory into the NAND flash. This command does not handle bad blocks, so if you want that, just append .jffs2 to the write as in the nand read example.
The write.jffs2 command has nothing to do with jffs2 and is poorly named - it just means skip bad blocks.
help nand nand nand nand info device [dev] read[.jffs2]

- show available NAND devices - show or set current device - addr off|partition size

nand write[.jffs2] - addr off|partiton size - read/write `size' bytes starting at offset `off' to/from memory address `addr' nand erase [clean] [off size] - erase `size' bytes from offset `off' (entire device if not specified) nand bad - show bad blocks nand dump[.oob] off - dump page nand scrub - really clean NAND erasing bad blocks (UNSAFE) nand markbad off - mark bad block at offset (UNSAFE) nand biterr off - make a bit error at offset (UNSAFE) nand lock [tight] [status] - bring nand to lock state or display locked pages nand unlock [offset] [size] - unlock section bfin> nand erase clean NAND erase: device 0 whole chip Erasing at 0x7fe0000 -- 100% complete. Cleanmarker written at 0x7fe0000. OK bfin> nand write.jffs2 0x1000000 0x0 0x260000 NAND write: device 0 offset 0x0, size 0x260000 2490368 bytes written: OK bfin> help nboot nboot [partition] | [[[loadAddr] dev] offset] bfin> nand device Device 0: NAND 128MiB 3,3V 8-bit bfin> nboot 0x2000000 0x0 Loading from NAND 128MiB 3,3V 8-bit, offset 0x0 Image Name: uClinux Kernel and ext2 Created: 2007-03-27 0:24:27 UTC Image Type: Blackfin Linux Kernel Image (gzip compressed) Data Size: 2453995 Bytes = 2.3 MB Load Address: 00001000 Entry Point: 00001000 Automatic boot of image at addr 0x02000000 ... ## Booting image at 02000000 ... Image Name: uClinux Kernel and ext2 Created: 2007-03-27 0:24:27 UTC Image Type: Blackfin Linux Kernel Image (gzip compressed) Data Size: 2453995 Bytes = 2.3 MB Load Address: 00001000 Entry Point: 00001000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK Starting Kernel at = 1000 Linux version 2.6.19.3-ADI-2007R1-pre-svn2931 (test@linux) (gcc version 4.1.1 (ADI 07R1)) #5 Mon Ma7

NAND FLASH
NAND vs. NOR
Beside the different silicon cell design, the most important difference between NAND and NOR Flash is the bus interface. NOR Flash is connected to a address / data bus direct like other memory devices as SRAM etc. NAND Flash uses a multiplexed I/O Interface with some additional control pins. NAND flash is a sequential access device appropriate for mass storage applications, while NOR flash is a random access device appropriate for code storage application.NOR Flash can be used for code storage and code execution. Code stored on NAND Flash can't be executed frome there. It must be loaded into RAM memory and executed from there.
NOR Interface Cell Size Cell Cost Read Time Program Time single Byte Program Time multi Byte Erase Time Power consumption Can execute code Bus Large High Fast Fast NAND I/O Small Low Slow Slow

Slow Slow High Yes nearly unrestricted

Fast Fast Low, but requires additional RAM No, but newer chips can execute a small loader out of the first page 1-3 times, also known as "partial page program restriction" Allowed

Bit twiddling

Bad blocks at ship time No

Some facts about write speed. NAND is typically faster than NOR for large writes. A typical NOR write is 10uS per word, which results in 1280uS per 512 bytes on a 32-bit bus. A typical NAND write is

50nS per byte + 10uS page seek + 200uS program which results in 236uS per 512 bytes on a 8 bit bus. As NAND Flash is cheaper than NOR Flash and has a very slim interface it was selected as the optimum solution for large nonvolatile storage applications such as solid state file storage, digital audio/voice recorder, digital still camera and portable applications requiring non-volatility.

NAND Types
There are various types of NAND Flash available. Bare NAND chips, SmartMediaCards, DiskOnChip. SmartMediaCards are bare NAND chips covered by thin plastic. They are very common in digital cameras and MP3 players. The card itself contains nothing smart at all. It gets smart by software. DiskOnChip is NAND Flash with additional glue logic as a drop in replacement for NOR Flash chips. The glue logic provides direct memory access to a small address window, which contains a boot loader stub, which loads the real boot code from the NAND device. The logic contains also control registers for the static NAND chip control lines and a hardware ECC generator.

NAND technical view

The memory is arranged as an array of pages. A page consists of 256 / 512 Byte data and 8 / 16 Byte spare (out of band) area. Newer chips have 2048 Bytes data and and 64 Bytes spare area sizes. The spare area is used to store ECC (error correction code), bad block information and filesystem dependend data. n pages build one block. The read / write access to data is on a per page basis. Erase is done on a per block basis. The commands to read / write / erase the chip is given by writing to the chip with the Command Latch Enable pin high. Address is given by writing with the Address Latch Enable pin high. There are only a few lines neccecary to access NAND Flashmemory. 16 bit buswidth chips are supported.
Pin(s) Function

I/O 0-7(15) Data Inputs/Outputs /CE Chip Enable

CLE ALE /RE /WE /WP /SE R/B

Command Latch Enable Address Latch Enable Read Enable Write Enable Write Protect Spare area Enable Ready / Busy Output

As it is neccecary to use the spare area, the /SE (Spare area Enable) pin should be tied to GND. /CE, CLE and ALE should be GPIO pins or latched signals. It's possible to use address lines for ALE and CLE, but you have to take care about the timing restrictions of the chip ! /RE and /WE can be tied to the corresponding lines of the CPU. Make sure, that they are logicaly combined with the corresponding chipselect. You can also use two different chipselects for /RE and /WE, but be aware of data hold time constraints of your NAND chip. Data hold time after rising edge of /WE is different to data hold time after rising edge of chipselect lines! I/O 0-7(15) are connected to the databus D0-D7(D15). The /WP pin can be used for write protection or connected to VCC to enable writes unconditionally. As NAND flash uses a command driven programming and erasing, an accidential write or erase is not likely to happen. The Ready / Busy output is not neccecary for operation, but it can be tied to a GPIO or an interrupt line.

Filesystems supporting NAND

One major problem for using NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 13 writes, depending on the manufacturers specifications. This applies similar to the spare area. This makes it neccecary for the filesystem to handle a writebuffer, which contains data, that is less than a page At the moment there are only a few filesystems, which support NAND

JFFS2 and YAFFS for bare NAND Flash and SmartMediaCards NTFL for DiskOnChip devices TRUEFFS from M-Systems for DiskOnChip devices

SmartMedia DOS-FAT as defined by the SSFDC Forum

JFFS2 and NTFL are Open Source, while TRUEFFS is a proprietary solution. SmartMedia DOS-Fat is a specification from SSFDC forum. It is somewhat open under a non disclosure agreement with Toshiba, who owns all rights on this specifications. NTFL is designed for the usage of DiskOnChip devices. JFFS2 supports raw NAND chips and SmartMediaCards at the moment. A JFFS2 support for DiskOnChip devices, based on the NAND code, is planned. There are some other Open Source projects for NAND filesystem support, but there's no other working solution than JFFS2 and YAFFS at the moment of this writing. YAFFS is available from YAFFS-Homepage. YAFFS is faster than JFFS2 and consumes less RAM, JFFS2 provides on the fly file compression and decompression, which is very helpfull for small FLASHs. There is currently no support for the wide spread SmartMedia DOS-FAT filesystem, mainly because it's not a reliable filesystem for industrial usage. It's ok for multimedia applications. The hardware support layer is designed to support an implementation of SmartMedia DOS-FAT. There are some efforts to implement it, but it's in an early stage. There are a couple of SmartMedia Card adaptors for USB, PCMCIA, FireWire ... with Linux drivers available, which support the SmartMedia DOS-FAT. JFFS2 and YAFFS include bad block management, wear leveling, error correction and provide reliable filesystems for industrial use on top of NAND Flash.

JFFS2 specific information

JFFS2 Out of Band usage

JFFS2 uses the default autoplacement scheme. The only JFFS2 specific usage of the oob area is the storage of the cleanmarker

Nand chips with 256 byte pagesize and 8 byte OOB size
Offset Content Comment

0x06

Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 0 to 0x85. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 1 to 0x19. In the remaining pages this byte is reserved

0x07

Nand chips with 512 byte pagesize and 16 byte OOB size
Offset Content Comment

0x08

Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 0 to 0x85. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 1 to 0x19. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 2 to 0x03. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 3 to 0x20. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 4 to 0x08. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 5 to 0x00. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 6 to 0x00. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 7 to 0x00. In the remaining pages this byte is reserved

0x09

0x0a

0x0b

0x0c

0x0d

0x0e

0x0f

Nand chips with 2048 byte pagesize and 64 byte OOB size
Offset Content Comment

0x10

Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 0 to 0x85. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page

0x11

marker byte was succesfully erased this byte in the first page of a block is programmed 1 to 0x19. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 2 to 0x03. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 3 to 0x20. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 4 to 0x08. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 5 to 0x00. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 6 to 0x00. In the remaining pages this byte is reserved Clean This byte indicates that a block was erased under JFFS2 control. If the page marker byte was succesfully erased this byte in the first page of a block is programmed 7 to 0x00. In the remaining pages this byte is reserved

0x12

0x13

0x14

0x15

0x16

0x17

HOWTO implement NAND support

Where can you get the code ?

The latest changes to JFFS2 and the underlying NAND code are not in the kernel code at the moment. The latest code is available from CVS and daily snapshots There are four layers of software
1. 2. 3. 4. JFFS2: filesystem driver MTD: Memory Technology Devices driver NAND: generic NAND driver Hardware specific driver

the MTD driver just provides a mount point for JFFS2. The generic NAND driver provides all functions, which are neccecary to identify, read, write and erase NAND Flash. The hardware dependend functions are provided by the hardware driver. They

provide mainly the hardware access informations and functions for the generic NAND driver. For YAFFS applies the same.

API Documentation
A complete API documentation is available as DocBook template in the Documentation/DocBook directory of the MTD source tree. Read the API documentation online

Supported chips
Most NAND chips actually available should be supported by the current code. If you have a chip, which is not supported, you can easily add it by extending the chiplist in drivers/mtd/nand/nand_ids.c. The chip name does not longer contain cryptic part numbers, as the device ID is just an information about size, erase block size, pagesize and operating voltage. Add an entry, which contains following information: { name, id, pagesize, chipsize, erasesize, options }
ref name id comment string: "NAND 'size' 'voltage' 'bus-width'" chip device code. This code is read during nand_scan. Check datasheet for the code of your chip Page size (0,256,512). 0 indicates that the pagesize can be read out from the chip in the extended ID The total size of the chip in MiB

pagesize chipsize

erasesize the erasesize of your chip in bytes. 0 for chips with extended ID options Options. Bitfield to enable chip specific options. See nand.h

Please contact NAND driver maintainer to include it in the public source tree. Manufacturer codes are scanned during nand_scan too. If the code is one of the known codes in the manufacturer ID table, the name of the manufacturer is printed out, else "Unknown" is printed. This happens when your hardware driver is loaded and calls nand_scan. Add codes, which are new and contact NAND driver maintainer to include it

Config settings

The following config switches have to be set. JFFS2 on NAND does not work, if one of these settings is missing. CONFIG_MTD=y CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_YOURBOARD=y CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_NAND=y Make sure that fs/Config.in contains the following lines: dep_tristate 'Journalling Flash File System v2 (JFFS2) support' CONFIG_JFFS2_FS $CONFIG_MTD if [ "$CONFIG_JFFS2_FS" = "y" -o "$CONFIG_JFFS2_FS" = "m" ] ; then int 'JFFS2 debugging verbosity (0 = quiet, 2 = noisy)' CONFIG_JFFS2_FS_DEBUG 0 bool 'JFFS2 support for NAND chips' CONFIG_JFFS2_FS_NAND fi

FAQ
Please see the NAND section in MTD FAQ's

References:

Open Source
JFFS2 and NTFL are located on this website. YAFFS is located at YAFFS-Homepage.

Hardware
Toshiba Samsung SSFDC Forum M-Systems

Maintainers
JFFS2 is maintained by David Woodhouse The generic NAND driver is maintained by Thomas Gleixner

sysfs
The sysfs filesystem is an in-memory virtual filesystem that provides a view of the kobject object hierarchy. It enables users to view the device topology of their system as a simple filesystem. Using attributes, kobjects can export files that allow kernel variables to be read from and optionally written to. Although the intended purpose of the device model was initially to provide a device topology for power management reasons, a quite spectacular offshoot was sysfs. To facilitate debugging, the device model's developer decided to export the tree as a filesystem. This quickly proved quite useful, at first as a replacement for device-related files that previously found themselves in /proc, and later as a powerful view into the system's object hierarchy. Indeed, sysfs, originally called driverfs, predated kobjects. Eventually sysfs made it clear that a new object model would be quite beneficial, and kobject was born. Today, every system with a 2.6 kernel has sysfs and nearly all have it mounted. The magic behind sysfs is simply tying kobjects to directory entries via the dentry variable inside each kobject. Recall from Chapter 12, "The Virtual Filesystem," that the dentry structure represents directory entries. By linking kobjects to dentries, kobjects trivially map to directories. Exporting the kobjects as a filesystem is now as easy as building a tree of the dentries in memory. But wait! kobjects already form a tree, our beloved device model. With kobjects mapping to dentries and the object hierarchy already forming an in-memory tree, sysfs became trivial. Figure 17.2 is a partial view of the sysfs filesystem as mounted at /sys. Figure 17.2. A view of part of the /sys tree.

The root of the sysfs contains seven directories: block, bus, class, devices, firmware, module, and power. The block directory contains one directory for each of the registered block devices on the system. Each of those directories, in turn, contains any partitions on the block device. The bus directory provides a view of the system buses. The class directory contains a view of the devices on the system organized by high-level function. The devices directory is a view of the device topology of the system. It maps directly to the hierarchy of device structures inside the kernel. The firmware directory contains a system-specific tree of low-level subsystems such as ACPI, EDD, EFI, and so on. The power directory contains system-wide power management data. The most important directory is devices, which exports the device model to the world. The directory structure is the actual device topology of the system. Much of the data in other directories is simply alternative organizations of the data in the devices directory. For example, /sys/class/net/ organizes devices by the high-level concept of

registered network interfaces. Inside this directory might be the subdirectory eth0, which contains the symlink device back to the actual device directory in devices. Take a look at /sys on any Linux systems that you have access to. Such an accurate view into the system's device is pretty neat, and seeing the interconnection between the high-level concepts in class versus the low-level physical devices in devices and the actual drivers in bus is very informative. The whole experience is even more rewarding when you realize that this data is free, that this is the very representation of the system maintained inside the kernel[1].
[1]

If you find sysfs interesting, you might be interested in HAL, a hardware abstraction layer, which can be found at http://hal.freedesktop.org/. HAL builds an in-memory database based on the data in sysfs, linking together the concepts of class, device, and driver. On top of this data, HAL provides a rich API allowing for smarter, more aware applications.

Adding and Removing kobjects from sysfs

Initialized kobjects are not automatically exported to sysfs. To represent a kobject to sysfs, you use kobject_add():
int kobject_add(struct kobject *kobj);

The kobject's location in sysfs depends on the kobject's location in the object hierarchy. If the kobject's parent pointer is set, the kobject will map to a subdirectory in sysfs inside its parent. If the parent pointer is not set, the kobject will map to a subdirectory inside kset->kobj. If neither the parent nor the kset fields are set in the given kobject, the kobject is assumed to have no parent and will map to a root-level directory in sysfs. This is almost assuredly what you want, so one or both of parent and kset should be set appropriately before kobject_add() is called. Regardless, the name of the directory representing the kobject in sysfs is given by kobj->k_name. Rather than call both kobject_init() and kobject_add(), you can call kobject_register():
int kobject_register(struct kobject *kobj)

This function both initializes the given kobject and adds it to the object hierarchy. Removing a kobject's sysfs representation is done via kobject_del():
void kobject_del(struct kobject *kobj);

The function kobject_unregister() combines both kobject_del() and kobject_put():

void kobject_unregister(struct kobject * kobj)

All four of these functions are defined in lib/kobject.c and declared in <linux/kobject.h>.

Adding Files to sysfs

kobjects map to directories, and the complete object hierarchy maps nicely to the complete sysfs directory structure, but what about files? sysfs is nothing but a pretty tree without files to provide actual data.

Default Attributes
A default set of files is provided via the ktype field in kobjects and ksets. Consequently, all kobjects of the same type have the same default set of files populating their sysfs directories. The kobj_type structure contains a member, default_attrs, that is an array of attribute structures. Attributes map kernel data to files in sysfs. The attribute structure is defined in <linux/sysfs.h>:
/* attribute structure - attributes map kernel data to a sysfs file */ struct attribute { char *name; /* attribute's name */ struct module *owner; /* owning module, if any */ mode_t mode; /* permissions */ };

The name member provides the name of this attribute. This will be the filename of the resulting file in sysfs. The owner member points to a module structure representing the owning module, if any. If a module does not own this attribute, this field is NULL. The mode member is a mode_t type that specifies the permissions for the file in sysfs. Readonly attributes probably want to set this to S_IRUGO if they are world readable and S_IRUSR if they are only owner readable. Writable attributes probably want to set mode to S_IRUGO | S_IWUSR. All files and directories in sysfs are owned by uid zero and gid zero. Although default_attrs lists the default attributes, sysfs_ops describes how to use them. The sysfs_ops member is a pointer to a structure of the same name, which is defined in <linux/sysfs.h>:
struct sysfs_ops { /* method invoked on read of a sysfs file */ ssize_t (*show) (struct kobject *kobj, struct attribute *attr,

char *buffer); /* method invoked on write of a sysfs file */ ssize_t (*store) (struct kobject *kobj, struct attribute *attr, const char *buffer, size_t size);

};

The show() method is invoked on read. It must copy the value of the attribute given by attr into the buffer provided by buffer. The buffer is PAGE_SIZE bytes in length; on x86, PAGE_SIZE is 4096 bytes. The function should return the size in bytes of data actually written into buffer on success or a negative error code on failure. The store() method is invoked on write. It must read the size bytes from buffer into the variable represented by the attribute attr. The size of the buffer is always PAGE_SIZE or smaller. The function should return the size in bytes of data read from buffer on success or a negative error code on failure. Because this single set of functions must handle file I/O requests on all attributes, they typically need to maintain some sort of generic mapping to invoke a handler specific to each attribute.

Creating New Attributes

Generally, the default attributes provided by the ktype associated with a kobject are sufficient. Indeed, because all the kobjects of the same ktype are supposed to be relatedif not identical in nature as in, say, all partitionsthe same set of attributes should satisfy all kobjects. This not only simplifies life, but also provides code consolidation and a uniform look and feel to sysfs directories of related objects. Nonetheless, often some specific instance of a kobject is somehow special. It wants or even needs its own attributesperhaps to provide data or functionality not shared by the more general ktype. To this end, the kernel provides the sysfs_create_file() interface for adding new attributes on top of the default set:
int sysfs_create_file(struct kobject *kobj, const struct attribute *attr);

This badboy will associate the attribute structure pointed at by attr with the kobject pointed at by kobj. Before it is invoked, the given attribute should be filled out. This function returns zero on success and a negative error code otherwise. Note that the sysfs_ops specified in the kobject's ktype is invoked to handle this new attribute. The existing default show() and store() methods must be capable of handling the newly created attribute.

In addition to creating actual files, it is possible to create symbolic links. Creating a symlink in sysfs is very easy:
int sysfs_create_link(struct kobject *kobj, struct kobject *target, char *name);

This function creates a link named name in the directory mapped from kobj to the directory mapped from target. This function returns zero on success and a negative error code otherwise.

Destroying New Attributes

Removing an attribute is handled via sysfs_remove_file():
void sysfs_remove_file(struct kobject *kobj, const struct attribute *attr);

Upon call return, the given attribute will no longer appear in the given kobject's directory. Symbolic links created with sysfs_create_link() may be removed with sysfs_remove_link():
void sysfs_remove_link(struct kobject *kobj, char *name);

Upon return, the symbolic link name in the directory mapped from kobj is removed. All four of these functions are declared in <linux/kobject.h>. The sysfs_create_file() and sysfs_remove_file() functions are defined in fs/sysfs/file.c. The sysfs_create_link() and sysfs_remove_link() functions are defined in fs/sysfs/symlink.c.

sysfs Conventions
The sysfs filesystem is currently the place for implementing functionality previously reserved for ioctl() calls on device nodes or the procfs filesystem. These days, the chic thing to do is implement such functionality as sysfs attributes in the appropriate directory. For example, instead of a new ioctl() on a device node, add a sysfs attribute in the driver's sysfs directory. Such an approach avoids the type-unsafe use of obscure ioctl() arguments and the haphazard mess of /proc. To keep sysfs clean and intuitive, however, developers must follow certain conventions. First, sysfs attributes should export one value per file. Values should be text-based and map to simple C types. The goal is to avoid the highly structured or highly messy

representation of data we have today in /proc. Providing one value per file makes reading and writing trivial from the command line and enables C programs to easily slurp the kernel's data from sysfs into their own variables. In situations where the onevalue-per-file rule results in an inefficient representation of data, it is acceptable to place multiple values of the same type in one file. Delineate them as appropriate; a simple space probably makes the most sense. Ultimately, think of sysfs attributes as mapping to individual kernel variables (as they usually do) and keep in mind ease of manipulation from user-space, particularly from the shell. Second, organize data in sysfs in a clean hierarchy. Correctly parent kobjects so that they map intuitively into the sysfs tree. Associate attributes with the correct kobject and keep in mind that the kobject hierarchy exists not only in the kernel but also as an exported tree to user-space. Keep the sysfs tree sane! Finally, keep in mind that sysfs provides a kernel-to-user service and is thus some sort of user-space ABI. User programs may come to rely on the existence, location, value, and behavior of sysfs directories and files. Changing existing files in any way is discouraged, and modifying the behavior of a given attribute but keeping its name and location is surely begging for trouble.
These simple conventions should allow sysfs to provide a rich and intuitive interface to userspace. Use sysfs correctly and user-space developers will not curse your existence but praise your beautiful code.