做Linux嵌入式系統的對常見的幾種嵌入式開發環境一定不會默生，由于主要接觸網絡相關產品的一些系統設計，因此，將可能用到的嵌入式開發環境簡要總結一下。主要涉及下面的幾個東東：

　　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用于嵌入式系統的目的而開發。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 找到。