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

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

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

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

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

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

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

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

　　Scratchbox

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

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

　　在目標(biāo)平臺上編譯軟件，對于只有幾十或幾百兆的低性能核來說，編譯一個核心可能會讓你等上半天的時間;

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

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

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

　　透過qemu模擬運行或sbrsh解決中間執(zhí)行文件或類似configure測試文件運行的問題;

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

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

　　本文不詳述每一種環(huán)境，因此各個軟件都只是點到為止(雖然可以講得更詳細(xì)一些，但這些內(nèi)容還是獨立出來比較好一些)，不過這里還是引入一個很簡單的示例，根據(jù) scratchbox 網(wǎng)站上的文檔，安裝完成后，進(jìn)行簡單配置就可以使用了(Debian用戶的安裝可以更簡單，因為該站提供Deb包，直接apt-get就行了)。通過 /scratchbox/login 登入開發(fā)環(huán)境，通過sb-menu配置一個基于 ARM 的環(huán)境(其中 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: ~] >