Linux RFS v1.3.0 Porting Guide May 20-2008, Version 1.
Copyright notice Copyrightⓒ 2008 Flash Software Group, Samsung Electronics, Co., Ltd.. All rights reserved. Trademarks RFS is trademark of Flash Software Group, Samsung Electronics Co., Ltd.. in Korea and other countries Restrictions on Use and Transfer All software and documents of RFS are commercial software. Therefore, you must install, use, redistribute, modify and purchase only in accordance with the terms of the license agreement you entered into with Flash Software Group, Samsung Electronics Co.
Preface SEC-FSG-RFS1.2-POG This document is a porting guide of RFS developed by Flash Software Group, Memory Division, Samsung Electronics. It describes Linux RFS porting procedure to user's target platform. Purpose This document is RFS Porting Guide. This document explains the definition, architecture, system requirement, and porting tutorial of RFS. This document also provides the features and API of each module that a user should know well to port RFS.
Related Documents - RFS v1.3.0 Programmer’s Guide, Samsung Electronics, Co., Ltd. - LinuStoreII Utility Guide, Samsung Electronics Co., Ltd. - LinuStoreII Porting Guide, Samsung Electronics Co., Ltd. History Version 0.1 0.8 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 III Date 2006.01.05 2006.01.13 2006.02.13 2006.03.16 2006.03.23 2006.04.19 2006.05.10 2006.09.27 2006-09-29 2006.12.26 2007.03.19 2008-05-20 Comment Initial 1st draft Release Release Release RFS1.2.
Table of Contents 1 Introduction .........................................................................................1 1.1 Overview ........................................................................................1 1.2 Features .........................................................................................1 1.3 Architecture ....................................................................................1 2 Prerequisites .............................................................
Tables Table 1 Host System Requirements ......................................................................... 4 Table 2 RFS Static Memory Usage (in bytes) .............................................................. 6 Table 3 Hardware information of OMAP2420.............................................................. 6 V Linux RFS v1.3.
Figures Figure 1-1 Linux RFS Architecture .......................................................................... 2 Figure 2-1 Directory Structure of Linux RFS Package .................................................... 4 Figure 2-2 Linux RFS Source Files (Annotated on the Source Tree) ................................... 5 Figure 3-1 Linux RFS Porting Procedure.................................................................... 7 Figure 3-2 Main screen of Kernel menu ....................................
1 Introduction This chapter describes the overview and system architecture of RFS. It also covers the information about low-level flash memory partitions. 1.1 Overview Linux RFS (Linux Robust FAT File System) is a FAT compatible file system to use OneNAND/NAND flash memory as storage on any consumer electronic devices. As its name implies, Linux RFS runs in the Linux kernel and is fully compatible with FAT file system standards (FAT16/32).
Figure 1-1 Linux RFS Architecture File Systems Linux file system for flash devices is managed by two file systems: CRAMFS and RFS. Both of these file systems run under Linux VFS (Virtual File System). • CRAMFS: This is a read-only file system included in a standard Linux kernel distribution. CRAMFS is used to manage the read-only part of Linux file system directories, i.e. execution code, libraries, and ROM data files.
4. Writing the sector data to the modified page These sequences of operations are not atomic, so a write request to this block device driver is prone to data corruption. For this reason, read-only file systems such as CRAMFS are adequate to run on top of this block device driver. • STL Block Device Driver: This block device driver is used to provide driver functions for the device files /dev/stl0/*, /dev/stl1/* and so on.
2 Prerequisites This chapter explains the host/target system environment for porting RFS to your target system. Host is Linux PC environment and target can be any kind of consumer device using OneNAND flash memory. 2.1 Host Environment The following table shows the host system requirements for configuring and building RFS 1.2 Table 1 Host System Requirements Host Machine Host OS IDE & Compiler Free Space PC Linux Native GCC compiler & Cross-Compiler About 50MB 2.2 Software Environment 2.2.
fs – RFS file system module drivers - XSR block device driver module tools - Utilities to manipulate RFS scripts- RFS Package Installation scripts Include – includes header files 2.2.2 Source Files List This section gives short description of source files listed in the ‘rfs’ and ‘xsr’ directory. The source files in this package are listed in Figure 2-2, where *.c files and *.h files are annotated on the ‘RFS’ source tree.
Most of the sources are platform-independent codes except PAM. Please refer the “XSR Porting Guide” for more detailed information. Before going into detail about RFS customization according to target requirement, next section will explain about objects that Linux RFS will create during make (or build) steps. 2.2.3 RFS Memory Usage Table 2 lists the RFS static memory usage.
3 Porting Linux RFS This chapter describes porting overview, hardware configuration for OneNAND, Linux RFS initialization and porting procedure with OMAP2420 target board. 3.1 Porting Overview This section describes Linux RFS porting procedure briefly. The procedure is divided into 5 steps as shown in the following figure.
If you are using Linux kernel 2.4.xx specify ‘kernel type’ as 24. If you are using Linux kernel 2.6.xx specify ‘kernel type’ as 26. Shell> cd $(TOP_DIR) Shell> $(RFS_TOP_DIR)/scripts/rfs_install.sh 24 3.2.2 Kernel Configuration for RFS 3.2.2.1 Menu Configuration of Kernel for RFS As shown below, you should get sub-menu in $(KERNEL_TOP_DIR) as the result of ‘make menuconfig’. Figure 3-2 shows the general main menu of kernel configuration. Select “File systems” menu to go on to the next step.
Figure 3-3 File system screen of Kernel menu Figure 3-3 shows the detailed RFS configuration. 1. The first is FAT32 and long file name support 2. The second is direct I/O support. But, this feature is experimental and should not be used in production environment. 3. The third is debugging message option ☞ NOTE You have to execute the ‘mkrfsnod’ utility on the target for making device nodes used by XSR block device driver. The detailed usage of this program is described in Ftools Utility Guide document. 3.
Figure 3-4 Code maturity level You should set the make option for “COMPRESSED ROM FILE SYSTEM (CRAMFS)” in file system option during make menuconfig because the root file system is managed by CRAMFS. 10 Linux RFS v1.3.
Figure 3-5 CRMAFS OPTION Settings Now, you can proceed to build the kernel and the kernel modules. Before starting build process your kernel cross compile path ‘CROSS_COMPILE = ’ must be set in $(KERNEL_TOP_DIR)/Makefile. To build the kernel, type the following commands in sequence. shell> shell> shell> shell> cd $(KERNEL_TOP_DIR) make clean make dep make uImage Then, the kernel image file named ‘uImage’ will be created if no error occurs.
After all of these steps, you will have the kernel image ‘uImage’. For usage of OneNAND device on your target, please refer to ftools utility guide. 3.3 Using the NLS (Native Language Support) The FAT Filesystem can deal with filenames in native language character sets. These character sets are stored in so-called DOS codepages. You need to include the appropriate codepage if you want to be able to read/write these file names on DOS/Windows or other FAT partitions correctly.
Figure 3-7 NLS(Native Language Support) configuration And you should select the codepages like the default codepage and other codepages to be used at the target. Then, the codepages will be compiled as built-in or module. For example, if you set the default codepage to “cp949” for Korean, you have to select “Codepage 949” at this menu. ☞ NOTE If you installed the RFS code by using ‘rfs_install.
Figure 3-8 RFS Filesystem configuration for FAT16 If you decide to build RFS Filesystem as FAT16 type, you always make the filenames with the native language in the 8.3 format regardless of NLS support. Why is this possible? The NLS is used for the conversion the filenames with the native language to/from Unicode, but the conversion doesn’t happen at the FAT16. So, FAT16 doesn’t need any codepage. ☞ NOTE If you make filenames with the native language at FAT16 and the length of the name is longer than the 8.
If you didn’t select the ‘FAT32 & long file name’ when you built the kernel image, this command will success and RFS is able to support filenames with the native language in the 8.3 format. If you selected the NLS support and the default codepage, this command will success if only the default codepage is configured and built. For example, if the default codepage is “codepage 437”, then RFS supports filenames with the native language of ‘cp437’ character set.
Appendix I. Description of FAT Configuration Option z CONFIG_RFS_FS Description Configuration option for RFS Behavioral description This option should be set for RFS support. Additional notice None z CONFIG_RFS_VFAT Description To avoid the patent problems related to Window FAT file system, RFS can be built without codes related to Windows FAT file system. Behavioral description This option can be turned off by turning on the option, “FAT32 & long file name support” in the configuration menu.
This option has the name of the default codepage. Behavioral description This option is valid if only the CONFIG_RFS_NLS is turned on. When the mount option ‘codepage’ of the RFS Filesystem is not set, this value can be used for mounting and for the conversion of the filename with this character set. Additional notice None z CONFIG_RFS_FAT_DEBUG Description This option prints low-level debugging message for the RFS file system.
This option enables RFS to use a iget4() interface instead of a iget_locked() interface. If your kernel supports a iget_locked() interface, you can disable it. Additional notice For MontaVista Linux Pro 3.1, you should disable this option. For CEE 3.1, this option should be enabled. Default is enable. z CONFIG_RFS_VERSION Description This option is used for RFS version string Behavioral description None Additional notice z CONFIG_RFS_PRE_ALLOC Description This option is used for advanced cluster allocation.
