root文件系统的一点经验(转)[@more@] 这几天折腾一个ARM9（s3c2410）的开发板,从bootloader到kernel，共花了一个多星期的时间，在root文件系统上折腾得最郁闷，不过总算是跑起来了，把自己的一点理解贴出来，希望有点用处，理解有误的地方请大侠们指正。
基本情况是这样：买了一个公司的开发板，但是软件和技术支持非常差，没办法，就试着用turbolinux大侠强力推荐的mizi_SDK for s3c2410ttp://www.mizi.com/en/developer/s3c2410x ），果然是比较好用,bootloader（vivi）稍微改改就可以跑了。但是启动linux的时候，vivi默认的是从NAND flash上启动，在这个上面需要建立一个bon的文件系统，用其中一个分区存放root文件系统，而我的开发板用的是4M的NOR flash，不能直接用vivi在上面建立bon分区，所以启动的时候无法mount root文件系统。后来采用ramdisk 做root文件系统，成功解决问题。下面是一些理解：
1。linux启动时，经过一系列初始化之后，需要mount 根文件系统，为最后运行init进程等做准备，mount 根文件系统有这么几种方式：
1）文件系统已经存在于硬盘（或者类似的设备）的某个分区上了，kernel根据启动的命令行参数（root＝/dev/xxx),直接进行mount。这里有一个问题，在root文件系统本身还不存在的情况下，kernel如何根据/dev/xxx来找到对应的设备呢？原来kernel通过直接解析设备的名称来获得设备的主、从设备号，然后就可以访问对应的设备驱动了。所以在init/main.c中有很长一串的root_dev_names，通过这个表就可以根据设备名称得到设备号。
2）从软驱等比较慢的设备上装载根文件系统，如果kernel支持ramdisk，在装载root文件系统时，内核判断到需要从软盘（fdx）mount，就会自动把文件系统映象复制到ramdisk，一般对应设备ram0，然后在ram0上mount 根文件系统。 从源码看，如果kernel编译时没有支持ramdisk，而启动参数又root=/dev/fd0, 系统将直接在软盘上mount，除了速度比较慢，理论上是可行的（这个我没试过，不知道是不是样？）3）启动时用到initrd来mount根文件系统。一开始我被ramdisk和initrd这两个东西弄胡涂了，其实ramdisk只是在ram上实现的块设备，initrd可以说是启动过程中用到的一种机制。就是在装载linux之前，bootloader可以把一个比较小的根文件系统的映象装载在内存的某个指定位置，姑且把这段内存称为initrd，然后通过传递参数的方式告诉内核initrd的起始地址和大小（也可以把这些参数编译在内核中），在启动阶段就可以暂时的用initrd来mount根文件系统。initrd的最初的目的是为了把kernel的启动分成两个阶段：在kernel中保留最少最基本的启动代码，然后把对各种各样硬件设备的支持以模块的方式放在initrd中，这样就在启动过程中可以从initrd所mount的根文件系统中装载需要的模块。这样的一个好处就是在保持kernel不变的情况下，通过修改initrd中的内容就可以灵活的支持不同的硬件。在启动完成的最后阶段，根文件系统可以重新mount到其他设备上，但是也可以不再重新mount（很多嵌入式系统就是这样）。 initrd的具体实现过程是这样的：bootloader把根文件系统映象装载到内存指定位置，把相关参数传递给内核，内核启动时把initrd中的内容复制到ramdisk中（ram0），把initrd占用的内存释放掉，在ram0上mount根文件系统。从这个过程可以看出，内核需要对同时对ramdisk和initrd的支持。
2。嵌入式系统根文件系统的一种实现方法。对于kernel和根文件系统都存储在flash中的系统，一般可以利用linux启动的initrd的机制。具体的过程前面已经比较清楚了，还有一点就是在启动参数中传递
root=/dev/ram0，这样使得用initrd进行mount的根文件系统不再切换，因为这个时候实际的设备就是ram0。还有就是initrd的起始地址参数为虚拟地址，需要和bootloader中用的物理地址对应。
3。我原来在mcf5307上跑的uClinux在编译的时候就生成一个映象文件，应该是把内核和文件系统都打包到一起了，没有仔细看根文件系统装载是否也是类似的方法，哪位大侠比较清楚给解释解释：）
基本情况是这样：买了一个公司的开发板，但是软件和技术支持非常差，没办法，就试着用turbolinux大侠强力推荐的mizi_SDK for s3c2410ttp://www.mizi.com/en/developer/s3c2410x ），果然是比较好用,bootloader（vivi）稍微改改就可以跑了。但是启动linux的时候，vivi默认的是从NAND flash上启动，在这个上面需要建立一个bon的文件系统，用其中一个分区存放root文件系统，而我的开发板用的是4M的NOR flash，不能直接用vivi在上面建立bon分区，所以启动的时候无法mount root文件系统。后来采用ramdisk 做root文件系统，成功解决问题。下面是一些理解：
1。linux启动时，经过一系列初始化之后，需要mount 根文件系统，为最后运行init进程等做准备，mount 根文件系统有这么几种方式：
1）文件系统已经存在于硬盘（或者类似的设备）的某个分区上了，kernel根据启动的命令行参数（root＝/dev/xxx),直接进行mount。这里有一个问题，在root文件系统本身还不存在的情况下，kernel如何根据/dev/xxx来找到对应的设备呢？原来kernel通过直接解析设备的名称来获得设备的主、从设备号，然后就可以访问对应的设备驱动了。所以在init/main.c中有很长一串的root_dev_names，通过这个表就可以根据设备名称得到设备号。
2）从软驱等比较慢的设备上装载根文件系统，如果kernel支持ramdisk，在装载root文件系统时，内核判断到需要从软盘（fdx）mount，就会自动把文件系统映象复制到ramdisk，一般对应设备ram0，然后在ram0上mount 根文件系统。 从源码看，如果kernel编译时没有支持ramdisk，而启动参数又root=/dev/fd0, 系统将直接在软盘上mount，除了速度比较慢，理论上是可行的（这个我没试过，不知道是不是样？）3）启动时用到initrd来mount根文件系统。一开始我被ramdisk和initrd这两个东西弄胡涂了，其实ramdisk只是在ram上实现的块设备，initrd可以说是启动过程中用到的一种机制。就是在装载linux之前，bootloader可以把一个比较小的根文件系统的映象装载在内存的某个指定位置，姑且把这段内存称为initrd，然后通过传递参数的方式告诉内核initrd的起始地址和大小（也可以把这些参数编译在内核中），在启动阶段就可以暂时的用initrd来mount根文件系统。initrd的最初的目的是为了把kernel的启动分成两个阶段：在kernel中保留最少最基本的启动代码，然后把对各种各样硬件设备的支持以模块的方式放在initrd中，这样就在启动过程中可以从initrd所mount的根文件系统中装载需要的模块。这样的一个好处就是在保持kernel不变的情况下，通过修改initrd中的内容就可以灵活的支持不同的硬件。在启动完成的最后阶段，根文件系统可以重新mount到其他设备上，但是也可以不再重新mount（很多嵌入式系统就是这样）。 initrd的具体实现过程是这样的：bootloader把根文件系统映象装载到内存指定位置，把相关参数传递给内核，内核启动时把initrd中的内容复制到ramdisk中（ram0），把initrd占用的内存释放掉，在ram0上mount根文件系统。从这个过程可以看出，内核需要对同时对ramdisk和initrd的支持。
2。嵌入式系统根文件系统的一种实现方法。对于kernel和根文件系统都存储在flash中的系统，一般可以利用linux启动的initrd的机制。具体的过程前面已经比较清楚了，还有一点就是在启动参数中传递
root=/dev/ram0，这样使得用initrd进行mount的根文件系统不再切换，因为这个时候实际的设备就是ram0。还有就是initrd的起始地址参数为虚拟地址，需要和bootloader中用的物理地址对应。
3。我原来在mcf5307上跑的uClinux在编译的时候就生成一个映象文件，应该是把内核和文件系统都打包到一起了，没有仔细看根文件系统装载是否也是类似的方法，哪位大侠比较清楚给解释解释：）
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10617731/viewspace-959500/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/10617731/viewspace-959500/
371
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
