『壹』 arm-linux-gcc 和 arm-elf-gcc 的區別
在基於ARM的嵌入式系統開發中，常常用到交叉編譯的GCC工具鏈有兩種：
arm-linux-*和 arm-elf-*，兩者區別主要在於使用不同的C庫文件。arm-linux-*使用
GNU的Glibc，而arm-elf-*一般使用 uClibc/uC-libc或者使用REDHAT專門為嵌入式系統
的開發的C庫newlib.Glibc。uClibc/uC-libc以及 newlib都是C語言庫文件，只是所應
用的領域不同而已，Glibc是針對PC開發的，uClibc/uC-libc是與Glibc API兼容的小型
化C語言庫，實現了Glibc部分功能。
關於uClibc/uC-libc的說明，詳見如下：
There are two libc libraries commonly used with uClinux. uC-libc and
uClibc. They are quite different despite their similar names. Here is a
quick overview of how they are different.
uC-libc is the original library for uClinux. It was based on sources
from the Linux-8086 C library which was part of the ELKs project with m68000
support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete
libc implementation, however, some of the API's are a little non-standard
and quite a few common libc routines are not present. Currently it has
stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was
primary design goal is to be small and light weight. It does try to conform
to any standards, although its API tries to be compatible with most libcs,
it is not always exactly the same.
The uClinux distribution provides an environment that can compile using
either uC-libc or uClibc depending on your needs. For m68000 and Coldfire
platforms it is generally better to chose uC-libc as it supports shared
libraries and is the most commonly used libc for these CPUs. uClibc also
works quite well with almost all platforms supported by the distribution.
Which libc you choose to use will be decided by your requirements
uClinux有兩個經常使用的libc庫：uC-libc和uClibc。雖然兩者名字很相似，其實有差
別，下面就簡單的介紹一下二者的不同之處。uC -libc是最早為uClinux開發的庫，是
Jeff Dionne和Kenneth Albanowski為在EKLs項目中支持m68000在Linux-8086 C庫源碼
上移植的。uC-libc是一個完全的libc實現，但其中有一些api是非標準的，有些libc的
標准也沒有實現。uC-libc穩定地支持 m68000，ColdFire和沒有MMU的ARM。其主要設計
目標是「小」、"輕"，並盡量與標准一致，雖然它的API和很多libc兼容，但是似乎並
不像它期望的那樣和所有標准一致。
uClibc就是為了解決這個問題從uC-libc中發展出來的。它的所有API都是標準的(正確
的返回類型，參數等等)，它彌補了uC-libc中沒有實現的libc標准，現在已經被移植到
多種架構中。一般來講，它盡量兼容glibc以便使應用程序用uClibc改寫變的容易。
uClibc能夠在標準的 VM linux和uClinux上面使用。為了應用程序的簡潔，它甚至可以
在許多支持MMU的平台上被編譯成共享庫。Erik Anderson在uClibc背後做了很多的工
作。uClibc支持許多系列的處理器：m68000，Coldfire，ARM，MIPS，v850， x86，
i960，Sparc，SuperH，Alpha，PowerPC和Hitachi 8。不斷增加的平台支持顯示uClibc
能夠很容易的適應新的架構。uClinux發行版提供了環境能夠讓你選擇使用uC-libc或是
uClibc編譯。對於m68000和Coldfire平台來說，選擇uC-libc還是稍微好一點，因為它
支持共享庫，而共享庫是這些cpu經常使用的 libc.uClibc也幾乎和所有的平台都能很
好的工作。選擇哪種libc取決於你的需求。
newlib 是一個用於嵌入式系統的開放源代碼的C語言程序庫，由libc和libm兩個庫組
成，特點是輕量級，速度快，可移植到很多CPU結構上。newlib實現了許多復雜的功
能，包括字元串支持，浮點運算，內存分配(如malloc)和I/O流函數(printf，fprinf()
等等)。其中libc提供了c 語言庫的實現，而libm提供了浮點運算支持。
在為ARM交叉編譯gcc編譯器時，對gcc指定不同的配置選項時，使用的C語言庫就不同，
gcc編譯器默認使用Glibc，也可以使用 uClibc/uC-libc(基本兼容Glibc API)，當使用
--with-newlib時，gcc編譯器不使用Glibc。當沒有交叉編譯Glibc時，可以使用
--with-newlib禁止連接Glibc而編譯bootstrap gcc編譯器。從gcc源目錄下的
config/arm中的t-linux和t-arm-elf中可以看出，不同的--target也影響gcc連接C語言
庫，t-linux(--target=arm-linux)默認使用Glibc，-arm-elf(--target=arm-elf)使用
- Dinhibit_libc禁止連接Glibc，這時我們就可以使用newlib等其他C語言庫編譯GCC工
具鏈。
雖然GCC工具鏈配置了不同的的C語言庫，但由於這些C語言庫都可以用來支持GCC，它們
對核心數據的處理上不存在較大出入。因而arm-linux-* 和 arm-elf-*區別主要表現在
C語言庫的實現上，例如不同系統調用，不同的函數集實現，不同的ABI\啟動代碼以及
不同系統特性等微小的差別。
arm-linux-*和 arm-elf-*的使用沒有一個絕對的標准，排除不同庫實現的差異，gcc可
以編譯任何系統。arm-linux-*和 arm-elf-*都可以用來編譯裸機程序和操作系統，只
是在遵循下面的描述時系統程序顯得更加協調：
arm-linux-*針對運行linux的ARM機器，其依賴於指定的C語言庫Glibc，因為同樣使用
Glibc的linux而使得arm-linux-*在運行linux的ARM機器上編譯顯得更加和諧。
arm-elf-*則是一個獨立的編譯體系，不依賴於指定的C語言庫Glibc，可以使用newlib
等其他C語言庫，不要求操作系統支持，當其使用為嵌入式系統而設計的一些輕巧的C語
言庫時編譯裸機程序(沒有linux等大型操作系統的程序)，如監控程序，bootloader等
能使得系統程序更加小巧快捷。
Linaro prebuilt toolchain does support both hard and soft floating
point. You can get it from https://launchpad.net/linaro-toolchain-binaries/+milestone/2012.08 try: ./arm-linux-gnueabihf-gcc -print-multi-lib
The default configure is --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
To use soft floating, you need options: -marm -march=armv4t -mfloat-abi=soft.
In your case, please try to change -march=armv5 to "-march=armv4t"
If you want to change to configure to cortex-a8 and armv5. You need
* Change cortex-a9 to cortex-a8 in
samples/linaro-arm-linux-gnueabihf/crosstool.config
* Change armv4t to armv5 in
contrib/linaro/patches/gcc/linaro-4.7-2012.08/multilib.patch,
Then follow the instructions to rebuild the toolchain
(contrib/linaro/doc/README.txt)
BTW: crosstool-ng-linaro does not support multilib for eglibc. It uses
the prebuilt sysroot from Ubuntu Precise. If it does not work for you,
please use the latest crosstool-ng from http://crosstool-ng.org/.
『貳』 如何配置uClinux2.6內核使其支持jffs2格式的文件系統
目前flash的文件系統比較多，用的比較多的就是JFFS2文件系統。基於NOR flash上的JFFS2文件系統可以說算是比較成熟了，支持NAND flash的JFFS2也已經發布了。源代碼可以到http://www.linux-mtd.infradead.org上面下載。但是在我的測試過程中，在nand flash上掛接的JFFS2文件系統很不穩定，經常有CRC錯誤產生。特別是進行寫操作的時候，每次復位都會產生CRC錯誤，可以說支持NAND flash的JFFS2文件系統目前還不成熟。而YAFFS文件系統則是專門針對NAND flash的，源代碼可以到
http://www.aleph1.co.uk/yaffs/index.html上下載。在測試過程中穩定性能比JFFS2文件系統要穩定的多，而且mount分區的時間也比JFFS2文件系統少的多。用JFFS2 mount一個2m的文件系統大約需要1s。下面分別介紹在uclinux下面使用JFFS2和YAFFS文件系統。
1、JFFS2
到http://www.linux-mtd.infradead.org上面下載最新的MTD和JFFS2壓縮包。壓縮包裡面還有有關的內核補丁和一些MTD的相關工具。主要的補丁就是ilookup- 2.4.23.patch，因為最新的MTD驅動中要用到一個ilookup（）函數。打完補丁、更新了MTD驅動和JFFS2文件系統之後就開始寫自己 nand flash驅動了。如果不想把JFFS2作為根文件系統的話，還需要修改MTD_BLOCK_MAJOR。驅動可以參考裡面的例子，最簡單的就是參考 spia.c。
寫驅動主要工作是定義flash分區結構、定義flash讀寫地址、寫控制flash的**_hwcontrol()函數。具體的操作要看所用的nand flash的晶元資料。相對NOR flash來說驅動要簡單多了。:)
改完之後再配置
Memory Technology Devices(MTD)下
CONFIG_MTD=Y
CONFIG_MTD_DEBUG=Y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_PARTITIONS=Y
CONFIG_MTD_CHAR=Y
CONFIG_MTD_BLOCK=Y
NAND Flash Device Drivers下
CONFIG_MTD_NAND=Y
定義自己的驅動文件
File systems下
CONFIG_JFFS2_FS=Y
CONFIG_JFFS2_FS_DEBUG=2
CONFIG_JFFS2_FS_NAND=y /*這個是新加的*/
在uClinux v1.3.4 Configuration下
Flash Tools下
CONFIG_USER_MTDUTILS=Y
CONFIG_USER_MTDUTILS_ERASE=Y
CONFIG_USER_MTDUTILS_ERASEALL=Y
CONFIG_USER_MTDUTILS_MKFSJFFS2=Y
最後就是辛苦了調試工作了。:(MTD驅動調試完之後，就可以在上面掛接JFFS2文件系統了。參看flash分區情況：cat /proc/mtd，擦除分區:eraseall /dev/mtd*.例如把第一個分區mount到/mnt目錄下面：
先:eraseall /dev/mtd0
然後:mount -t jffs2 /dev/mtdblock0 /mnt
2、YAFFS
YAFFS意義為'yet another flash file system'，也是一個開源的文件系統。YAFFS是目前為止唯一一個專門為NAND flash設計的文件系統，具有很好的可移植性，能夠在linux，uclinux，和wince
下面運行。
在http://www.aleph1.co.uk/yaffs/index.html上下載源代碼。壓縮包裡面也包含YAFFS的說明文檔。YAFFS文件系統的源文件就devextras.h，yaffs_ecc.c， yaffs_ecc.h,yaffs_guts.c,yaffs_guts.h,yaffs_mtdif.h,yaffs_mtdif.c和 yportenv.h
另外需要配置的宏：CONFIG_YAFFS_FS 和CONFIG_YAFFS_MTD_ENABLED，就是配置在mtd上面掛接YAFFS，其它還有一些輔助配置需要時也可以配置。
在fs目錄下面建一個yaffs目錄，把以上說的文件考裡面去，新建一個makefile：
O_TARGET := yaffs.o
obj-y := yaffs_fs.o yaffs_guts.o yaffs_mtdif.o yaffs_ecc.o
obj-m := $(O_TARGET)
include $(TOPDIR)/Rules.make
接下來就是改fs目錄下面config.in和makefile，在配置YAFFS的時候，把YAFFS連接進去。
如果像前面一樣已經把NAND MTD驅動調好了，加YAFFS就很簡單了。因為YAFFS是自己做ECC校驗的，所以要把MTD驅動裡面的ECC去掉。在驅動裡面改成this->eccmode = NAND_ECC_NONE就可以了。
另外YAFFS是用mkyaffs來擦除flash，所以在mtd-utils中加上mkyaffs.c，一起編譯進去。
最後就是編譯了，呵呵。中間會有一些警告沒有關系的，就是寫沒有用的變數和函數，不過話說回來YAFFS的代碼寫的確實不太規范。當然它的性能確實沒話說。有興趣的可以試一下。
『叄』 如果我要把linux精簡,然後安裝在psp中,我需要學習哪些知識
如果直接往psp之類的手持設備中移植發行版 這個不現實
首先是內核的移植，將內核精簡並編寫需要的設備驅動，提出不需要的功能和設備驅動，然後用交叉編譯器編譯為手持設備cpu支持的2進制內核文件
這是第一步， 離系統還遠
第二步 移植glibc ,同樣是精簡 和指令集方面的移植，提供必須的程序運行庫
第三步 如果要求不高可以直接交叉編譯出一個shell 環境，以及必須的軟體包
第四步 解決系統引導和文件系統以及燒錄
以上四步基本完成了一個基礎的可在手持設備上運行的linux
然後就是圖形界面的修改和移植方面的了, 接下來才能到移植ubuntu的方面，第一就是ubuntu的包管理的移植，第二就是ubuntu系統配置的移植，這裡面又牽涉到 perl python這兩個的精簡 ，因為大多腳本都是用這兩個寫的
按照順序需要的知識有
1，2步 對內核結構和glibc庫的了解和熟悉，以便於精簡 ， 極為熟練精通的c語言和匯編語言能力，設備訪問方式和設備驅動原理的熟練，可從源代碼級的刪減添加功能，並編寫相應功能，在以上基礎上對MIPS指令集的了解(PSP的處理器是MIPS類型的)以便於必須的移植代碼的編寫， 對gcc的了解和熟悉 ，出錯的地方快速的定位、修改，以及gcc編譯的優化
3,4步 主要就是gcc方面，如果需要精簡的話 前面的能力都能用的上，第四步上主要是bootloader的燒寫 ，jffs文件系統的創建等等
linux的移植方便，發行版級別的移植很麻煩
lz可以先製作一個LFS 體驗下linux系統的具體結構，然後就知道如何入手了