嵌入式系统 实验报告
闻悦 孙恩比 虞淦超 孙德一 滑冰 2010年1月5日
一.选题
我们组的实验题目是：将配制过并且用Open64编译过的linux操作系统移植到ebox中。 这个实验是编译原理实验和嵌入式系统实验的结合。我们的小组成员有三位选了董渊老师的编译原理专题训练。当时董渊老师对大实验给出了一个提议，用open64编译器编译busybox，并且和嵌入式系统实验相结合。我们组员感觉这将是一个很好的尝试。另外，在ebox平台上运行linux，网上鲜有现成的案例。我们觉得，虽然ebox运行Embedded WinCE已经可以满足很多商业上的需求，但是linux有它的许多特点是WinCE不具备的。显然最重要的就是它的开源特性，使得功能的开发变得更加灵活，虽然可能没有WinCE容易上手，但是linux可以支持更多的CPU类型，应用的场合也较多。
新的创意往往可以激发我们的干劲。实验刚一开始，我们就为这个前所未有的挑战而激动万分，跃跃欲试。我们也很想通过实验，使得我们在学习嵌入式系统新知识的同时，尝试运用编译知识和巩固以前学过的操作系统知识，以达到使知识融会贯通、学以致用的目的。
在接下来的实验报告中，我们将主要体现嵌入式实验部分的工作。
二.实验过程
嵌入式linux操作系统的三大要素是：bootloader, kernel image和根文件系统。我们也就按照这三点要素来总结我们的实验流程。
1.初选bootloader
在查阅了一些嵌入式linux的资料后，我们把bootloader的备选集定位在了lilo、grub和syslinux上面。根据我们的实验设计，我们希望首先尝试用U盘引导，之后再尝试把U盘的内容写到ebox里面引导linux。明确了需求，我们就对这些bootloader的功能和适用性进行了比较。
Lilo是Grub的前身，grub在很多功能上加强了lilo，在实验设计做好之后，我们进一步询问业内人士并且得到了一些建议：GRUB不像LILO一样使用裸扇区，而是可以从ext2或ext3文件系统中加载Linux内核。这也就是说，如果用U盘做引导，lilo可能不能用，而grub是可以的。syslinux相对于grub是一个更轻量级的引导器，一般用于光盘和U盘。原本我们认为syslinux可能比grub更适合我们的实验，但是由于网上关于grub的参考更多一些，并且我们认为grub是可以胜任预期的工作。于是我们没有实验syslinux，用grub开始了我们的初期实验之旅。
2.编译配制kernel
构建一个根文件系统首先需要的就是加载一个kernel。我们将busybox集成在内核中，这样kernel启动后，再加载initramfs，就可以直接进入带shell的linux环境中了。
kernel我们选择的是Linux2.6.31.6的最新版本。由于ebox使用的Vortex也是x86系统的，因此不需要交叉编译。在编译kernel的时候，我们指定的是自己的initramfs。我们的initramfs只是增加了一个init文件。init是一个hello.c文件，如下： hello.c：
#include #include int main(int argc,char argv[]) { printf(\"hello world, from initramfs.\\n\"); sleep(9999999); return 0; }
创建一个initramfs的源文件目录image，把hello程序拷入，并改名为init。在image下，创建一个dev/console的设备文件，否则无法输出helloworld。
mknod -m 600 dev/console c 5 1
在编译kernel时，在general setup配置目录下的initramfs sources配置项下输入image的路径名。 为我们的init程序是ELF格式的，所以内核需要支持ELF的可执行文件，否则启动这个init程序会失败。在内核的 Executable file formats配置目录下，选择 kernel support for ELF binaries，则可使内核支持ELF格式的可执行文件。
在编译kernel的时候，需要配置选项。kernel中有很多可选模块，makeallconfig是加载所有模块，这样做编译完kernel会很大。makenoconfig是最小化kernel。我们一开始使用的是makedefconfig，使用默认的配置。但是事实证明这是不可取的。在后来grub加载kernel中，出现了cmov问题。kernel无法加载，这是由于可能ebox的主机不支持kernel中的cmov指令。后来我们从网上查找了相关的资料。http://www.daodoc.com.tw/tech/os-xlinux/详细介绍了在Vortex86上的移植。我们下载了kernel，它的kernel非常小，只有2.1Mb，这个kernel是可以用的，但是缺少了硬盘驱动。我们认为可能是在配置的时候，在device一块少了写什么。我们详细试验了一下几个选项的配置：
Generic Driver Options，Block devices，SCSI device support，Serial ATA and Parallel ATA drivers，Multi-device support (RAID and LVM)，Input device support，ATA/ATAPI/MFM/RLL support，经过反复的调试，但是硬盘识别的问题还是没有解决，在进入根目录后，没有找到hd0或是sda文件夹，我们也很困惑。不知道是不是将busybox集成带来的问题。
3.内核中集成Busybox——构造根文件系统
一个简单的内核运行在ebox中是没有意义的，我们进而考虑了如何利用busybox构造基于linux的嵌入式根文件系统。Busybox是一种可以提供很多标准的Unix工具的开源软件，它是专门为linux量身打造的一个轻便的软件包，对于嵌入式系统来说是十分合适的。busybox的使用也是我们此次实验与编译原理专题训练相结合的地方，编译实验要求我们利用目前还不完善的Open64编译器对Busybox源码进行编译，这部分在这里不多说。
在构建根文件系统之前，我们并没有使用busybox，而是尝试构建一个最简单的根文件系统。经过查阅资料，我们发现在编译linux内核的过程中，可以将文件系统部分直接编译到内核当中，这样在内核加载到内存中的时候，文件系统也会相应的随之加载。于是仿照一般的linux的文件系统的目录结构，我们尝试构建自己的文件目录(dev, sys, bin等)。linux内核成功加载之后，会首先运行一个根目录中的名字为init程序，于是我们写了一个打印helloworld的程序，编译之后生成名字为init的可执行文件。然后在qemu模拟器中运行，可以看到在内核加载完毕之后在屏幕上打印helloworld，初期的尝试性工作完成。
关于Busybox使用的第二个步骤是尝试将Busybox编译到内核当中，其中涉及到得问题是如何编译与安装Busybox。在安装Busybox的过程中，程序会自动在选定的安装目录中建立linux的目录结构，并且在/bin中加入了linux的命令。这里需要说明一下，Busybox的功能主要体现在/bin目录中的可执行程序，在编译Busybox的过程中，可以选择让Busybox支持什么样的linux指令，这样在编译安装结束后就会在/bin中出现相应的命令，编译好的linux内核也会支持相应的命令。安装Busybox成功之后，按照初期尝试的编译内核方法，将busybox编译到内核中去。这里需要注意一个问题，如果想在新生成的linux中使用busybox命令，就必须在系统初始化的过程中启动busybox的功能，这是就需要修改init程序。我们以shell脚本的方式写了一个init程序，该程序最后会启动/bin/sh命令（进入新的系统的shell程序）。上述工作完成之后，在qemu中进行模拟，可以发现此时的linux已经支持了常用的linux命令。
尝试busybox的第三个过程是如何将rootfs与kernel分离，之前的工作都是将构建好的文件系统直接编译到内核中，这样如果文件系统过大的话会增加内核的负担，另外，如果嵌入在内核中的文件系统就要求我们每次调试过程都要重新编译一边内核，花费比较多的时间。在这个步骤之中我们通过linux中带的cpio命令，该命令可以对指定的目录中的所有文件进行压缩，生成一个initrd文件，恰好达到我们的要求。这样，最终在qemu中模拟时不仅要选择使用的内核，也要指定相应的initrd。
4.第一次尝试
我们把编译完成的kernel image，initrd文件连同grub一起考到U盘里面，进入ebox，在MBR处选择U盘启动，运行grub，定位kernel和initrd，最后boot，但是boot失败，错误在initrd里面，系统意外中止了。随即我们更换了kernel的版本，重新设置kernel选项，尝试了无数种选项的组合，但是每次boot的时候，这个问题始终存在。
5.第二次尝试
在第一次尝试失败后，我们一度有些摸不清问题的所在，有些灰心丧气。元旦之前集体到陶老师处询问，并且也发邮件给ICOP的工作人员询问了关于kernel无法被引导的问题。看着网上众口不一的解决方案，我们也总结出了一些可能有效的办法。既然实验就是上面的几个部分组成，我们不妨试验一下换一换bootloader，或者换一换kernel。
换kernel是一件比较麻烦的事情，因为这个实验的kernel部分和编译的关系最密切。一旦换kernel，光编译就需要很久，编译部分的实验也要返工。我们大胆决定先换一个bootloader试试看，很幸运，我们成功了。
Grub4dos，一位活跃在某国际嵌入式爱好者论坛的外国朋友曾经向我们提到了这个引导工具，在我们最困难的时候，隔壁宿舍的周以苏同学也提议让我们试一试这个。它是一款主要由中国人维护的grub工具，对原始的grub做了许多改进。我们想既然外国朋友都向我们推荐我们自己的准国产工具，那我们不妨试试。
在用grub4dos替换掉了原先的grub之后，我们再次启动ebox，显示成功。
6.告别U盘
U盘引导完成之后， 我们就很容易告别U盘了。在ebox自带的WinCE里，我们把U盘里面的linux目录拷贝到ebox的硬盘根目录下。再次启动ebox，通过原始默认的MBR进入DOS，运行刚刚拷贝到硬盘根目录下linux文件夹里面的grub4dos，进入grub4dos，设置好kernel和initrd的位置，boot。linux便可以在没有U盘的情况下，直接运行在ebox上了。
7.用grub4dos做MBR
我们现在完成的linux boot过程可以简要概括为： 利用ebox原有的MBR（Master Boot Record）进入DOS，在DOS中找到ebox硬盘里面的grub4dos，利用grub4dos定位kernel和initrd，完成boot。可是在每次boot之前，都需要做一些引导设置的操作。实际grub4dos是可以省略这个二次引导的。它可以被直接装入MBR里面引导kernel和文件系统。我们尝试了这个装入。通过grub4dos提供的grub> fdisk /mbr命令。装入之后启动ebox，出现error 16并无法继续启动。由于原先的MBR已经被替换，ebox也没办法进入dos下，实验到此结束。
三.进一步工作的设想
1.用grub4dos做MBR
在一些情况下，用grub做二次引导的bootloader会更方便，而另一些情况是，把grub装入MBR内会更方便。我们上面已经提到，在实验的最后，装入MBR的过程没有成功。可能是因为误删除了一些grub的文件所致。这一步工作还可以继续尝试。 2.尝试使用syslinux作为bootloader完成实验
这只是一个尝试。因为我们在实验中并没有实测syslinux这个bootloader是否可以很好地工作。实际上grub4dos已经很好了。 3.使用支持更多linux功能的kernel
我们编译的kernel只是一个功能简单到不能再简单的kernel。一个实用的kernel必须做得更好，支持更多的功能，新添更多支持ebox的驱动。
四.实验心得体会
我们这次实验完成将配制过并且用Open64编译器编译过的linux操作系统移植到ebox中。工作大致可以分为编译部分和ebox引导部分。编译部分我们完成了用open64编译kernel以及根文件系统。ebox引导部分我们将编译好的linux操作系统移植到了ebox上。在实验中涉及到许多学科的知识，我们将编译原理、嵌入式系统乃至操作系统等课程的知识结合在一起进行实际使用，是嵌入式系统课之前所没有同学尝试过的一次创新性的实验。当然，有创新，就会有很多不确定的因素，这对我们来说是一次风险性的挑战。实验没有现成的文档可以参考，而且有关ebox上移植linux系统的资料也并不多。在我们遇到问题的时候，我们想了很多方法去解决，在一次次失败中磨练了我们，也使我们对我们的实验越来越深入，越来越了解。在一步一步克服困难的努力中，我们都学到了很多。现在我们做到了这个程度，可以说我们基本上赢了。很感谢老师提供的文档帮助我们解决了一些问题，也很感谢隔壁宿舍的张伟达同学和周以苏同学的帮助，更是有网络上很多国内外的嵌入式爱好者们耐心地解答我们用邮件咨询的种种问题。如此的参与规模，可以说这个实验是大学期间最难以忘怀的实验之一。在实验中，我们真切地体会了团队合作精神，大家一起想办法，同时在团队讨论中，我们每个人都学到了很多。我们觉得，这个实验其实是可以做为一个基础实验来给之后的同学做的。相比于基础实验中在ebox上安装WinCE，我们这个linux实验与底层更贴近。整个boot的过程都在实验的每个环节中充分地体现出来。做完实验，我们可以对MBR、bootloader以至加载kernel和文件系统的整体流程更加清晰。实验还残留着上面提到的一些问题，希望以后会有同学可以继续探索这个实验，也希望这个实验可以继续对以后同学有所帮助吧。
