幾種Linux下嵌入式開(kāi)發(fā)環(huán)境的簡(jiǎn)單介紹

　　做Linux嵌入式系統的對常見(jiàn)的幾種嵌入式開(kāi)發(fā)環(huán)境一定不會(huì )陌生，由于主要接觸網(wǎng)絡(luò )相關(guān)產(chǎn)品的一些系統設計，因此，將可能用到的嵌入式開(kāi)發(fā)環(huán)境簡(jiǎn)要總結一下。主要涉及下面的幾個(gè)東東：

　　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用于嵌入式系統的目的而開(kāi)發(fā)。Debian是一個(gè)發(fā)展很快的項目，在我第一次用Debian時(shí)，就再也不愿意換用其它的發(fā)布版了，目前我用的Debian已經(jīng)安裝了有兩年的時(shí)間了，但現在系統仍然是 “最新”版本，良好的在線(xiàn)軟件升級系統是Debian成功的原因之一。目前Debian已經(jīng)支持11個(gè)體系的系統，包括X86、PPC、MIPS、 ARM、SH等(據最近的一則消息，ARM有可能不再支持)，并包含了大量的軟件。這些要歸功于Debian的開(kāi)發(fā)團隊，正因為有許多人使用和支持，因此，不是比較偏門(mén)的軟件，基本上不需要從源碼來(lái)安裝，這也是我喜歡用 Debian的原因之一。

　　這樣好的一個(gè)系統，當然有人愿意將其用到嵌入式系統中去。emDebian基于一個(gè)很簡(jiǎn)易的嵌入式系統開(kāi)發(fā)的想法來(lái)構造嵌入式系統，即從一個(gè)成熟的系統中去除不需要的部份(如文檔和不需要的工具)，精簡(jiǎn)出一個(gè)小的系統，這與下面要介紹的幾個(gè)工具的想法剛好相反(下面幾個(gè)都是基于 from scratch 即從無(wú)到有，從頭構建的方式)。emDebian提供一些工具來(lái)協(xié)助完成從現有的系統或安裝包(deb文件，類(lèi)似Redhat的rpm)中提取需要的東東，并協(xié)助完成完整系統的構建，當然也支持交叉構建了，比如你可以在X86 的PC上構建一個(gè)基于A(yíng)RM的嵌入式系統，而整個(gè)過(guò)程不需要編譯任何一行源代碼。

　　順理成章的，emDebian的重要優(yōu)勢就展現出來(lái)了，現在你用的CPU超出11個(gè) Debian支持范圍了嗎?沒(méi)有，那么你可以簡(jiǎn)單的通過(guò) emDebian構建目標系統;你所需要的主體軟件在Debian支持的官方和非官方近2萬(wàn)個(gè)軟件以外嗎?沒(méi)有，那么恭喜你，明天就可以給老板交工了。當然，對于特定的軟件，可能還是需要從源碼來(lái)構建，不過(guò)同樣的，我們可以將其生成Deb包，然后將配置加到emDebian工具集中，同其它所有軟件一樣的選取和配置。

　　emDebian的發(fā)展似乎不是想像的那么好，現在主頁(yè)上的新聞更新還是去2004年的。

　　◆buildroot

　　emDebian實(shí)際上并不一定適合于資源非常緊缺的超小型系統，比如只有2M Flash的小型控制系統。另外發(fā)行版的軟件通常會(huì )以通用代碼來(lái)編譯，例如，為了盡可能在各種X86平臺上都能夠安裝，大多數發(fā)行版通常會(huì )以i686甚至 i386代碼集來(lái)編譯軟件，可以使文件的通用性很強，但CPU的性能卻不能發(fā)恢到最好(這就是為什么有時(shí)會(huì )看到一些廠(chǎng)商或愛(ài)好者發(fā)布PIII、PIV、 athlon等優(yōu)化系統的原因)，這對于嵌入式系統來(lái)說(shuō)也不會(huì )是一件好事情。另外，沒(méi)有源碼的控制權，一些需要定制的東西也會(huì )變得難以實(shí)現，因此，從源碼開(kāi)始構建仍然有必要。

