uclinux編譯工具

A. uclinux和linux的區別

Linux是一種很受歡迎的操作系統，它與UNIX系統兼容，開放源代碼。它原本被設計為桌面系統，現在廣內泛應容用於伺服器領域。而更大的影響在於它正逐漸的應用於嵌入式設備。uClinux正是在這種氛圍下產生的。在uClinux這個英文單詞中u表示Micro，小的意思，C表示Control，控制的意思，所以uClinux就是Micro-Control-Linux，字面上的理解就是"針對微控制領域而設計的Linux系統"。想了解Linux命令可參考下圖：

B. 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/.

C. 如何配置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的代碼寫的確實不太規范。當然它的性能確實沒話說。有興趣的可以試一下。

D. uclinux內核編譯問題

在Ubuntu 下輸入 apt-get install ncurses
Redhat下輸入 rpm -ivh ncurses
這個問題應該是在輸入make menucongfig時候出現的，內核啟動文本配置，需要
ncurses庫

E. 如何使uClinux根目錄使用jffs2分區

一、系統介紹
1． 採用加補丁方式的uClinux內核，不是uClinux-dist結構的。原始linux 2.4.22
2． Flash 地址0x46000000 ---- (0x46800000-0x1)
3． 192K 存放loader所以映像燒寫起始 0x46030000
4． 832K 存放內核 0x46030000----(0x46100000-0x1)
5．
二、打開jffs2支持
File systems --->
<*> Journalling Flash File System (JFFS) support
(0) JFFS debugging verbosity (0 = quiet, 3 = noisy)
<*> JFFS stats available in /proc filesystem
<*> Journalling Flash File System v2 (JFFS2) support
(0) JFFS2 debugging verbosity (0 = quiet, 2 = noisy)

Memory Technology Devices (MTD) --->
<*> Memory Technology Device (MTD) support
<*> MTD partitioning support
<*> Direct char device access to MTD devices
<*> Caching block device access to MTD devices

RAM/ROM/Flash chip drivers --->
<*> Detect flash chips by Common Flash Interface (CFI) probe
<*> Support for AMD/Fujitsu flash chips
三、分區說明
文件：driver/mtd/maps/xxxxx_map.c 有(不同的廠商或flash會有不同的map文件)
static struct mtd_partition xxxxmap_partitions[] = {
XXXXX_MTD_PARTITIONS
} 結構對應分區
宏XXXXX_MTD_PARTITIONS對應在 (有一些是不用宏直接寫在結構里也一樣)
include/asm-arm/arch-xxxxx/board-xxxxx/mtdpartitions.h 文件中
測試時分了一個區8M的最後2M。分區如下
{ /* 2MB:test */ /
name: "test jffs2", / /*分區名稱，啟動時候會顯示*/
size: 0x200000, / /*分區大小兩兆*/
offset: 0x600000, / /*6M處開始*/
mask_flags: 0, / /*0表示讀寫*/
}
編譯後在系統中會產生/dev/mtdblock/0 和 /dev/mtdblock/1；/dev/mtdblock/1就是對應該分區。
註：我用的版本會自動產生設備文件，它使用一個所謂的devfs，比我以前用過要在Makefile中添加設備節點的方便多了。
四、用最簡單的方法進行測試
1． 格式化
在開發系統中新建jffs2目錄隨便放個文件
mkfs.jffs2 -d ./jffs2 -o jffs2.img –l –U (mkfs.jffs2 可在mtd包的util目錄中編譯生成)
編譯好帶網路的映像，寫入，啟動，映射好nfs。在uClinux中運行
cat ./jffs2.img > /dev/mtdblock/2 （格式化前一定要使用bootloader erase該分區）
2． 使用
mount -t jffs2 /dev/mtdblock/1 /mnt
進入/mnt 目錄測試一下
五、根目錄使用jffs2分區
1． 方案說明
內核映像還是放在romfs文件系統中，一般bootloader僅僅支持romfs的啟動。Root文件系統製作成jffs2的映像。連接到romfs下面。最後進行整體燒入。
2． 8Mflash具體分區
{ /* 7104KB read/write */ / /*root 文件系統*/
name: "Root fs", /
size: 0x6f0000, /
offset:0x100000, /
mask_flags: 0, /
}, /
{ /* 64KB read/write */ / /*分1塊其他用途*/
name: "User", /
size: 0x10000, /
offset: 0x7f0000, /
mask_flags: 0, /
}, /
#if 0 //可以分出來，但最好不要，沒有用處，裡面的內容也不是jffs2結構
//前面1M是laoder和內核
{ /* 192KB readonly: bootloader */ /
name: "BootROM", /
size: 0x20000, /
offset: 0x0, /
mask_flags: 0, /* Not writable */ /
}, /
{ /* 832KB: kernel*/ /
name: "Kernel", /
size: 0xe0000, /
offset: 0x20000, /
mask_flags: 0, /
}
#endif
這樣/dev/mtdblock/1就是root分區了
3． 關於啟動命令行do_mounts.c::__setup
General Setup --- >
[*] Compiled – in Kernel Boot Parameter
Default kernel command string : 「root=/dev/mtdblock1 rw」

