Flash Storage Technology in uClinux

Abstract: This article introduces in detail the Flash storage technology under the embedded operating system uClinux platform, and provides a specific design example based on Flash memory under the Samsung system.

Keywords: Flash memory; uClinux; cloud4510

Abstract: This document. nbspparticipant ularly introduces how to use Flash memory on the embedded OS-uClinux. And it gives the design example of Flash memory based on the initi4510

Key words: Flash memory; uClinux; cloud4510

Flash Storage Technology
In the past two decades, ROM and EPROM have been the first choice for storage devices of embedded systems. However, more and more embedded system designers are designing and developing Flash storage devices that can read and write.

Flash is mainly divided into two types: NOR and NAND. NOR and NAND are two major non-loss flash technologies on the market. Intel first developed NOR Flash technology in 1988, which completely changed the previous situation where EPROM and EEPROM were integrated. Next, in 1989, Toshiba published the NAND Flash structure, emphasizing reducing the cost per bit and higher performance, and easily upgrading it through interfaces like disks.

NOR features In-chip execution (XIP, eXecute In Place), so that applications can run directly In Flash memory without having to read the code into system RAM. NOR transmission efficiency is very high, in 1 ~ The small size of 4 MB has high cost efficiency, but the low write and erase speeds greatly affect its performance.

The NAND structure provides a very high unit density, achieves a high storage density, and writes and erases quickly. However, the difficulty in using NAND lies in that Flash management requires special system interfaces.

However, after more than a decade, a considerable number of hardware engineers are still confused about NOR and NAND Flash. Because in most cases, flash memory is only used to store a small amount of code, NOR flash memory is more suitable for some. Flash memory is often used with NOR memory. However, NAND is an ideal solution for high data storage density.

The following is a detailed comparison of the two:

Performance Comparison

Flash memory is a non-loss-prone memory. It can be used to erase and re-program memory unit blocks called blocks. Write operations on any Flash device can only be performed in an empty or erased unit. In most cases, the Flash device must be erased before writing. It is very easy for the NAND device to perform the erasure operation, and NOR requires that all the bits in the target block be written to 0 before the erasure.

Since the NOR device is erased with 64 ~ For blocks of KB, the time for performing a write/erase operation is 5 s. In contrast, the erased NAND device is 8 ~ For 32 KB blocks, it takes up to 4 ms to perform the same operation.

When the block size is erased, the performance gap between NOR and NADN is further extended. Statistics show that for a given set of write operations (especially when updating small files ), more erasure operations must be performed in the NOR-based unit. In this way, when selecting a storage solution, the designer must weigh the following factors.

● NOR reads faster than NAND.

● NAND writes much faster than NOR.

● NAND's 4 Ms erasure speed is far faster than NOR's 5s.

● Most write operations require erasure first.

● NAND has fewer erased units and fewer erased circuits.

Interface differences

NOR Flash has an SRAM interface and enough address pins to address it, so it can easily access its internal

Each byte.

NAND devices use complex I/O ports to access data in a serial manner. Different products or vendors may use different methods. Eight pins are used to transmit control, address, and data information.

NAND read and write operations use 512 bytes of blocks, which is a bit like hard disk management. Naturally, NAND-based memory can replace hard disks or other Block devices.

Capacity and cost

The unit size of NAND Flash is almost half the size of the NOR device. Because the production process is simpler, the NAND structure can provide a higher capacity within the given mold size, thus reducing the price accordingly.

NOR Flash occupies 1 ~ Most of the 16 MB Flash memory market, while NAND Flash is only used in 8 ~ Among the MB products, this also shows that NOR is mainly used in code storage media. NAND is suitable for data storage. NAND shares the largest share in the CompactFlash, Secure Digital, PC Cards, and MMC memory Cards markets.

Availability and Durability

When Using Flash Media, a major concern should be the feasibility. Flash is a suitable storage solution for systems that need to expand MTBF. We can compare the availability of NOR and NAND in terms of life (durability), bit switching, and bad block processing.

Life (durability)

In nand flash memory, the maximum number of writes to each block is 1 million, while that of NOR is 100,000. In addition to having a block erasure cycle of 10 to 1, the typical NAND block size is eight times smaller than that of the NOR device, each NAND memory block is deleted less frequently within a given period of time.