　　嵌入式Linux開(kāi)發(fā)中使用的CPU速度往往向對不會(huì )太高，因此，盡可能提高代碼的性能就非常必要。通常開(kāi)發(fā)人員應該對該CPU的具體型號有一定的了解，以便啟用編譯器中對該型號的優(yōu)化，以ARM為例，我們可以通過(guò) -march=armv5te 和 -mtune=arm9tdmi 來(lái)對代碼在A(yíng)RM9上的運行進(jìn)行優(yōu)化。有時(shí)這些優(yōu)化體現出來(lái)的性能改善是比較大的，我曾對比過(guò)一些復雜算法的代碼優(yōu)化前后的性能(執行速度)，都有一定的提升。另外在PIV上測試過(guò)以i686和pentium4對一個(gè)語(yǔ)音編碼算法進(jìn)行優(yōu)化，運算速度居然提高了幾倍。

　　這種幅度的提升可能只是一個(gè)特例，這個(gè)算法有大量的復雜浮點(diǎn)運算，使用i386或 i686指令集和使用更先進(jìn)的PIV指令集編譯出來(lái)的機器代碼對于同一個(gè)運算的解釋可能采用完全不同的指令來(lái)完成，因此性能提升較大就不足為奇了。同樣這種代碼，在A(yíng)RM上通過(guò)ARM4和ARM5來(lái)優(yōu)化后在A(yíng)RM9上運行，卻沒(méi)有那么大的提升?？磥?lái)對CPU的一定了解也應該是嵌入式系統軟件設計者應該具備的能力。

　　那么又如何控制可執行文件的大小呢?除了卻除軟件中不需要的部份外，我們還應該考慮軟件所引用的庫文件。GNU的Glibc是一個(gè)非常寵大而完整的庫，至少對于嵌入式系統來(lái)說(shuō)，其體積顯得過(guò)于大了一些。uClibc的提出較好的解決了這樣一個(gè)問(wèn)題。uClibc盡可能的兼容Glibc，大多數應用程序可以在很小或完全不修改的情況下就可能使用uClibc替代glibc。通過(guò) uClibc來(lái)代替Glibc，可以在不改變應用程序功能的前提下，大大減少發(fā)布文件的大小，無(wú)論應用程序以靜態(tài)鏈接來(lái)編譯，還是以動(dòng)態(tài)鏈接形式編譯。

　　不過(guò)使用uClibc代替并不是簡(jiǎn)單的設置一兩個(gè)參數就行了，通常需要使用一個(gè)不同的工具集(gcc/binutils等)來(lái)編譯代源碼。手工的構造這樣一個(gè)環(huán)境，對于大多數普通程序員來(lái)說(shuō)，不一定是一件很簡(jiǎn)單的事情，因此， uClibc的開(kāi)發(fā)者創(chuàng )造出一個(gè)叫做buildroot的工具集。 buildroot將自動(dòng)構造編譯基于uClibc代碼的工具集和uClibc庫，并提供一個(gè)可配置的框架和一些構建一個(gè)基本系統的配置文件。用戶(hù)只需要通過(guò)配置菜單選擇了相應的目標軟件，buildroot就可以從構建基本工具集開(kāi)始，一直到最后構建出目標系統所需要的東西，如嵌入式系統常用的基于 ext2的initrd，jffs根文件系統，壓縮的根目錄樹(shù)等，這些代碼都是基于uClibc而不是系統的Glibc的。Buildroot對主機系統的要求較小，通常只需要主機系統提供足以構建工具鏈(toolchain)的工具，如gcc/binutils等，當工具鏈編譯完成后，對目標系統需要的源碼的編譯過(guò)程與主機系統的開(kāi)發(fā)工具集基本上就沒(méi)有什么關(guān)系了。因此，不同的主機如果能夠通過(guò)第一步，編譯完成工具鏈，那么編譯出來(lái)的目標系統的執行代碼就可以幾乎不存在由于系統引起的差異。這樣，開(kāi)發(fā)人員就可能在各自喜歡的Linux發(fā)行版上進(jìn)行開(kāi)發(fā)，而不必擔心出現什么兼容性問(wèn)題。

　　◆ucLinux

　　uClinux與emDebian至少有兩個(gè)重要的區別，第一是構建方式，前面已經(jīng)提到過(guò)了，uClinux屬于 from scratch 一類(lèi)的。另一個(gè)不同的地方，uClinux是支持不在emDebian支持的11種CPU的，當然，這個(gè)說(shuō)法不是很恰當，正確的說(shuō)法是uClinux支持那些不具備MMU單元的CPU體系。uClinux的第一個(gè)目的是支持MC68328芯片，現在已經(jīng)能構支持更多的CPU，如Intel i960，ARM等。不過(guò)，uClinux的主體開(kāi)發(fā)團隊目前已經(jīng)不再支持ARM了，還好 Samsung 的 Hyok S. Choi 接過(guò)了接勵棒，Linux 2.6版本的補丁可以在 uClinux/ARM2.6 找到。

