一、FHS(Filesystem Hierarchy Standard)标准介绍
当我们在linux下输入ls / 的时候,见到的目录结构以及这些目录下的内容都大同小异,这是因为所有的linux发行版在对根文件系统布局上都遵循FHS标准的建议规定。
该标准规定了根目录下各个子目录的名称及其存放的内容:
目录名 | 存放的内容 |
/bin | 必备的用户命令,例如ls、cp等 |
/sbin | 必备的系统管理员命令,例如ifconfig、reboot等 |
/dev | 设备文件,例如mtdblock0、tty1等 |
/etc | 系统配置文件,包括启动文件,例如inittab等 |
/lib | 必要的链接库,例如C链接库、内核模块 |
/home | 普通用户主目录 |
/root | root用户主目录 |
/usr/bin | 非必备的用户程序,例如find、du等 |
/usr/sbin | 非必备的管理员程序,例如chroot、inetd等 |
/usr/lib | 库文件 |
/var | 守护程序和工具程序所存放的可变,例如日志文件 |
/proc | 用来提供内核与进程信息的虚拟文件系统,由内核自动生成目录下的内容 |
/sys | 用来提供内核与设备信息的虚拟文件系统,由内核自动生成目录下的内容 |
/mnt | 文件系统挂接点,用于临时安装文件系统 |
/tmp | 临时性的文件,重启后将自动清除 |
制作根文件系统就是要建立以上的目录,并在其中建立完整目录内容。其过程大体包括:
下面就来详细介绍这个过程。
二、编译/安装busybox,生成/bin、/sbin、/usr/bin、/usr/sbin目录
这些目录下存储的主要是常用命令的二进制文件。如果要自己编写这几百个常用命令的源程序,my god, 这简直是一个噩梦!好在我们有嵌入式Linux系统的瑞士军刀——busybox,事情就简单很多。
1、从http://www.busybox.net/ 下载busybox-1.7.0.tar.bz2
2、tar xjvf busybox-1.7.0.tar.bz2解包
3、修改Makefile文件
175 ARCH ?= arm
176 CROSS_COMPILE ?= arm-linux-
4、make menuconfig配置busybox
busybox配置主要分两部分。
第一部分是Busybox Settings,主要编译和安装busybox的一些选项。这里主要需要配置:
1)、Build Options -- Build BusyBox as a static binary (no shared libs),表示编译busybox时,是否静态链接C库。我们选择动态链接C库。
2)、Installation Options -- Applets links (as soft-links) -- (X) as soft-links,表示安装busybox时,将各个命令安装为指向busybox的软链接还是硬链接。我们选择软链接。
3)、Installation Options -- (/work/nfs_root/fs_mini3) BusyBox installation prefix,表示busybox的安装位置。我们选择/work/nfs_root/fs_mini3
4)Busybox Library Tuning。保留Command line editing以支持命令行编辑;保留History size以支持记忆历史命令;选中Tab completion和Username completion以支持命令自动补全
第二部分是Applets,他将busybox的支持的几百个命令分门别类。我们只要在各个门类下选择想要的命令即可。这里我们基本保持默认设置。
1)选中Networking Utilities -- httpd下的Enable -u <user> option,以启用http服务器的功能allows the server to run as a specific user
5、编译busybox
make
6、安装busybox
make install
make中常遇到的问题及解决办法:
进入目录后添加编译环境:vi Makefile
175-177行:
ARCH = arm
CROSS_COMPILE = /usr/arm/3.4.1/bin/arm-linux-
然后开始配置:make menuconfig
错误i :
applets/applets.c:20:2: warning: #warning Static linking against glibc produces buggy executables
applets/applets.c:21:2: warning: #warning (glibc does not cope well with ld --gc-sections).
applets/applets.c:22:2: warning: #warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400
applets/applets.c:23:2: warning: #warning Note that glibc is unsuitable for static linking anyway.
applets/applets.c:24:2: warning: #warning If you still want to do it, remove -Wl,--gc-sections
applets/applets.c:25:2: warning: #warning from top-level Makefile and remove this warning.
applets/applets.c:26:2: #error Aborting compilation.
make[1]: *** [applets/applets.o] 错误 1
make: *** [applets] 错误 2
解决办法:
$cd applets
$vi applets.c
注释掉警告部分:19-31行:
/*
#if ENABLE_STATIC && defined(__GLIBC__) && !defined(__UCLIBC__)
#warning Static linking against glibc produces buggy executables
#warning (glibc does not cope well with ld --gc-sections).
#warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400
#warning Note that glibc is unsuitable for static linking anyway.
#warning If you still want to do it, remove -Wl,--gc-sections
#warning from top-level Makefile and remove this warning.
#error Aborting compilation.
#endif
*/
错误II:
[miscutils/taskset.o] 错误 1
make: *** [miscutils] 错误 2
解决办法:
make menuconfig 中:在 Miscellaneous Utilities ---> [ ] taskset 将其前的星号去掉即可
错误III:
modutils/lib.a(insmod.o): In function `insmod_main':
insmod.c:(.text.insmod_main+0xbc8): warning: warning: create_module is not implemented and will always fail
insmod.c:(.text.insmod_main+0x3f0): warning: warning: query_module is not implemented and will always fail
miscutils/lib.a(inotifyd.o): In function `inotifyd_main':
inotifyd.c:(.text.inotifyd_main+0x30): undefined reference to `inotify_init'
inotifyd.c:(.text.inotifyd_main+0xac): undefined reference to `inotify_add_watch'
collect2: ld returned 1 exit status
make: *** [busybox_unstripped] 错误 1
解决办法:
make menuconfig中:在Linux Module Utilities 中把Support version 2.2.x to 2.4.x Linux kernels去掉。
Coreutils >
[*] cp
[*] cat
[*] ls ls里关于颜色的一定不能选,不然在DNW里打开了是乱码
[*] mkdir
[*] echo (basic SuSv3 version taking no options)
[*] env
[*] mv
[*] pwd
[*] rm
[*] touch
如此之后:make install会在目录下出现_install 。表示编译成功。。
安装完成后,可以看到在/work/nfs_root/fs_mini3目录下生成了binsbinusr/binusr/sbin目录,其下包含了我们常用的命令,这些命令都是指向bin/busybox的软链接,而busybox本身的大小不到800K:
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ ls
bin linuxrc sbin usr
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ ls -l bin
total 740
lrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 addgroup -> busybox
lrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 adduser -> busybox
lrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 ash -> busybox
-rwxr-xr-x 1 dennis dennis 749632 2010-04-03 23:57 busybox
lrwxrwxrwx 1 dennis dennis 7 2010-04-03 23:57 cat –> busybox
而普通PC机上的ls命令就有差不多80K的大小:
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ ls -l /bin/ls
-rwxr-xr-x 1 root root 78004 2007-09-29 20:51 /bin/ls
busybox以它娇小的身躯容纳了数以百计的命令代码,实在是让人佩服不已,其不愧嵌入式系统瑞士军刀之美誉。据说,busybox的作者身患绝症,这更让人钦佩GNU开源软件的作者们。
三、利用交叉编译工具链,构建/lib目录
光有应用程序(命令)是不够的,因为应用程序本身需要使用C库的库函数,因此还必需制作for ARM的C库,并将其放置于/lib目录。my god,要自己写C库的源代码吗?不用!还记得交叉编译工具链的3个组成部分吗?交叉编译器、for ARM的C库和二进制工具。哈哈,for ARM的C库是现成的,我们只需要拷贝过来就可以了。遗憾的是:整个C库目录下的文件总大小有26M。而我们根文件系统所在分区不过区区16M而已,根本 放不下。怎么办呢?
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ du -s --si /work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib
26M /work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib
需要C库目录下所有的文件吗?no,absolutely no! 让我们来分析一下glibc库目录下内容的组成。该目录下的子目录和文件共分8类:
很显然,第1、2、3、4、7类文件和目录是不需要拷贝的。
由于动态链接的应用程序本身并不含有它所调用的C库函数的代码,因此执行时需要动态链接库加载器来为它加载相应的C库文件,所以第6类文件是需要拷贝的。
除此之外,第5类文件当然要拷贝。但第5类文件的大小也相当大。
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ du -c --si *.so*
7.2M total
需要全部拷贝吗?非也,非也!其实,需要哪些库完全取决于要运行的应用程序使用了哪些库函数。如果我们只制作最简单的系统,那么我们只需要运行busybox这一个应用程序即可。通过执行
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ arm-linux-readelf -a bin/busybox | grep 'Shared'
0x00000001 (NEEDED) Shared library: [libcrypt.so.1]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libc.so.6]
可知:busybox只用到了3个库:通用C库(libc)、数学库(libm)、加密库(libcrypt),因此我们只需要拷贝这3个库的库文件即可。但是每个库都有4个文件,4个文件都要拷贝吗?当然不是。
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libcrypt[.-]*
-rwxr-xr-x 1 dennis dennis 30700 2008-01-22 05:32 libcrypt-2.3.6.so
-rw-r--r-- 1 dennis dennis 23118 2008-01-22 05:32 libcrypt.a
lrwxrwxrwx 1 dennis dennis 13 2008-12-22 15:38 libcrypt.so -> libcrypt.so.1
lrwxrwxrwx 1 dennis dennis 17 2008-12-22 15:38 libcrypt.so.1 -> libcrypt-2.3.6.so
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libm[.-]*
-rwxr-xr-x 1 dennis dennis 779096 2008-01-22 05:31 libm-2.3.6.so
-rw-r--r-- 1 dennis dennis 1134282 2008-01-22 05:32 libm.a
lrwxrwxrwx 1 dennis dennis 9 2008-12-22 15:38 libm.so -> libm.so.6
lrwxrwxrwx 1 dennis dennis 13 2008-12-22 15:38 libm.so.6 -> libm-2.3.6.so
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ ls -l libc[.-]*
-rwxr-xr-x 1 dennis dennis 1435660 2008-01-22 05:48 libc-2.3.6.so
-rw-r--r-- 1 dennis dennis 2768280 2008-01-22 05:31 libc.a
-rw-r--r-- 1 dennis dennis 195 2008-01-22 05:34 libc.so
lrwxrwxrwx 1 dennis dennis 13 2008-12-22 15:38 libc.so.6 -> libc-2.3.6.so
4个文件中的.a文件是静态库文件,是不需要拷贝的。另外3个文件是:
关于共享库的2个符号链接的作用的特别说明:
当 我们使用gcc hello.c -o hello -lm编译程序时,gcc会根据-lm的指示,加头(lib)添尾(.so)得到libm.so,从而沿着与版本无关的符号链接(libm.so -> libm.so.6)找到libm.so.6并记录在案(hello的ELF头中),表示hello需要使用libm.so.6这个库文件所代表的数学库 中的库函数。而当hello被执行的时候,动态链接库加载器会从hello的ELF头中找到libm.so.6这个记录,然后沿着主修订版本的符号链接 (libm.so.6 -> libm-2.3.6.so)找到实际的共享链接库libm-2.3.6.so,从而将其与hello作动态链接。可见,与版本无关的符号链接是供编译器 使用的,主修订版本的符号链接是供动态链接库加载器使用的,而实际的共享链接库则是供应用程序使用的。
通过以上分析,我们只需要拷贝3个库(每个库各1个主修订版本的符号链接和1个实际的共享链接库)以及动态链接库加载器(1个符号链接和1个实体文件)。步骤如下:
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ mkdir /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libcrypt-* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l libcrypt.so.* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libm-* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l libm.so.* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp libc-* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l libc.so.* /work/nfs_root/fs_mini3/lib
dennis@dennis-desktop:/work/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib$ cp -l ld-* /work/nfs_root/fs_mini3/lib
附另外一种拷贝/lib目录的方法:
#进入链接库目录
cd /usr/local/arm/3.3.2/lib
#编写一个shell文件,用于copy实际的共享链接库;主修订版本的符合链接;动态连接器及其符号链接到目标板根目录下的lib(在这里是/root/)。
vi cp.sh
#内容如下:
for file in libc libcrypt libdl libm libpthread libresolv libutil
do
cp $file-*.so /root/build_rootfs/rootfs/lib
cp -d $file.so.[*0-9] /root/build_rootfs/rootfs/lib
done
cp -d ld*.so* /root/build_rootfs/rootfs/lib
#保存退出
#第一个cp命令会复制实际的共享库
#第二个cp命令会复制符合链接本身
#第三个cp命令会复制动态连接器及其符合链接
#执行刚编写的shell。
source cp.sh
#这样就把链接库复制过来了。
#接着我们还要缩小复制过来的链接库的体积,如下:
arm-linux-strip –s /root/build_rootfs/rootfs/lib/lib*
四、手工构建/etc目录
/etc 目录存放的是系统程序的主配置文件,因此需要哪些配置文件取决于要运行哪些系统程序。即使最小的系统也一定会运行1号用户进程init,所以我们至少要手 工编写init的主配置文件inittab。busybox的inittab文件的语法、语义与传统的SYSV的inittab有所不同。
inittab 文件中每个条目用来定义一个需要init启动的子进程,并确定它的启动方式,格式 为<id>:<runlevel>:<action>:<process>。例 如:ttySAC0::askfirst:-/bin/sh
我们制作最简单的/etc/inittab文件,其内容如下:
::sysinit:/etc/init.d/rcS
::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a –r
制作最简单的脚本程序文件/etc/init.d/rcS,其内容如下:
#!/bin/sh
ifconfig eth0 192.168.2.17
修改shell脚本文件/etc/init.d/rcS的权限,以使其可被执行:
# chmod a+x /etc/init.d/rcS
五、手工构建最简化的/dev目录
在linux机器上,执行ls /dev可看到几百个设备文件,我需要手工创建它们吗?maybe,我只需要手工创建几个设备文件!我怎么知道我应该创建哪几个设备文件呢?管它呢,先看看开发板上可爱的linux的反应再说。
启动Linux操作系统,显示:
VFS: Mounted root (nfs filesystem).
Freeing init memory: 112K
Warning: unable to open an initial console.
这说明,内核已经成功挂载根文件系统,但却未能成功启动第1个用户进程init。通过错误消息“unable to open an initial console”搜索内核源代码,找到init/main.c文件。
748 static int noinline init_post(void)
749 {
750 free_initmem();
751 unlock_kernel();
752 mark_rodata_ro();
753 system_state = SYSTEM_RUNNING;
754 numa_default_policy();
755
756 if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
757 printk(KERN_WARNING "Warning: unable to open an initial console.\n");
758
759 (void) sys_dup(0);
760 (void) sys_dup(0);
761
762 if (ramdisk_execute_command) {
763 run_init_process(ramdisk_execute_command);
764 printk(KERN_WARNING "Failed to execute %s\n",
765 ramdisk_execute_command);
766 }
767
768 /*
769 * We try each of these until one succeeds.
770 *
771 * The Bourne shell can be used instead of init if we are
772 * trying to recover a really broken machine.
773 */
774 if (execute_command) {
775 run_init_process(execute_command);
776 printk(KERN_WARNING "Failed to execute %s. Attempting "
777 "defaults...\n", execute_command);
778 }
779 run_init_process("/sbin/init");
780 run_init_process("/etc/init");
781 run_init_process("/bin/init");
782 run_init_process("/bin/sh");
783
784 panic("No init found. Try passing init= option to kernel.");
785 }
显然,内核错误是由175行不能打开/dev/console所致。通过查看已经安装好的linux机器的/dev/console设备文件,可知其是字符设备文件,主设备号为5,次设备号为1:
dennis@dennis-desktop:/work/nfs_root/fs_mini3/etc$ ls -l /dev/console
crw------- 1 root root 5, 1 2010-04-08 08:40 /dev/console
因此,我们使用下面的命令创建它:
dennis@dennis-desktop:/work/nfs_root/fs_mini3/dev$ sudo mknod console c 5 1
还需要创建其它设备文件吗?只有天知道!再看看linux的反应。
VFS: Mounted root (nfs filesystem).
Freeing init memory: 112K
init: can't open '/dev/null': No such file or directory
这次我们有经验了,如法炮制,创建/dev/null设备文件:
dennis@dennis-desktop:/work/nfs_root/fs_mini3/dev$ sudo mknod null c 1 3
再次重启开发板上的linux,显示
VFS: Mounted root (nfs filesystem).
Freeing init memory: 112K
init started: BusyBox v1.7.0 (2010-04-03 23:53:55 CST)
starting pid 229, tty '': '/etc/init.d/rcS'
Please press Enter to activate this console.
starting pid 231, tty '': '/bin/sh'
#
哈哈,我们成功了,终于可以K歌去了。
六、创建其它空目录
K完歌回来,继续战斗。
dennis@dennis-desktop:/work/nfs_root/fs_mini3$ mkdir home root proc sys tmp mnt var
再次重启动开发板上的linux。咦,似乎有些问题。
VFS: Mounted root (nfs filesystem).
Freeing init memory: 112K
init started: BusyBox v1.7.0 (2010-04-03 23:53:55 CST)
starting pid 229, tty '': '/etc/init.d/rcS'
Please press Enter to activate this console.
starting pid 231, tty '': '/bin/sh'
# ps
PID Uid VSZ Stat Command
#
ps竟然看不到任何进程的存在!让我想想。对了,ps的机制是通过查看/proc中的内容来获得进程信息的。那么,目前/proc里有哪些内容呢?
# ls /proc
#
竟然空空如野!这可如何是好?
七、配置系统自动生成/proc目录
其实/proc是用来提供内核与进程信息的虚拟文件系统,由内核自动生成目录下的内容。不过需要我们设置一下,将/etc/init.d/rcS修改为:
#!/bin/sh
ifconfig eth0 192.168.2.17
mount -t proc none /proc
对 于mount -t proc none /proc 的解释:通常情况下mount命令应该写为mount –t ext2 /dev/hdb1 /proc。但由于现在挂载的/proc是虚拟文件系统,它不与任何物理硬盘分区相对应,因此在表示物理硬盘分区的位置用占位符none来表示。
重启开发板上的linux,显示成功了:
Please press Enter to activate this console.
starting pid 232, tty '': '/bin/sh'
# ps
PID Uid VSZ Stat Command
1 0 3088 S init
2 0 SW< [kthreadd]
3 0 SWN [ksoftirqd/0]
4 0 SW< [events/0]
5 0 SW< [khelper]
41 0 SW< [kblockd/0]
42 0 SW< [ksuspend_usbd]
45 0 SW< [khubd]
47 0 SW< [kseriod]
59 0 SW [pdflush]
60 0 SW [pdflush]
61 0 SW< [kswapd0]
62 0 SW< [aio/0]
177 0 SW< [mtdblockd]
226 0 SW< [rpciod/0]
232 0 3092 S -sh
233 0 3092 R ps
#
八、利用udev构建完整的/dev目录
高兴地插入U盘,内核显示识别到了U盘:
# usb 1-1: new full speed USB device using s3c2410-ohci and address 2
usb 1-1: not running at top speed; connect to a high speed hub
usb 1-1: configuration #1 chosen from 1 choice
scsi0 : SCSI emulation for USB Mass Storage devices
scsi 0:0:0:0: Direct-Access Teclast CoolFlash 0.00 PQ: 0 ANSI: 2
sd 0:0:0:0: [sda] 12560384 512-byte hardware sectors (6431 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] 12560384 512-byte hardware sectors (6431 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
sd 0:0:0:0: [sda] Attached SCSI removable disk
但当要使用的时候,却找不到设备文件:
# mount /dev/sda1 /mnt
mount: mounting /dev/sda1 on /mnt failed: No such file or directory
# ls /dev/sda1
ls: /dev/sda1: No such file or directory
/dev目录下只有可怜巴巴的2个设备文件。
# ls /dev
console null
在linux机器上,执行ls /dev可看到几百个设备文件,难道要我揉着酸疼的眼睛查看这几百个设备文件的主、次设备号,然后再手工使用mknod命令来生成这几百个设备文件吗?那你不如杀了我算了!其实构建/dev目录有3种方法:
udev 的原理是:操作系统启动的时候将识别到的所有设备的信息自动导出到/sys目录,然后用户态的应用程序udev根据/sys中的设备信息,自动在/dev 目录下创建所有正确的设备文件。因此我们要做的就是:配置自动生成/sys目录下的内容并调用mdev(mdev是busybox中对udev的简化实 现)。
# ls /sys
# mount -t sysfs none /sys
# ls /sys
block class firmware kernel power
bus devices fs module
# ls /dev
console null
# mdev -s
# ls -l dev | wc -l
140
# ls /dev/sda*
/dev/sda /dev/sda1
可是,当我们将U盘拔出后,发现/dev/sda1并不自动消失;手工删除/dev/sda1后,再重新插入U盘,/dev/sda1也不会自动生成。我们需进行如下操作,以使系统能够实现即插即用:
# echo /sbin/mdev > /proc/sys/kernel/hotplug
将上述工作放到rcS中:
#!/bin/sh
ifconfig eth0 192.168.2.17
mount -t proc none /proc
mount -t sysfs none /sys
echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s
九、使用tmpfs挂载/dev、/tmp、/var目录
似乎我们的根文件系统已经相当完善了。但仔细想一想Nand flash的擦写寿命是有限的这个事实,我们就应该明白,我们应该将/dev、/tmp、/var三个目录挂载为tmpfs文件系统。修改rcS如下:
#!/bin/sh
ifconfig eth0 192.168.2.17
mount -t proc none /proc
mount -t sysfs none /sys
mount -t tmpfs none /dev
mount -t tmpfs none /var
mount -t tmpfs none /tmp
echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s
十、制作根文件系统的jffs2映像文件
根文件系统已经制作完毕,最后一个步骤是将其打包为jffs2映像文件,以供bootloader将其烧录到nand flash上。这只需要执行命令:
dennis@dennis-desktop:/work/nfs_root$ mkfs.jffs2 -n -s 512 -e 16KiB -d fs_mini3 -o fs_mini3.jffs2
这其中:
但由于jffs2映像文件制作工具程序mkfs.jffs2 尚未安装,另外该程序需要用到zlib库,因此我们必须先安装它们:
安装zlib(编译MTD设备工具包需要它)
安装MTD工具包(其中含有jffs2映像文件制作工具)
哇塞,终于写完了。可以睡觉去喏!!!
转自:http://scyz.spaces.live.com/blog/cns!B627F5D454891288!436.entry