Bit Switching

All Flash devices are plagued by bit switching. In some cases (rarely, NAND occurs more often than NOR), a bit is reversed or reported to be reversed.

One-bit changes may not be obvious, but if it occurs on a critical file, this small fault may cause system downtime. If there is only a report problem, it may be solved by reading multiple times.

Of course, if this bit changes, you must use the error detection/error correction (EDC/ECC) algorithm. The problem of bit inversion is more common in nand flash memory. The NAND supplier recommends using the EDC/ECC algorithm when using nand flash memory. This problem is not fatal when using NAND to store multimedia information. Of course, if you use a local storage device to store operating systems, configuration files, or other sensitive information, you must use the EDC/ECC system to ensure availability.

Bad Block Processing

Bad blocks in NAND devices are randomly distributed. I have tried to eliminate bad blocks before, but I found that the yield rate is too low, the cost is too high, and it is not cost-effective at all. The NAND device needs to initialize the media to detect Bad blocks and mark them as unavailable. In an existing device, if you cannot perform this operation using the * method, the failure rate will be high.

Ease of use

The nor-based flash memory can be used very directly, and can be connected like other memory, and code can be directly run on it.

Due to the need for I/O interfaces, Nand is much more complicated. The access methods for various NAND devices vary from manufacturer to manufacturer. When using the NAND device, you must first write the driver to continue other operations. Writing information to a NAND device requires considerable skill, because designers must not write information to Bad blocks, which means virtual ing must be performed from beginning to end on the NAND device.

Software Support

When discussing software support, we should distinguish basic read/write/erase operations from high-level software for disk simulation and flash management algorithms, including performance optimization.

Running code on the nor device does not require any software support. When performing the same operation on the NAND device, the driver is usually needed, that is, the memory technology driver (MTD ), the NAND and nor devices require MTD for write and erase operations.

Fewer MTDS are required when using nor devices. Many vendors provide more advanced software for nor devices, including the trueffs driver of M-system, this driver is used by Wind River system, Microsoft, QNX software system, Symbian, Intel, and other vendors. The driver is also used to simulate diskonchip products and manage nand flash memory, including error correction, Bad Block Processing, and loss balancing.

At present, the world's nor flash manufacturers mainly include Intel, AMD, Fujitsu and Toshiba. The nor flash storage chip capacity ranges from several K to 64 m, nor flash, a standard storage device, may replace Rom in the next few years. NAND Flash Manufacturers include Samsung and toshba, and they are also flash vendors on the "diskonchip" of M-system. The capacity of the NAND flash storage chip ranges from 8 MB to 128 MB, while that of the diskonchip can reach MB.

Nor flash is widely used in the design of small embedded systems, especially uClinux systems. So the introduction below will focus more on nor flash.

System Design
In general, in embedded system design, the choice of Ram and flash is weighed by the designer, and the price is often the main deciding factor. Flash is more expensive than RAM in terms of storage overhead per M bytes. For uClinux systems, the choice of flash as memory has certain advantages, after the uClinux system is powered on, the program code and data to be run can be stored in flash, or even the startup kernel of uClinux in the starting CPU address can be written into flash. Therefore, in a certain sense, embedded systems only use flash to complete the required storage functions.

The flash memory partition is simpler than the hard disk partition, and the flash after partitioning is more convenient to use. Typical flash partitions are as follows:

Segment Purpose

0 bootloader

1 foctory Configuration

2

. Kernel

X

. Root filesystem

Y

Partition 0 places Bootloader, partition 1 places factory configuration, partition 2 to partition X places the system kernel, partition X to partition Y places the root file system. Flash partitions can be divided as needed. The block device drivers supporting Flash memory in uClinx define the partitions above.

Unlike Linux on a PC, Flash partitions separate the kernel files and root file systems of the system into two partitions, the hard disk of a PC stores the Kernel File and root file in a partition. Linux Bootloader in a PC is LILO or GRUB, which intelligently finds the Kernel File block in the partition during system startup and loads it into RAM for running. For Flash, writing the kernel image file into a separate partition has two advantages for the embedded system: 1) the system can run directly on Flash 2) for LILO or GRUB, it is easier to find the kernel code to load, or even run it directly without being instructed by LILO or GRUB.