　　uClinux之前僅是核心的一些補丁，后來(lái)發(fā)展成為一個(gè)包括核心、庫、應用程序、工具和編譯相關(guān)的配置文件的一個(gè)集成開(kāi)發(fā)環(huán)境。與 buildroot不同的是，uClinux不編譯目標系統的工具集，也就是說(shuō)，相應的編譯工具應該提前安裝好。如，對于arm來(lái)說(shuō)，需要先安裝ARM交叉編譯器。uClinux的編譯器也需要一些補丁，其中比較重要的兩個(gè)方面主要包括：

　　用于生成FLT文件的補?。河捎贛MU的關(guān)系，uClinux不支持ELF可執行文件，這個(gè)補丁主要包括bin2flt工具包和一個(gè)ld的wrapper腳本等，用于(透明于用戶(hù))生成FLT文件;

　　用于支持XIP(Execute In Place)的補?。哼@個(gè)補丁需要對gcc進(jìn)行一些小的修改;支持XIP主要是為了解決小內存環(huán)境中運行的問(wèn)題。

　　XIP不一定適用于每種應用環(huán)境，對于內在要求特別嚴格的系統來(lái)說(shuō)(空間第一位，如手機要求使用片內RAM)，可以通過(guò)將核心和應用程序編譯為XIP支持，然后直接在Flash上運行，內存僅用于運行時(shí)數據;而對于性能要求為主的系統(如高速網(wǎng)絡(luò )處理器)，則不能因為節省一點(diǎn)空間而使用XIP將程序直接在Flash上運行，這樣可能會(huì )降低指令的讀取速度而影響系統性能(但仍然可以使用 XIP，使程序的多個(gè)實(shí)例在內存中共享代碼空間，以后詳細說(shuō)); + FLT可執行文件支持動(dòng)態(tài)鏈接庫(目前僅m68k支持，參見(jiàn) uCdot: Shared libraries under uClinux mini-HOWTO)的補丁;

　　uClinux的編譯過(guò)程大致是，首先，通過(guò)可視配置界面(menuconfig/xconfig)選取Vendor和board(實(shí)際上是選擇了一些配置文件和產(chǎn)品相關(guān)的文件)，然后根據選擇構造一個(gè)適用于target的開(kāi)發(fā)環(huán)境，如生成頭文件和需要的庫文件(uClibc、glibc或uC-libc 以及其它一些庫)，然后編譯核心、庫、應用程序，最后將所有的輸出安裝到romfs目錄中，根據需要生成目標平臺需要的映像文件(如： romfs.img、linux.bin、rootfs.gz等)

　　由于一些過(guò)程細節被隱藏起來(lái)，uClinux現在的編譯過(guò)程方便到只需要配置一下(make menuconfig)，然后 make 就可以直接獲得最終輸出。不過(guò)這反倒成為一些初學(xué)者學(xué)習的一個(gè)麻煩，本文完成后，根據對本文的反饋，將進(jìn)一步對uClinux進(jìn)行詳細介紹。

　　總的來(lái)說(shuō)，目前的uClinux是一套主要用于無(wú)MMU核(但不限于此)的嵌入式Linux集成環(huán)境，也是一個(gè)非常好的 Linux from scratch 的示例。拋開(kāi)其MMU相關(guān)的補丁，uClinux也可以作為一套用于包含MMU系統的集成開(kāi)發(fā)環(huán)境，Snapgear 就是一個(gè)很好的例子。實(shí)際上，我們可以從官方的uClinux源碼就可以直接編譯一個(gè)支運行于X86的uClinux。

　　◆Scratchbox

　　Scratchbox 的故事要從buildroot講起(這不一定是scratchbox開(kāi)發(fā)者的故事，只是依據我個(gè)人的認識)。buildroot可以從頭開(kāi)始，先構造編譯器和基本開(kāi)發(fā)環(huán)境，然后根據用戶(hù)配配置構造一個(gè)適用于目標平臺的根文件系統。這個(gè)文件系統可以有許多用法，例如，做為initrd或通過(guò)NFS輸出給目標系統使用。為了減少交叉編譯軟件帶來(lái)的麻煩，可以配置buidroot創(chuàng )建一套目標系統的編譯環(huán)境(Gcc、binutils、lib等)，這樣用戶(hù)可以通過(guò)這個(gè)基本文系統在目標系統上直接本地編譯軟件。如果目標系統性能足夠的話(huà)，buildroot的任務(wù)到此就基本結束了。對于嵌入式系統的開(kāi)發(fā)者來(lái)說(shuō)，在目標系統上直接編譯代碼卻不一定都能夠實(shí)現，因為多數情況下，我們的目標平臺處理器性能并不會(huì )那么高，這樣，我們就不得不面對一個(gè)兩難的選擇：