該配置產生的結果保存在include/linux/autoconf.h 中
注意 root=/dev/mtdblock1 rw，1的前面的 / 是沒有的。在程序中do_mounts.c
static int __init root_dev_setup(char *line) 中把/dev/mtdblock1轉化成 kdev_t ROOT_DEV; 來保存rootfs設備主從設備號。加了/後解析從設備號就出錯，默認為 0 了，導致mount錯誤。
加了 rw ,__setup("rw", readwrite) 語句會調用static int __init readwrite(char *str) 函數，把root_mountflags 設置成可寫。相關函數mount_block_root("/dev/root", root_mountflags) （在調用之前 "/dev/root" 被映射到mtd設備了）
4． 關於blkmem
Block devices --- >

< > Rom dis memory block device (blkmem)
[ ] Per partition statistics in /proc/partitions
blkmem去掉，否則在blkmem模塊載入的時候會修改全局變數ROOT_DEV，到運行mount_block_root 使已經不是對應的mtd設備了。具體見blkmem.c : int __init blkmem_init( void ) 函數的最後幾行。
5． 關於jffs
File systems--- >

< > Journalling Flash File System (JFFS) support

去掉 jffs的支持，我使用的時候不知道為什麼 jffs 會mount jffs2格式成功，但最後肯定是不能用的。mount_block_root 函數中會循環系統中所有支持的文件系統去 mount root分區。找到mount成功就停止循環。去掉後就不會循環到 jffs系統了，先用ext2試了一下失敗，就是用jffs2載入了。
6． 映像文件的製作
下面列舉我的製作腳本（在 make romfs 後運行）
#製作一個romfs目錄僅僅存放一個linux.bin.gz文件的內核文件系統
cd /home/hge/armutils_xxxxx
rm -rf ./build_arm/romfs
mkdir -p ./build_arm/romfs
cp 「內核根目錄下的linux.bin」 ./build_arm/romfs/linux.bin
gzip -f ./build_arm/romfs/linux.bin

#romfs 製作內核文件系統映像並使文件固定為823K即flash存放內核的大小
genromfs -f ./bin/hge-romfs-linux.bin -V mambo -d ./build_arm/romfs
cat ./bin/hge-romfs-linux.bin /dev/zero | dd of=./bin/hge-romfs-fixsize.bin bs=1024 count=64 bs=1024 count=832

#在內核文件系統映像的前後各加上64K空白
#所以romfs其實是從第二個64K塊開始，而jffs2則從對應分區的第三個塊開始
#內核實際數據是不能大於823 – 64 = 768K，root分區很大少128K影響不大
#例子是這樣，否則可能出現很多錯誤信息，但好像還是可以使用
dd if=/dev/zero of=./bin/64KB_blank bs=1024 count=64
cat ./bin/64KB_blank ./bin/hge-romfs-fixsize.bin ./bin/64KB_blank > ./bin/hge-romfs-rootfs.bin

#rootfs 製作jffs2 格式的root 文件系統
rm -rf ./build_arm/romfs
mkdir -p ./build_arm/romfs
cp -Rdf ./build_arm/root/* ./build_arm/romfs
/home/hge/mkfs.jffs2 -d ./build_arm/romfs/ -o ./bin/hge-rootfs-jffs.img -l -U

#romfs+rootfs 兩個文件連接起來
cat ./bin/hge-rootfs-jffs.img >> ./bin/hge-romfs-rootfs.bin

#gzip
gzip -fc ./bin/hge-romfs-rootfs.bin > ./bin/hge-romfs-rootfs.bin.gz

#uuencode
uuencode ./bin/hge-romfs-rootfs.bin.gz x.gz > ./bin/hge-romfs-rootfs.bin.gz.uue

最後 hge-romfs-rootfs.bin.gz.uue 用來燒寫
7． 燒寫注意
必須把jffs2 文件系統對應的flash 全部擦除後再進行燒寫，否則那些多餘的數據也會被當作文件系統的數據導致CRC錯誤。
boot> flash erase 0x46030000 0x467d0000
8．
六、其他
在內核啟動mount文件系統前會運行一個 linux-2.4.22-XX/init/main.c : init 函數，在函數中有prepare_namespace 函數就是整個文件系統的初始化了。

F. UC/OS與Linux操作系統的區別

uc/os比較簡單一點，開始學的uc/os，感覺沒意思了就開始學linux,感覺ucos只是在單片機上跑跑，像arm9的一般是跑linux。其實先學哪個都差不多，因為學習方法大不相同，差別太大了，ucos太簡單，就一些信號量，郵箱什麼的，懂了也就會了，linux有點難，涉及知識太多，光是涉及內核以外的編程就需要大把大把的經典書籍去看。興趣很重要，都靠興趣過來的。