The placement of kernel files and root file systems in Flash can be selected according to the system design requirements. The following table lists the options.

Mode Selection
Optimization
Missing points

Kernel and root files are placed in fixed offset address units (separate partitions)
It is suitable for loading and upgrading the kernel and the root file system with fixed IP address units and easy boot loader.
Flash space is inevitably wasted between the kernel and the root file system.

Place the root file system closely with the kernel (not separately partitioned)
Saving Flash storage space
The kernel file and the root file are combined into one, which is not convenient to upgrade separately.

Kernel and root file system compression and placement
Saves a lot of Flash storage space. You can choose to compress and store the kernel or root file system.
The system requires Bootloader and RAM support.

Table 1

Bootloader Selection)
The boot process before the system starts is the CPU initialization process. Many CPUs, including ARM and X86, run boot programs from fixed address units. Other CPUs read the entry address of the boot program from an address unit, and then run the boot program, such as the M68K and COLDFIRE series. These affect the storage address of the system startup code in Flash.

First, the system should consider the address at which the system stores the Bootloader, or the address unit from which the system starts to load and run the system kernel code.

You can directly run the system kernel after the CPU is started. For uClinux, the startup code must include hardware configurations such as chip initialization and RAM initialization, load the kernel code segment to RAM, and clear the initialized data segment content. Although these implementations are intuitive, it is difficult to store the startup code in the correct address Offset Unit in Flash so that the CPU can be executed at startup. However, the CPU with advanced technology now sets the default offset address to 0 or stores the starting address near the offset address to 0.

Bootloader uses a separate piece of code to initialize the basic hardware and load and run the kernel code of uClinux. As a system startup tool, Bootloader can load multiple kernels in Flash after configuration, or even load the kernel and system images to run in RAM through the serial port and network port. Bootloader also provides multi-level protection for Kernel image files, which is especially important for systems that use Flash as storage devices. For example, when the system performs kernel upgrade and important data backup, the system suddenly loses power, just like the power loss during the BIOS flushing process on the PC, which is catastrophic. However, Bootloader can be used to achieve protective recovery.

Currently, the free Bootloader running on uClinux includes COLILO, MRB, PPCBOOT, and DBUG. Snap gear and arcturus networks are also designed for special needs.

Block Driver for uClinux)
For Block devices of embedded systems, there are three main options: block drives for storing file systems.

1) Blkmem driver. Blkmem driver is still the most popular Flash driver in uClinux. It is designed for uClinux, but its structure is relatively simple and only supports NOR Flash operations, you must create a root file system in RAM. It is also difficult to configure. You need to modify the code table to create a Flash partition. Despite this, it provides the most basic partition wipe/write operations.

2) MTD driver. MTD driver is a standard Flash drive in Linux. It supports most Flash storage devices and has powerful partition definition and image tools. Using the interleaving technology, MTD driver can even support different types of Flash in the same system. The MTD driver configuration in Linux kernel has more detailed options.

3) RAM disk driver. The most real RAM disk driver is used in standard Linux with no disk boot, but it does not support the underlying Flash memory and only makes sense for the establishment of the root file system, that is, where the compressed root file system is stored in Flash after compression.

Through the comparison above, we can see that MTD driver provides the most powerful support for Flash, and also supports running file systems directly from Flash, such as JFFS and JFFS2, the Blkmem driver is not supported.

Root Filesystem)
The file system in uClinux can have many options. In general, ROMfs is the most widely used file system, which is a simple, compact, and read-only file system. ROMfs stores file data in sequence and can directly run the file system on uClinux-supported storage devices. This saves a lot of RAM space during system running.

Cramfs is a new file system designed for Versions later than Llinux kernel 2.4. It is also compressed and read-only. It stores the file data in a compressed format and decompress it when necessary. Because it stores files in a compressed format, the file system cannot run on Flash directly. Although this saves a lot of Flash storage space, the file system needs to copy a large amount of data into RAM, consuming RAM space.

Considering that most systems need to read/write file systems, you can use MTD driver's log file formats such as JFFS and JFFS2 to create a root file system in the Flash header. A log file system can be protected from sudden power loss and does not require a file system check during the next system boot. Because JFFS and JFFS2 file formats are especially designed for Flash memory, both of them have a feature called "loss balancing, that is to say, all the erased units of Flash keep the same number of writes. Using this unique protection measure, the use cycle of Flash has been greatly improved. JFFS2 uses the compressed file format, saving a lot of storage space for Flash, which is better than JFFS format in the system. It is worth noting that using JFFS2 may cause a small amount of Flash space waste, mainly because of the overhead of log files and useless storage units used to recycle the system, the space wasted is roughly two data segments.

