分类： LINUX
2008-05-03 09:45:08
做Linux嵌入式系统的对常见的几种嵌入式开发环境一定不会默生，由于主要接触网络相关产品的一些系统设计，因此，将可能用到的嵌入式开发环境简要总结一下。主要涉及下面的几个东东：
emDebian -
uClinux -
buildroot -
scratchbox -
openEmbedded -
emDebian
emDebian基于将Debian用于嵌入式系统的目的而开发。Debian是一个发展很快的项目，在我第一次用Debian时，就再也不愿意换用其它的发布版了，目前我用的Debian已经安装了有两年的时间了，但现在系统仍然是“最新”版本，良好的在线软件升级系统是Debian成功的原因之一。目前Debian已经支持11个体系的系统，包括X86、PPC、MIPS、ARM、SH等(据最近的一则消息，ARM有可能不再支持)，并包含了大量的软件。这些要归功于Debian的开发团队，正因为有许多人使用和支持，因此，不是比较偏门的软件，基本上不需要从源码来安装，这也是我喜欢用 Debian的原因之一。
这样好的一个系统，当然有人愿意将其用到嵌入式系统中去。emDebian基于一个很简易的嵌入式系统开发的想法来构造嵌入式系统，即从一个成熟的系统中去除不需要的部份(如文档和不需要的工具)，精简出一个小的系统，这与下面要介绍的几个工具的想法刚好相反(下面几个都是基于 from scratch 即从无到有，从头构建的方式)。emDebian提供一些工具来协助完成从现有的系统或安装包(deb文件，类似Redhat的rpm)中提取需要的东东，并协助完成完整系统的构建，当然也支持交叉构建了，比如你可以在X86 的PC上构建一个基于ARM的嵌入式系统，而整个过程不需要编译任何一行源代码。
顺理成章的，emDebian的重要优势就展现出来了，现在你用的CPU超出11个Debian支持范围了吗？没有，那么你可以简单的通过 emDebian构建目标系统；你所需要的主体软件在Debian支持的官方和非官方近2万个软件以外吗？没有，那么恭喜你，明天就可以给老板交工了。当然，对于特定的软件，可能还是需要从源码来构建，不过同样的，我们可以将其生成Deb包，然后将配置加到emDebian工具集中，同其它所有软件一样的选取和配置。
emDebian的发展似乎不是想像的那么好，现在主页上的新闻更新还是去2004年的。
buildroot
emDebian实际上并不一定适合于资源非常紧缺的超小型系统，比如只有2M Flash的小型控制系统。另外发行版的软件通常会以通用代码来编译，例如，为了尽可能在各种X86平台上都能够安装，大多数发行版通常会以i686甚至 i386代码集来编译软件，可以使文件的通用性很强，但CPU的性能却不能发恢到最好(这就是为什么有时会看到一些厂商或爱好者发布PIII、PIV、 athlon等优化系统的原因)，这对于嵌入式系统来说也不会是一件好事情。另外，没有源码的控制权，一些需要定制的东西也会变得难以实现，因此，从源码开始构建仍然有必要。
嵌入式Linux开发中使用的CPU速度往往向对不会太高，因此，尽可能提高代码的性能就非常必要。通常开发人员应该对该CPU的具体型号有一定的了解，以便启用编译器中对该型号的优化，以ARM为例，我们可以通过 -march=armv5te 和 -mtune=arm9tdmi 来对代码在ARM9上的运行进行优化。有时这些优化体现出来的性能改善是比较大的，我曾对比过一些复杂算法的代码优化前后的性能(执行速度)，都有一定的提升。另外在PIV上测试过以i686和pentium4对一个语音编码算法进行优化，运算速度居然提高了几倍。
这种幅度的提升可能只是一个特例，这个算法有大量的复杂浮点运算，使用i386或i686指令集和使用更先进的PIV指令集编译出来的机器代码对于同一个运算的解释可能采用完全不同的指令来完成，因此性能提升较大就不足为奇了。同样这种代码，在ARM上通过ARM4和ARM5来优化后在ARM9上运行，却没有那么大的提升。看来对CPU的一定了解也应该是嵌入式系统软件设计者应该具备的能力。
那么又如何控制可执行文件的大小呢？除了却除软件中不需要的部份外，我们还应该考虑软件所引用的库文件。GNU的Glibc是一个非常宠大而完整的库，至少对于嵌入式系统来说，其体积显得过于大了一些。uClibc的提出较好的解决了这样一个问题。uClibc尽可能的兼容Glibc，大多数应用程序可以在很小或完全不修改的情况下就可能使用uClibc替代glibc。通过uClibc来代替Glibc，可以在不改变应用程序功能的前提下，大大减少发布文件的大小，无论应用程序以静态链接来编译，还是以动态链接形式编译。
不过使用uClibc代替并不是简单的设置一两个参数就行了，通常需要使用一个不同的工具集(gcc/binutils等)来编译代源码。手工的构造这样一个环境，对于大多数普通程序员来说，不一定是一件很简单的事情，因此，uClibc的开发者创造出一个叫做buildroot的工具集。 buildroot将自动构造编译基于uClibc代码的工具集和uClibc库，并提供一个可配置的框架和一些构建一个基本系统的配置文件。用户只需要通过配置菜单选择了相应的目标软件，buildroot就可以从构建基本工具集开始，一直到最后构建出目标系统所需要的东西，如嵌入式系统常用的基于 ext2的initrd，jffs根文件系统，压缩的根目录树等，这些代码都是基于uClibc而不是系统的Glibc的。Buildroot对主机系统的要求较小，通常只需要主机系统提供足以构建工具链(toolchain)的工具，如gcc/binutils等，当工具链编译完成后，对目标系统需要的源码的编译过程与主机系统的开发工具集基本上就没有什么关系了。因此，不同的主机如果能够通过第一步，编译完成工具链，那么编译出来的目标系统的执行代码就可以几乎不存在由于系统引起的差异。这样，开发人员就可能在各自喜欢的Linux发行版上进行开发，而不必担心出现什么兼容性问题。
uClinux
uClinux与emDebian至少有两个重要的区别，第一是构建方式，前面已经提到过了，uClinux属于 from scratch 一类的。另一个不同的地方，uClinux是支持不在emDebian支持的11种CPU的，当然，这个说法不是很恰当，正确的说法是uClinux支持那些不具备MMU单元的CPU体系。uClinux的第一个目的是支持MC68328芯片，现在已经能构支持更多的CPU，如Intel i960，ARM等。不过，uClinux的主体开发团队目前已经不再支持ARM了，还好 Samsung 的 Hyok S. Choi 接过了接励棒，Linux 2.6版本的补丁可以在 uClinux/ARM2.6 找到。
uClinux之前仅是核心的一些补丁，后来发展成为一个包括核心、库、应用程序、工具和编译相关的配置文件的一个集成开发环境。与 buildroot不同的是，uClinux不编译目标系统的工具集，也就是说，相应的编译工具应该提前安装好。如，对于arm来说，需要先安装ARM交叉编译器。uClinux的编译器也需要一些补丁，其中比较重要的两个方面主要包括：
用于生成FLT文件的补丁：由于MMU的关系，uClinux不支持ELF可执行文件，这个补丁主要包括bin2flt工具包和一个ld的wrapper脚本等，用于(透明于用户)生成FLT文件；
用于支持XIP(Execute In Place)的补丁：这个补丁需要对gcc进行一些小的修改；支持XIP主要是为了解决小内存环境中运行的问题。
XIP不一定适用于每种应用环境，对于内在要求特别严格的系统来说(空间第一位，如手机要求使用片内RAM)，可以通过将核心和应用程序编译为XIP 支持，然后直接在Flash上运行，内存仅用于运行时数据；而对于性能要求为主的系统(如高速网络处理器)，则不能因为节省一点空间而使用XIP将程序直接在Flash上运行，这样可能会降低指令的读取速度而影响系统性能(但仍然可以使用XIP，使程序的多个实例在内存中共享代码空间，以后详细说)； + FLT可执行文件支持动态链接库(目前仅m68k支持，参见 uCdot: Shared libraries under uClinux mini-HOWTO)的补丁；
uClinux的编译过程大致是，首先，通过可视配置界面(menuconfig/xconfig)选取Vendor和board(实际上是选择了一些配置文件和产品相关的文件)，然后根据选择构造一个适用于target的开发环境，如生成头文件和需要的库文件(uClibc、glibc或uC- libc 以及其它一些库)，然后编译核心、库、应用程序，最后将所有的输出安装到romfs目录中，根据需要生成目标平台需要的映像文件(如： romfs.img、linux.bin、rootfs.gz等)
由于一些过程细节被隐藏起来，uClinux现在的编译过程方便到只需要配置一下(make menuconfig)，然后 make 就可以直接获得最终输出。不过这反倒成为一些初学者学习的一个麻烦，本文完成后，根据对本文的反馈，将进一步对uClinux进行详细介绍。
总的来说，目前的uClinux是一套主要用于无MMU核(但不限于此)的嵌入式Linux集成环境，也是一个非常好的 Linux from scratch 的示例。抛开其MMU相关的补丁，uClinux也可以作为一套用于包含MMU系统的集成开发环境，Snapgear 就是一个很好的例子。实际上，我们可以从官方的uClinux源码就可以直接编译一个支运行于X86的uClinux。
Scratchbox
Scratchbox 的故事要从buildroot讲起(这不一定是scratchbox开发者的故事，只是依据我个人的认识)。buildroot可以从头开始，先构造编译器和基本开发环境，然后根据用户配配置构造一个适用于目标平台的根文件系统。这个文件系统可以有许多用法，例如，做为initrd或通过NFS输出给目标系统使用。为了减少交叉编译软件带来的麻烦，可以配置buidroot创建一套目标系统的编译环境(Gcc、binutils、lib等)，这样用户可以通过这个基本文系统在目标系统上直接本地编译软件。如果目标系统性能足够的话，buildroot的任务到此就基本结束了。对于嵌入式系统的开发者来说，在目标系统上直接编译代码却不一定都能够实现，因为多数情况下，我们的目标平台处理器性能并不会那么高，这样，我们就不得不面对一个两难的选择：
继续通过buildroot编译其它的软件，性能会高许多，但每个软件都需要进行交叉编译相关的改造；
在目标平台上编译软件，对于只有几十或几百兆的低性能核来说，编译一个核心可能会让你等上半天的时间；
有没有好的办法解决性能和交叉编译的问题呢？先分析一下通过buildroot交叉编译不能解决的问题。Buildroot只在一定程度上对目标平台进行了模拟，但仍有一些是无法实现的，例如，当目标平台不同于主机平台时，不能生成并运行目标平台的中间代码。这样，许多通过autotools (autoconf/automake)配置的软件就可能会出现问题。例如，configure 脚本有时会生成一些中间代码，并试图运行以确认开发环境中是否存在某个库文件或头文件，对于在X86上编译基于uClibc X86目标平台代码可能不会出现问题，但如果目标平台是X86以外的平台，编译就可能会中断；又如，configure脚本确认编译器是否工作，会试图编译一个包含空的主程序的代码并运行，实际一个可运行于目标平台的 a.out 确实生成了，也可以正常运行于目标平台，但是这个测试会因为 a.out 被运行在主机系统上而错误的中断。这些问题一些被 buildroot 通过补丁或复杂的 configure 参数解决了，某些中间执行文件，则通过HOSTCC(主机上的CC)来生成并运行以生成最终文件。目前buildroot包含的软件或多或少都会有一些这样的补丁，而且开发者一旦深入到对软件的定制，就会不停的被这些问题所困扰。
Scratchbox相比于buildroot有几方面的改进：
运行于 chroot 的环境，完全独立于主机，编译过程将基本与主机系统无关(并且scratchbox修改了一些库，使得普通用户可以chroot到编译环境中，并且多个用户可以同时使用一套Scratchbox开发套件和完全独立的用户资源)；
透过qemu模拟运行或sbrsh解决中间执行文件或类似configure测试文件运行的问题；
对(chroot后)的系统进行修定，达到足以欺骗大多数软件的效果，这并不是指的让软件可以不进行改造就可以 交叉 编译，而是使软件 误认为 这就是在目标平台上编译；
不过 Scratchbox 目前还只能编译 ARM 和 x86 的代码，不能支持 buildroot 所支持的 ppc、mips等。
本文不详述每一种环境，因此各个软件都只是点到为止(虽然可以讲得更详细一些，但这些内容还是独立出来比较好一些)，不过这里还是引入一个很简单的示例，根据 scratchbox 网站上的文档，安装完成后，进行简单配置就可以使用了(Debian用户的安装可以更简单，因为该站提供Deb包，直接apt-get就行了)。通过 /scratchbox/login 登入开发环境，通过sb-menu配置一个基于 ARM 的环境(其中 Select CPU-transparency method 选qemu不要先sbrsh)，然后写一个 helloword.c，编译并运行之。通过ldd可以看到，在没有任可改动的情况下，顺利的生成了ARM ELF，但在 scratchbox 里却可以在X86的主机上正常的运行！
[sbox-redice: ~] > gcc -o hello hello.c
[sbox-redice: ~] > file hellohello:
ELF 32-bit LSB executable, ARM, version 1 (ARM),
for GNU/Linux 2.0.0,dynamically linked (uses shared libs),
not stripped[sbox-redice: ~] >
./hellohelo world![sbox-redice: ~] >
