Construction and Improvement of YAFFS File System in Embedded Linux System (1)

In the development of embedded Linux, the commonly used storage devices are NorFlash and NandFlash, and NandFlash, which is inexpensive and suitable for high-density and large-capacity storage, is more widely used [1]. YAFFS (Yet Another Flash File System) file system is specially designed for the special structure of NandFlash. It is a file system with log structure and its performance surpasses the original JFFS series file system. However, with the development of embedded technology, when constructing YAFFS in embedded Linux on NandFlash media, YAFFS has the disadvantages of too long mounting time and insufficient loss balance, which needs further improvement and optimization.

1 YAFFS file system

In the NandFlash used for embedded, the basic unit of reading and writing is the page, and the storage location of YAFFS is also the page (generally called Chunk), which is divided into an additional area (OOB) and a data area. The 32-page block is the basic erase unit [2]. A mapping table of files and physical pages is established because the file offset address of YAFFS is inconsistent with the physical address of the flash memory. The page number of the flash memory is used as the table content, and the file offset described by each page is used as the table index. Then the large mapping table is divided into several small tables and organized into a tree structure to improve the search speed of the file data block. This hierarchical index directory built in memory is called the node tree (TnodeTree), which is the core model of YAFFS, as shown in Figure 1. The physical chunk index is found in the node tree according to the logical chunk index. As the file gets larger, the required leaf nodes will also increase, and the node tree will "pull up" and "fat". When the file is deleted, it recursively shrinks from the leaf node to release the physical page corresponding to the deleted node.

2 Building the YAFFS file system

2.1 Experimental platform

The cross-compilation mode of the target board and the host machine is used in the development process. The host computer is a virtual machine + Linux RedHat9.0 system; the hardware of the target board is ARM board, which is an S9C2440 ARM9 microprocessor with a 256 MB NandFlash and 64 MB SDRAM memory. . The development software used by the target board is embedded Linux2.6.28+ cross-compilation tool arm-Linux-gcc4.3.1. The development process of the YAFFS file system is shown in Figure 2. The boot program Boot-Loader is generally fixed in the open Flash (not explained here).

2.2 kernel porting

(1) Modify the cross-compilation environment to make it suitable for this experimental platform. Modify the ARM compiler defined in the top-level Makefile to correspond to the platform processor being used. Modify as follows:

ARCH = arm

CROSS_COMPILE = /usr/local/3.4.1/arm-linux-

At the same time, in order to support the experimental platform processor 12 MHz crystal frequency, modify the input clock provided by Linux, in the file arch / arm / mach -

S3c24xx_init_clocks is defined in s3c2440/mach-smdk2440.c

(12 000 000); and in this file, change the machine name supported by Linux to MACHINE_START (S3C2440, "Study-S3C2440"); finally, modify the default machine number in Linux to match the machine parameter 782 passed by BootLoarder. . In arch/arm/tools/math-types, the machine model statement is modified to:

S3C2440 ARCH_S3C2440 S3C2440 782

(2) The kernel supports MTD. MTD is the interface between flash memory and file system. The connection between NandFlash and YAFFS file system and MTD is shown in Figure 3.

[1] [2] [3]