If RAM disk is used, select the EXT2 file format. However, EXT2 is not a particularly efficient file storage space. Because it exists on the RAM disk, any changes will be lost after the next startup. Of course, many people think that this is an advantage for embedded storage space, because every system startup starts from the state of a known file system.

Although many file formats are available in Linux, only the preceding file formats are available in uClinux. Another point is how to create a root file system on the target system. The procedure is as follows:

First, create a directory tree of the root file system of the target machine on the Development host machine, and then use the embedded root file system generation tool to generate a binary file image of the directory tree on the host machine, finally, download it to the target machine. There are different binary image generation tools for different file formats, such as mkfs. jffs2 of JFFS and mkisofs of ISO9660.

Flash tools and Instances
There are many types of Flash operators in uClinux, which are designed and used for underlying Block devices.

When MTD driver is used, the main tools include erase (Data Segment erasure tool), eraseall (erased Flash), lock (write protection), unlock (Enable write Protection), and mkfs. jffs and mkfs. jffs2 (JFFS2 format generation tool ). Because MTD driver supports characters and Block devices, you can use dd commands on the target machine to write Flash.

Actual Design Example:

System hardware configuration: MB Flash, 4 mb sdram. Kernel: uClinux2.4.x, supporting Flash storage using MTD driver. Select ROMfs as the file system format. There are a series of Erasable address spaces at the bottom of the Flash memory address. Their sizes are 16 K, 8 K, 8 K, and 32 K, respectively. The total size is 64 K, we chose Flash's "bottom boot ".

The Flash hardware design principle is shown in figure

Figure 1

The Flash partition is as follows:

● Segment size MTD-DEVICE description
0 16 K mtd0 Boot Loader

1 8 K mtd1 kernel boot parameters

2 8 K mtd2 factory settings

3 32 K mtd3 idle

4 64 K mtd4 curing settings

5

. 1984 K mtd5 kernel + root file system.

35

0-35 2048 K mtd6 all of flash memory

During flash partitioning, try to use the top and bottom of flash. Different MTD partitions can partially overlap, but pay special attention to them during operations.

The system kernel is compressed for storage, and bootloader unzips the kernel to run in the SDRAM after initializing the SDRAM. The root file system is stored after the compressed kernel image file. It can run directly on flash. After the kernel compression image is removed, the size of a typical root file system is about MB.

One of the biggest advantages of combining the kernel file and the root file system in an image file is that when the two need to be upgraded, you only need to re-compile the configuration file on MTD4.

In all configurations, the key is the establishment of MTD driver ing, uClinux-2.4.x/drivers/mtd/maps under the nettle-uc.c is the source program established by the file system, it mainly explains the content of partition ing and how to configure the root file system on MTD4.

The pilot log can be used to analyze the pilot process. For example, the pilot process log is as follows:

SnapGear Flash probe (0xf0000000, 2097152,2): 200000 at f0000000

CFI: Found no Flash device at location zero

Found: toshba TC58FVB160

Number of JEDEC chips: 1

Creating 7 MTD partitions on "Flash ":

0x00000000-0x00004000: "Bootloader"

0x00004000-0x00006000: "Bootargs"

0x00006000-0x00008000: "MAC"

0x0000000-0x00020000: "Config"

0x00008000-0x00010000: "Spare"

0x00020000-0x00200000: "Image"

0x00000000-0x00200000: "Flash"

As shown in the preceding log, MTD drivers finds Toshiba Flash and divides it into several specified partitions according to previous requirements. Flash is mapped to 0xf0000000 of the CPU address unit. Of course, MTD driver provides more complex configuration settings. By configuring MTD drivers in the Kernel configuration, you can get a more detailed log report on the Flash device.

Use netFlash to refresh the system kernel and file system. The command line is only: netFlash imagez. bin: place the image file on the Tftp server. netFlash downloads the image file from the Tftp server at the specified address and completes the installation. Restart the target board to run uClinux.