　　繼續通過(guò)buildroot編譯其它的軟件，性能會(huì )高許多，但每個(gè)軟件都需要進(jìn)行交叉編譯相關(guān)的改造;

　　在目標平臺上編譯軟件，對于只有幾十或幾百兆的低性能核來(lái)說(shuō)，編譯一個(gè)核心可能會(huì )讓你等上半天的時(shí)間;

　　有沒(méi)有好的辦法解決性能和交叉編譯的問(wèn)題呢?先分析一下通過(guò)buildroot交叉編譯不能解決的問(wèn)題。Buildroot只在一定程度上對目標平臺進(jìn)行了模擬，但仍有一些是無(wú)法實(shí)現的，例如，當目標平臺不同于主機平臺時(shí)，不能生成并運行目標平臺的中間代碼。這樣，許多通過(guò)autotools (autoconf/automake)配置的軟件就可能會(huì )出現問(wèn)題。例如，configure 腳本有時(shí)會(huì )生成一些中間代碼，并試圖運行以確認開(kāi)發(fā)環(huán)境中是否存在某個(gè)庫文件或頭文件，對于在X86上編譯基于uClibc X86目標平臺代碼可能不會(huì )出現問(wèn)題，但如果目標平臺是X86以外的平臺，編譯就可能會(huì )中斷;又如，configure腳本確認編譯器是否工作，會(huì )試圖編譯一個(gè)包含空的主程序的代碼并運行，實(shí)際一個(gè)可運行于目標平臺的 a.out 確實(shí)生成了，也可以正常運行于目標平臺，但是這個(gè)測試會(huì )因為 a.out 被運行在主機系統上而錯誤的中斷。這些問(wèn)題一些被 buildroot 通過(guò)補丁或復雜的 configure 參數解決了，某些中間執行文件，則通過(guò)HOSTCC(主機上的CC)來(lái)生成并運行以生成最終文件。目前buildroot包含的軟件或多或少都會(huì )有一些這樣的補丁，而且開(kāi)發(fā)者一旦深入到對軟件的定制，就會(huì )不停的被這些問(wèn)題所困擾。

　　Scratchbox相比于buildroot有幾方面的改進(jìn)：

　　運行于 chroot 的環(huán)境，完全獨立于主機，編譯過(guò)程將基本與主機系統無(wú)關(guān)(并且scratchbox修改了一些庫，使得普通用戶(hù)可以chroot到編譯環(huán)境中，并且多個(gè)用戶(hù)可以同時(shí)使用一套Scratchbox開(kāi)發(fā)套件和完全獨立的用戶(hù)資源);

　　透過(guò)qemu模擬運行或sbrsh解決中間執行文件或類(lèi)似configure測試文件運行的問(wèn)題;

　　對(chroot后)的系統進(jìn)行修定，達到足以欺騙大多數軟件的效果，這并不是指的讓軟件可以不進(jìn)行改造就可以 交叉 編譯，而是使軟件 誤認為 這就是在目標平臺上編譯;

　　不過(guò) Scratchbox 目前還只能編譯 ARM 和 x86 的代碼，不能支持 buildroot 所支持的 ppc、mips等。

　　本文不詳述每一種環(huán)境，因此各個(gè)軟件都只是點(diǎn)到為止(雖然可以講得更詳細一些，但這些內容還是獨立出來(lái)比較好一些)，不過(guò)這里還是引入一個(gè)很簡(jiǎn)單的示例，根據 scratchbox 網(wǎng)站上的文檔，安裝完成后，進(jìn)行簡(jiǎn)單配置就可以使用了(Debian用戶(hù)的安裝可以更簡(jiǎn)單，因為該站提供Deb包，直接apt-get就行了)。通過(guò) /scratchbox/login 登入開(kāi)發(fā)環(huán)境，通過(guò)sb-menu配置一個(gè)基于 ARM 的環(huán)境(其中 Select CPU-transparency method 選qemu不要先sbrsh)，然后寫(xiě)一個(gè) helloword.c，編譯并運行之。 通過(guò)ldd可以看到，在沒(méi)有任可改動(dòng)的情況下，順利的生成了ARM ELF，但在 scratchbox 里卻可以在X86的主機上正常的運行!