幾種Linux嵌入式開發(fā)環(huán)境的簡(jiǎn)單介紹
——
加入技術(shù)交流群
emDebian - http://emdebian.sourceforge.net
uClinux - http://www.uclinux.org
buildroot - http://buildroot.uclibc.org
scratchbox - http://www.scratchbox.org
openEmbedded - http://oe.handhelds.org
emDebian
emDebian基于將Debian用于嵌入式系統(tǒng)的目的而開發(fā)。Debian是一個(gè)發(fā)展很快的項(xiàng)目，在我第一次用Debian時(shí)，就再也不愿意換用其它的發(fā)布版了，目前我用的Debian已經(jīng)安裝了有兩年的時(shí)間了，但現(xiàn)在系統(tǒng)仍然是“最新”版本，良好的在線軟件升級(jí)系統(tǒng)是Debian成功的原因之一。目前Debian已經(jīng)支持11個(gè)體系的系統(tǒng)，包括X86、PPC、MIPS、ARM、SH等（據(jù)最近的一則消息，ARM有可能不再支持），并包含了大量的軟件。這些要?dú)w功于Debian的開發(fā)團(tuán)隊(duì)，正因?yàn)橛性S多人使用和支持，因此，不是比較偏門的軟件，基本上不需要從源碼來安裝，這也是我喜歡用 Debian的原因之一。
這樣好的一個(gè)系統(tǒng)，當(dāng)然有人愿意將其用到嵌入式系統(tǒng)中去。emDebian基于一個(gè)很簡(jiǎn)易的嵌入式系統(tǒng)開發(fā)的想法來構(gòu)造嵌入式系統(tǒng)，即從一個(gè)成熟的系統(tǒng)中去除不需要的部份（如文檔和不需要的工具），精簡(jiǎn)出一個(gè)小的系統(tǒng)，這與下面要介紹的幾個(gè)工具的想法剛好相反（下面幾個(gè)都是基于 from scratch 即從無到有，從頭構(gòu)建的方式）。emDebian提供一些工具來協(xié)助完成從現(xiàn)有的系統(tǒng)或安裝包（deb文件，類似Redhat的rpm）中提取需要的東東，并協(xié)助完成完整系統(tǒng)的構(gòu)建，當(dāng)然也支持交叉構(gòu)建了，比如你可以在X86 的PC上構(gòu)建一個(gè)基于ARM的嵌入式系統(tǒng)，而整個(gè)過程不需要編譯任何一行源代碼。
順理成章的，emDebian的重要優(yōu)勢(shì)就展現(xiàn)出來了，現(xiàn)在你用的CPU超出11個(gè)Debian支持范圍了嗎？沒有，那么你可以簡(jiǎn)單的通過 emDebian構(gòu)建目標(biāo)系統(tǒng)；你所需要的主體軟件在Debian支持的官方和非官方近2萬個(gè)軟件以外嗎？沒有，那么恭喜你，明天就可以給老板交工了。當(dāng)然，對(duì)于特定的軟件，可能還是需要從源碼來構(gòu)建，不過同樣的，我們可以將其生成Deb包，然后將配置加到emDebian工具集中，同其它所有軟件一樣的選取和配置。
emDebian的發(fā)展似乎不是想像的那么好，現(xiàn)在主頁上的新聞更新還是去2004年的。
buildroot
emDebian實(shí)際上并不一定適合于資源非常緊缺的超小型系統(tǒng)，比如只有2M Flash的小型控制系統(tǒng)。另外發(fā)行版的軟件通常會(huì)以通用代碼來編譯，例如，為了盡可能在各種X86平臺(tái)上都能夠安裝，大多數(shù)發(fā)行版通常會(huì)以i686甚至 i386代碼集來編譯軟件，可以使文件的通用性很強(qiáng)，但CPU的性能卻不能發(fā)恢到最好（這就是為什么有時(shí)會(huì)看到一些廠商或愛好者發(fā)布PIII、PIV、 athlon等優(yōu)化系統(tǒng)的原因），這對(duì)于嵌入式系統(tǒng)來說也不會(huì)是一件好事情。另外，沒有源碼的控制權(quán)，一些需要定制的東西也會(huì)變得難以實(shí)現(xiàn)，因此，從源碼開始構(gòu)建仍然有必要。
嵌入式Linux開發(fā)中使用的CPU速度往往向?qū)Σ粫?huì)太高，因此，盡可能提高代碼的性能就非常必要。通常開發(fā)人員應(yīng)該對(duì)該CPU的具體型號(hào)有一定的了解，以便啟用編譯器中對(duì)該型號(hào)的優(yōu)化，以ARM為例，我們可以通過 -march=armv5te 和 -mtune=arm9tdmi 來對(duì)代碼在ARM9上的運(yùn)行進(jìn)行優(yōu)化。有時(shí)這些優(yōu)化體現(xiàn)出來的性能改善是比較大的，我曾對(duì)比過一些復(fù)雜算法的代碼優(yōu)化前后的性能（執(zhí)行速度），都有一定的提升。另外在PIV上測(cè)試過以i686和pentium4對(duì)一個(gè)語音編碼算法進(jìn)行優(yōu)化，運(yùn)算速度居然提高了幾倍。
這種幅度的提升可能只是一個(gè)特例，這個(gè)算法有大量的復(fù)雜浮點(diǎn)運(yùn)算，使用i386或i686指令集和使用更先進(jìn)的PIV指令集編譯出來的機(jī)器代碼對(duì)于同一個(gè)運(yùn)算的解釋可能采用完全不同的指令來完成，因此性能提升較大就不足為奇了。同樣這種代碼，在ARM上通過ARM4和ARM5來優(yōu)化后在ARM9上運(yùn)行，卻沒有那么大的提升?？磥韺?duì)CPU的一定了解也應(yīng)該是嵌入式系統(tǒng)軟件設(shè)計(jì)者應(yīng)該具備的能力。
那么又如何控制可執(zhí)行文件的大小呢？除了卻除軟件中不需要的部份外，我們還應(yīng)該考慮軟件所引用的庫文件。GNU的Glibc是一個(gè)非常寵大而完整的庫，至少對(duì)于嵌入式系統(tǒng)來說，其體積顯得過于大了一些。uClibc的提出較好的解決了這樣一個(gè)問題。uClibc盡可能的兼容Glibc，大多數(shù)應(yīng)用程序可以在很小或完全不修改的情況下就可能使用uClibc替代glibc。通過uClibc來代替Glibc，可以在不改變應(yīng)用程序功能的前提下，大大減少發(fā)布文件的大小，無論應(yīng)用程序以靜態(tài)鏈接來編譯，還是以動(dòng)態(tài)鏈接形式編譯。
不過使用uClibc代替并不是簡(jiǎn)單的設(shè)置一兩個(gè)參數(shù)就行了，通常需要使用一個(gè)不同的工具集（gcc/binutils等）來編譯代源碼。手工的構(gòu)造這樣一個(gè)環(huán)境，對(duì)于大多數(shù)普通程序員來說，不一定是一件很簡(jiǎn)單的事情，因此，uClibc的開發(fā)者創(chuàng)造出一個(gè)叫做buildroot的工具集。 buildroot將自動(dòng)構(gòu)造編譯基于uClibc代碼的工具集和uClibc庫，并提供一個(gè)可配置的框架和一些構(gòu)建一個(gè)基本系統(tǒng)的配置文件。用戶只需要通過配置菜單選擇了相應(yīng)的目標(biāo)軟件，buildroot就可以從構(gòu)建基本工具集開始，一直到最后構(gòu)建出目標(biāo)系統(tǒng)所需要的東西，如嵌入式系統(tǒng)常用的基于 ext2的initrd，jffs根文件系統(tǒng)，壓縮的根目錄樹等，這些代碼都是基于uClibc而不是系統(tǒng)的Glibc的。Buildroot對(duì)主機(jī)系統(tǒng)的要求較小，通常只需要主機(jī)系統(tǒng)提供足以構(gòu)建工具鏈(toolchain)的工具，如gcc/binutils等，當(dāng)工具鏈編譯完成后，對(duì)目標(biāo)系統(tǒng)需要的源碼的編譯過程與主機(jī)系統(tǒng)的開發(fā)工具集基本上就沒有什么關(guān)系了。因此，不同的主機(jī)如果能夠通過第一步，編譯完成工具鏈，那么編譯出來的目標(biāo)系統(tǒng)的執(zhí)行代碼就可以幾乎不存在由于系統(tǒng)引起的差異。這樣，開發(fā)人員就可能在各自喜歡的Linux發(fā)行版上進(jìn)行開發(fā)，而不必?fù)?dān)心出現(xiàn)什么兼容性問題。
uClinux
uClinux與emDebian至少有兩個(gè)重要的區(qū)別，第一是構(gòu)建方式，前面已經(jīng)提到過了，uClinux屬于 from scratch 一類的。另一個(gè)不同的地方，uClinux是支持不在emDebian支持的11種CPU的，當(dāng)然，這個(gè)說法不是很恰當(dāng)，正確的說法是uClinux支持那些不具備MMU單元的CPU體系。uClinux的第一個(gè)目的是支持MC68328芯片，現(xiàn)在已經(jīng)能構(gòu)支持更多的CPU，如Intel i960，ARM等。不過，uClinux的主體開發(fā)團(tuán)隊(duì)目前已經(jīng)不再支持ARM了，還好 Samsung 的 Hyok S. Choi 接過了接勵(lì)棒，Linux 2.6版本的補(bǔ)丁可以在 uClinux/ARM2.6 找到。
uClinux之前僅是核心的一些補(bǔ)丁，后來發(fā)展成為一個(gè)包括核心、庫、應(yīng)用程序、工具和編譯相關(guān)的配置文件的一個(gè)集成開發(fā)環(huán)境。與 buildroot不同的是，uClinux不編譯目標(biāo)系統(tǒng)的工具集，也就是說，相應(yīng)的編譯工具應(yīng)該提前安裝好。如，對(duì)于arm來說，需要先安裝ARM交叉編譯器。uClinux的編譯器也需要一些補(bǔ)丁，其中比較重要的兩個(gè)方面主要包括：
用于生成FLT文件的補(bǔ)?。河捎贛MU的關(guān)系，uClinux不支持ELF可執(zhí)行文件，這個(gè)補(bǔ)丁主要包括bin2flt工具包和一個(gè)ld的wrapper腳本等，用于(透明于用戶)生成FLT文件；
用于支持XIP(Execute In Place)的補(bǔ)丁：這個(gè)補(bǔ)丁需要對(duì)gcc進(jìn)行一些小的修改；支持XIP主要是為了解決小內(nèi)存環(huán)境中運(yùn)行的問題。
XIP不一定適用于每種應(yīng)用環(huán)境，對(duì)于內(nèi)在要求特別嚴(yán)格的系統(tǒng)來說（空間第一位，如手機(jī)要求使用片內(nèi)RAM），可以通過將核心和應(yīng)用程序編譯為XIP支持，然后直接在Flash上運(yùn)行，內(nèi)存僅用于運(yùn)行時(shí)數(shù)據(jù)；而對(duì)于性能要求為主的系統(tǒng)（如高速網(wǎng)絡(luò)處理器），則不能因?yàn)楣?jié)省一點(diǎn)空間而使用XIP將程序直接在Flash上運(yùn)行，這樣可能會(huì)降低指令的讀取速度而影響系統(tǒng)性能（但仍然可以使用XIP，使程序的多個(gè)實(shí)例在內(nèi)存中共享代碼空間，以后詳細(xì)說）； + FLT可執(zhí)行文件支持動(dòng)態(tài)鏈接庫(目前僅m68k支持，參見 uCdot: Shared libraries under uClinux mini-HOWTO)的補(bǔ)丁；
uClinux的編譯過程大致是，首先，通過可視配置界面（menuconfig/xconfig）選取Vendor和board（實(shí)際上是選擇了一些配置文件和產(chǎn)品相關(guān)的文件），然后根據(jù)選擇構(gòu)造一個(gè)適用于target的開發(fā)環(huán)境，如生成頭文件和需要的庫文件（uClibc、glibc或uC-libc 以及其它一些庫），然后編譯核心、庫、應(yīng)用程序，最后將所有的輸出安裝到romfs目錄中，根據(jù)需要生成目標(biāo)平臺(tái)需要的映像文件（如： romfs.img、linux.bin、rootfs.gz等）
由于一些過程細(xì)節(jié)被隱藏起來，uClinux現(xiàn)在的編譯過程方便到只需要配置一下(make menuconfig)，然后 make 就可以直接獲得最終輸出。不過這反倒成為一些初學(xué)者學(xué)習(xí)的一個(gè)麻煩，本文完成后，根據(jù)對(duì)本文的反饋，將進(jìn)一步對(duì)uClinux進(jìn)行詳細(xì)介紹。
總的來說，目前的uClinux是一套主要用于無MMU核（但不限于此）的嵌入式Linux集成環(huán)境，也是一個(gè)非常好的 Linux from scratch 的示例。拋開其MMU相關(guān)的補(bǔ)丁，uClinux也可以作為一套用于包含MMU系統(tǒng)的集成開發(fā)環(huán)境，Snapgear 就是一個(gè)很好的例子。實(shí)際上，我們可以從官方的uClinux源碼就可以直接編譯一個(gè)支運(yùn)行于X86的uClinux。
Scratchbox
Scratchbox 的故事要從buildroot講起（這不一定是scratchbox開發(fā)者的故事，只是依據(jù)我個(gè)人的認(rèn)識(shí)）。buildroot可以從頭開始，先構(gòu)造編譯器和基本開發(fā)環(huán)境，然后根據(jù)用戶配配置構(gòu)造一個(gè)適用于目標(biāo)平臺(tái)的根文件系統(tǒng)。這個(gè)文件系統(tǒng)可以有許多用法，例如，做為initrd或通過NFS輸出給目標(biāo)系統(tǒng)使用。為了減少交叉編譯軟件帶來的麻煩，可以配置buidroot創(chuàng)建一套目標(biāo)系統(tǒng)的編譯環(huán)境（Gcc、binutils、lib等），這樣用戶可以通過這個(gè)基本文系統(tǒng)在目標(biāo)系統(tǒng)上直接本地編譯軟件。如果目標(biāo)系統(tǒng)性能足夠的話，buildroot的任務(wù)到此就基本結(jié)束了。對(duì)于嵌入式系統(tǒng)的開發(fā)者來說，在目標(biāo)系統(tǒng)上直接編譯代碼卻不一定都能夠?qū)崿F(xiàn)，因?yàn)槎鄶?shù)情況下，我們的目標(biāo)平臺(tái)處理器性能并不會(huì)那么高，這樣，我們就不得不面對(duì)一個(gè)兩難的選擇：
繼續(xù)通過buildroot編譯其它的軟件，性能會(huì)高許多，但每個(gè)軟件都需要進(jìn)行交叉編譯相關(guān)的改造；
在目標(biāo)平臺(tái)上編譯軟件，對(duì)于只有幾十或幾百兆的低性能核來說，編譯一個(gè)核心可能會(huì)讓你等上半天的時(shí)間；
有沒有好的辦法解決性能和交叉編譯的問題呢？先分析一下通過buildroot交叉編譯不能解決的問題。Buildroot只在一定程度上對(duì)目標(biāo)平臺(tái)進(jìn)行了模擬，但仍有一些是無法實(shí)現(xiàn)的，例如，當(dāng)目標(biāo)平臺(tái)不同于主機(jī)平臺(tái)時(shí)，不能生成并運(yùn)行目標(biāo)平臺(tái)的中間代碼。這樣，許多通過autotools （autoconf/automake）配置的軟件就可能會(huì)出現(xiàn)問題。例如，configure 腳本有時(shí)會(huì)生成一些中間代碼，并試圖運(yùn)行以確認(rèn)開發(fā)環(huán)境中是否存在某個(gè)庫文件或頭文件，對(duì)于在X86上編譯基于uClibc X86目標(biāo)平臺(tái)代碼可能不會(huì)出現(xiàn)問題，但如果目標(biāo)平臺(tái)是X86以外的平臺(tái)，編譯就可能會(huì)中斷；又如，configure腳本確認(rèn)編譯器是否工作，會(huì)試圖編譯一個(gè)包含空的主程序的代碼并運(yùn)行，實(shí)際一個(gè)可運(yùn)行于目標(biāo)平臺(tái)的 a.out 確實(shí)生成了，也可以正常運(yùn)行于目標(biāo)平臺(tái)，但是這個(gè)測(cè)試會(huì)因?yàn)?nbsp;a.out 被運(yùn)行在主機(jī)系統(tǒng)上而錯(cuò)誤的中斷。這些問題一些被 buildroot 通過補(bǔ)丁或復(fù)雜的 configure 參數(shù)解決了，某些中間執(zhí)行文件，則通過HOSTCC（主機(jī)上的CC）來生成并運(yùn)行以生成最終文件。目前buildroot包含的軟件或多或少都會(huì)有一些這樣的補(bǔ)丁，而且開發(fā)者一旦深入到對(duì)軟件的定制，就會(huì)不停的被這些問題所困擾。
Scratchbox相比于buildroot有幾方面的改進(jìn)：
運(yùn)行于 chroot 的環(huán)境，完全獨(dú)立于主機(jī)，編譯過程將基本與主機(jī)系統(tǒng)無關(guān)（并且scratchbox修改了一些庫，使得普通用戶可以chroot到編譯環(huán)境中，并且多個(gè)用戶可以同時(shí)使用一套Scratchbox開發(fā)套件和完全獨(dú)立的用戶資源）；
透過qemu模擬運(yùn)行或sbrsh解決中間執(zhí)行文件或類似configure測(cè)試文件運(yùn)行的問題；
對(duì)(chroot后)的系統(tǒng)進(jìn)行修定，達(dá)到足以欺騙大多數(shù)軟件的效果，這并不是指的讓軟件可以不進(jìn)行改造就可以 交叉 編譯，而是使軟件 誤認(rèn)為 這就是在目標(biāo)平臺(tái)上編譯；
不過 Scratchbox 目前還只能編譯 ARM 和 x86 的代碼，不能支持 buildroot 所支持的 ppc、mips等。
本文不詳述每一種環(huán)境，因此各個(gè)軟件都只是點(diǎn)到為止(雖然可以講得更詳細(xì)一些，但這些內(nèi)容還是獨(dú)立出來比較好一些），不過這里還是引入一個(gè)很簡(jiǎn)單的示例，根據(jù) scratchbox 網(wǎng)站上的文檔，安裝完成后，進(jìn)行簡(jiǎn)單配置就可以使用了（Debian用戶的安裝可以更簡(jiǎn)單，因?yàn)樵撜咎峁〥eb包，直接apt-get就行了）。通過 /scratchbox/login 登入開發(fā)環(huán)境，通過sb-menu配置一個(gè)基于 ARM 的環(huán)境（其中 Select CPU-transparency method 選qemu不要先sbrsh），然后寫一個(gè) helloword.c，編譯并運(yùn)行之。 通過ldd可以看到，在沒有任可改動(dòng)的情況下，順利的生成了ARM ELF，但在 scratchbox 里卻可以在X86的主機(jī)上正常的運(yùn)行！
評(píng)論