1. linux 內核 鏡像 工具 哪些 yocto
linux內核鏡像格式
一、Linux內核鏡像格式
Linux內核有多種格式的鏡像，包括vmlinux、Image、zImage、bzImage、uImage、xipImage、bootpImage等.
(1)kernel鏡像格式:vmlinux
vmlinuz是可引導的、可壓縮的內核鏡像，vm代表Virtual Memory.Linux支持虛擬內存，因此得名vm.它是由用戶對內核源碼編譯得到，實質是elf格式的文件.也就是說，vmlinux是編譯出來的最原始的內核文件，未壓縮.這種格式的鏡像文件多存放在PC機上.
【 attention】elf格式文件
ELF，Executable and Linkable Format，可執行可鏈接格式，是UNIX實驗室作為應用程序二進制介面而發布的，擴展名為elf.可以簡單的認為，在elf格式的文件中，除二進制代 碼外，還包括該可執行文件的某些信息，比如符號表等.
(2)kernel鏡像格式:Image
Image是經過obj處理的只包含二進制數據的內核代碼，它已經不是elf格式了，但這種格式的內核鏡像還沒有經過壓縮.
【 attention】obj
GNU使用工具程序obj作用是拷貝一個目標文件的內容到另一個目標文件中，也就是說，可以將一種格式的目標文件轉換成另一種格式的目標文件. 通過使用binary作為輸出目標(-o binary)，可產生一個原始的二進制文件，實質上是將所有的符號和重定位信息都將被拋棄，只剩下二進制數據.
(3)kernel鏡像格式:zImage
zImage是ARM linux常用的一種壓縮鏡像文件，它是由vmlinux加上解壓代碼經gzip壓縮而成，命令格式是#make zImage.這種格式的Linux鏡像文件多存放在NAND上.
(4)kernel鏡像格式:bzImage
bz表示big zImage,其格式與zImage類似，但採用了不同的壓縮演算法，注意，bzImage的壓縮率更高.
(5)kernel鏡像格式:uImage
uImage是uboot專用的鏡像文件，它是在zImage之前加上一個長度為0x40的頭信息(tag)，在頭信息內說明了該鏡像文件的類型、載入 位置、生成時間、大小等信息.換句話說，若直接從uImage的0x40位置開始執行，則zImage和uImage沒有任何區別.命令格式是#make uImage.這種格式的Linux鏡像文件多存放在NAND上.
(6)kernel鏡像格式:xipImage
這種格式的Linux鏡像文件多存放在NorFlash上，且運行時不需要拷貝到內存SDRAM中，可以直接在NorFlash中運行.
二、Linux內核鏡像的產生過程
在嵌入式Linux中，內核的啟動過程分為兩個階段.其中，第一階段啟動代碼放在arch/arm/kernel/head.S文件中，該文件與體系 結果相關，與用戶的開發板無關，主要是初始化ARM內核等.第二階段啟動代碼是init目錄下的main.c.現以執行命令#make zImage為例來說明，arm-linux內核鏡像的產生過程.
(1)當用戶對Linux內核源碼進行編譯時，kernel的第1/2階段代碼會生成可執行文件vmlinux，該文件是未被壓縮的鏡像文件，非常大，不能直接下載到NAND中，通常放在PC機上，這也是最原始的Linux鏡像文件.試驗時該文件約50M.
(2)鏡像文件vmlinux由於很大，肯定不能直接燒入NAND中，因此需要進行二進制化，即經過obj處理，使之只包含二進制數據的內核代 碼，去除不需要的文件信息等，這樣就製作成了image鏡像文件.該鏡像文件也是未壓縮，只是經過了二進制化而變小.試驗時該文件約5M.
(3) 一般來說，內存SDRAM中的內核鏡像是經過壓縮的，只是在運行時再將其解壓.所以，編譯時會先使用gzip將鏡像文件image進行壓縮(壓縮比約為 2:1),再將壓縮後的鏡像文件和源碼中的兩個文件arch/arm/boot/compressed/head.S、arch/arm/boot /compressed/misc.c一起鏈接生成壓縮後的鏡像文件compress/vmlinux.試驗時該文件約為2.5M.注意，這兩個源碼文件 是解壓程序，用於將內存SDRAM中的壓縮鏡像zImage進行解壓.
(4)壓縮後的鏡像文件compress/vmlinux經過二進制化，最終生成鏡像文件zImage，試驗時該文件約為2.5M.當然，在內存 SDRAM中運行壓縮鏡像文件zImage時，會首先調用兩個解壓程序arch/arm /boot/compressed/head.S、arch/arm/boot/compressed/misc.c將自身解壓，然後再執行kernel 的第一階段啟動代碼arch/arm/kernel/head.S.簡而言之，在內存中運行內核時，kernel先自身解壓，再執行第一階段啟動代碼.試 驗時運行在內存中的鏡像文件約為5M，與image鏡像文件大小相同.
(
2. 如何安裝yocto
1.Yocto簡介：
Yocto 是一個開源社區，它通過提供模版、工具和方法幫助開發者創建基於linux內核的定製系統，支持ARM, PPC, MIPS, x86 (32 & 64 bit)硬體體系架構。
2.Yocto定製准備工作
（1）確保電腦能聯網，並且有100G的空閑，電腦配置不低於4核
（2）獲取yocto腳本：$git clone git://git.yoctoproject.org/poky
（3）獲取硬體相關層：$git clone git://git.yoctoproject.org/meta-intel.git
（4）關於yocto的幫助：http://www.yoctoproject.org/documentation
3.開始搭建環境
（1）$source poky/oe-init-build-env xxx
xxx$cd conf
xxx/conf$ vim bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"
BBFILES ?= ""
BBLAYERS ?= " \
/hda5/hmi/x86/yocto/poky/meta \
/hda5/hmi/x86/yocto/poky/meta-yocto \
/hda5/hmi/x86/yocto/poky/meta-intel \
/hda5/hmi/x86/yocto/poky/meta-intel/meta-crownbay \
（2）修改local.conf
xxx/conf$ vim local.conf
#MACHINE ??= "qemux86"
MACHINE ??= "crownbay"
4.開始編譯
註：(官方下載的只是腳本，yocto一邊下載一邊編譯所以很慢而且還受資源下載限制和電腦配置，下載的文件在工作目錄中的downloads中，第一次下載後保存好downloads以後就方便了)
（1）配置內核
xxx$ bitbake linux_yocto -c menuconfig
（2）定製微型yocto
xxx$ bitbake core-image-minimal
（3）定製桌面型yocto
xxx$ bitbake coure-image-sato
（4） hob config
xxx$ hob
可以在圖形化界面中方便的定製系統。
3. Yocto編譯傑發或MTK的linux或android時的幾個問題
編譯問題1（audiomanager_7.0.bb的do_configure報錯）：
錯誤：CMake Error at Plugins/PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:352 (message):
| Failed to generate files from FIDL:
手動執行一下：
$ commonapi-generator-linux-x86 -ll verbose -sk Default -d . /data/linux/hz_rs28_bm/sources/神燃build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/audiomanager/7.0-r1/audiomanager-7.0/Plugins/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl
-bash: /data/linux/hz_rs28_bm/sources/src/build/tools/commonapi_tool/commonapi-generator/commonapi-generator-linux-x86: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
解決（需要安裝32位的glibc庫和32位java jre環境）：
$ sudo yum install glibc.i686
$ sudo yum install java-1.8.0-openjdk.i686
$ sudo ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.i386/jre/bin/java /bin/java
$ java -version （保證是32位的java）
編譯問題2（perl_5.20.0.bb的do_package報錯）：
錯誤：ERROR: obj failed with exit code 256 (cmd was 『arm-poky-linux-gnueabi-obj』 –only-keep-debug
… generate_uudmap: File format not recognized
解決（tar在1.29版本之後需要exclude在路徑的前面）：
sources/meta/poky/bitbake/lib/bb/fetch2/bzr.py
tar_flags = 「–exclude 『.bzr』 –exclude 『.bzrtags'」
修改成：
tar_flags = 「–exclude=』.bzr』 –exclude=』.bzrtags'」
sources/meta/poky/bitbake/lib/bb/fetch2/cvs.py
tar_flags = 「–exclude 『CVS'」
修改成：
tar_flags = 「–exclude=』CVS'」
sources/meta/poky/bitbake/游輪虛lib/bb/fetch2/repo.py
tar_flags = 「–exclude 『.repo』 –exclude 『.git'」
修改成：
tar_flags = 「–exclude=』.repo』 –exclude=』.git'」
sources/meta/poky/bitbake/lib/bb/fetch2/svn.py
tar_flags = 「–exclude 『桐顫.svn'」
修改成：
tar_flags = 「–exclude=』.svn'」
sources/meta/poky/meta/recipes-devtools/quilt/quilt-0.63.inc
tar -cf – bin/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – compat/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – quilt/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -cf – test/ –exclude mail.test –exclude delete.test | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=\*.in bin/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=\*.in compat/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=\*.in quilt/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
tar -c –exclude=mail.test –exclude=delete.test test/ | ( cd ${D}${PTEST_PATH} && tar -xf – && chmod 777 test)
sources/meta/poky/meta/recipes-extended/sed/sed-4.2.2/sed-add-ptest.patch
+ cd $(BUILDDIR); tar -cf – $(TESTDIR) –exclude *.o | ( cd $(DESTDIR) && tar -xf – )
修改成：
+ cd $(BUILDDIR); tar -c –exclude=*.o $(TESTDIR) | ( cd $(DESTDIR) && tar -xf – )
sources/meta/poky/meta/recipes-support/attr/acl.inc
tar -cf – test/ –exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=nfs test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
sources/meta/poky/meta/recipes-support/attr/attr.inc
tar -cf – test/ –exclude ext | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=ext test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )
sources/meta/poky/meta/recipes-devtools/perl/perl-ptest.inc
tar -cf – * –exclude \*.o –exclude libperl.so –exclude Makefile –exclude makefile –exclude hostperl \
–exclude miniperl –exclude generate_uudmap –exclude patches | ( cd ${D}${PTEST_PATH} && tar -xf – )
修改成：
tar -c –exclude=\*.o –exclude=libperl.so –exclude=Makefile –exclude=makefile –exclude=hostperl \
–exclude=miniperl –exclude=generate_uudmap –exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )
編譯問題3（libunwind_1.1.bb的do_compile報錯）：
錯誤：make[1]: latex2man: Command not found
解決：
$ sudo yum install texlive-tetex
$ sudo rpm -ivh ~/latex2man-1.18-2.noarch.rpm
編譯問題3（qt5-app_1.0.bb的do_compile報錯）：
錯誤（有一批類似的錯誤）：ld: cannot find -lgtest
解決：
$ vi atc_linux/application/btate/btate.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L $(DA_LIBDIR)/lib -lgtest -lpthread -lbluetoothclient -lglobalbus -lappobj -lapputils
} else {
LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/atc-binarys/1.0-r0/image/usr/lib -lgtest -lpthread -lbluetoothclient -l
globalbus -lappobj -lapputils
}
$ vi atc_linux/application/gps/gps_bin.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L $(DA_LIBDIR)/lib -lapputils -lglobalbus -lappobj -lgps
} else {
LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -lapputils -lglobalbus -lappobj -lgps
}
$ vi atc_linux/application/dvr/dvr_bin.pro
equals(MY_BUILD_SYSTEM, atc) {
LIBS += -L${DA_TOP}/lib/lib/ -ldvr -ludev -lsurface_atc -lglobalbus -lappobj -lapputils -lstorage_atc -lgps
} else {
LIBS += -L${DA_TOP}/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -ldvr -ludev -lsurface_atc -lglobalbus –
lappobj -lapputils -lstorage_atc -lgps
}
$ vi atc_linux/application/dvr/dvr_bin.pro
INCLUDEPATH += ${DA_TOP}/kernel/kernel-3.18/drivers/ \
../common/ \
../utils/ \
../appobj/include/ \
../globalbus/include/ \
../appcommon/include/ \
../storage_atc/ \
../dvr/gps/ \
../gps/include/ \
../gps/includeex/ \
編譯問題4（makall報錯）：
報錯：./makall: line 169: mkisofs: command not found
解決：$ sudo yum install mkisofs
編譯問題5（修改ac83xx_systemd_defconfig再編譯時報錯）：
報錯：Applying patch remove-selinux-android.patch
patching file system/extras/ext4_utils/make_ext4fs.c
Hunk #1 FAILED at 62.
1 out of 1 hunk FAILED — rejects in file system/extras/ext4_utils/make_ext4fs.c
解決：
$ vi sources/meta/meta-atc/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb
在裡面做個假的do_patch()，bitbake會優先使用本bb文件的do_patch()函數。
do_patch(){
}
編譯問題6（修改ac83xx_systemd_defconfig再編譯時報錯）：
報錯：sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/qtbase/5.5.0+gitAUTOINC+c619d2daac-r0/git/src/corelib/tools/qregexp.cpp:3947:1: internal compiler error: in add_stores, at var-tracking.c:6000
解決：
$ cd sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9/
$ wget http://openlinux.windriver.com/overc/sources/core2_64/gcc-4.9.2-r0.1/0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch
$ vi sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9.inc
file://0058-gcc-r212171.patch \
file://0059-gcc-PR-rtl-optimization-63348.patch \
file://target-gcc-includedir.patch \
file://0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch \
其實就是這個文件：
$ cat 0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch
From Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= <[email protected]>
Date: Tue, 7 Apr 2015 16:15:11 +0200
Subject: [PATCH] gcc/var-tracking.c: backport from gcc trunk r212178
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
resolves a bug seen on cortexa8 building qt5 libraries.
2014-06-30 Joseph Myers <[email protected]>
* var-tracking.c (add_stores): Return instead of asserting if old
and new values for conditional store are the same.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4
Signed-off-by: Stefan Müller-Klieser <[email protected]>
---
gcc/var-tracking.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 65d8285..7c38910 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -5997,7 +5997,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)
{
cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode);
- gcc_assert (oval != v);
+ if (oval == v)
+ return;
gcc_assert (REG_P (oloc) || MEM_P (oloc));
if (oval && !cselib_preserved_value_p (oval))
--
1.9.1
編譯問題7（修改ac83xx_systemd_defconfig再編譯時報錯）：
報錯：libevdev/1.2.2-r0/libevdev-1.2.2/test/test-main.c:24:19: fatal error: check.h: No such file or directory
解決：
$ vi meta/poky/meta/recipes-support/libevdev/libevdev_1.2.2.bb
LIC_FILES_CHKSUM = 「file://COPYING;md5= \
file://libevdev/libevdev.h;endline=21;md5=″
DEPENDS += 「libcheck」
SRC_URI = 「 http://www.freedesktop.org/software/libevdev/ ${BP}.tar.xz」
編譯問題8（修改ac83xx_systemd_defconfig再編譯時報錯）：
報錯：python報錯： 『do_rootfs』, lineno: 17, function
Exception: CalledProcessError: Command 『[『』, 『-ks』, …
解決： 沒有實際問題，重新編譯一次即可，可能是機器太忙導致超時，或者某個命令執行不成功。
編譯問題9（preuboot編譯工具問題）：
報錯：make: armv7a-mediatek451_001_vfp-linux-gnueabi-gcc: Command not found
解決：
$ vi atc_linux/bootloader/preuboot/Makefile
#CROSS_COMPILE :=armv7a-mediatek451_001_vfp-linux-gnueabi-
CROSS_COMPILE :=arm-poky-linux-gnueabi-
$ vi ../../atc_linux/bootloader/preuboot/driver/mmc/include/linux/list.h
#ifndef NULL
#define NULL 0
#endif
4. Linux嵌入式交叉編譯工具鏈問題 淺談
交叉編譯工具鏈是一個由編譯器、連接器和解釋器組成的綜合開發環境，交叉編譯工具鏈主要由binutils、gcc和glibc 3個部分組成。有時出於減小libc庫大小的考慮，也可以用別的c庫來代替glibc，例如uClibc、dietlibc和newlib。交叉編譯工具鏈主要包括針對目標系統的編譯器gcc、目標系統的二進制工具binutils、目標系統的標准c庫glibc和目標系統的Linux內核頭文件。第一個步驟就是確定目標平台。每個目標平台都有一個明確的格式，這些信息用於在構建過程中識別要使用的不同工具的正確版本。因此，當在一個特定目標機下運行GCC時，GCC便在目錄路徑中查找包含該目標規范的應用程序路徑。GNU的目標規范格式為CPU-PLATFORM-OS。例如，建立基於ARM平台的交叉工具鏈，目標平台名為arm-linux-gnu。
分步編譯和安裝交叉編譯工具鏈所需要的庫和源代碼，最終生成交叉編譯工具鏈。
通過Crosstool腳本工具來實現一次編譯生成交叉編譯工具鏈。
直接通過網上（ftp.arm.kernel.org.uk）下載已經製作好的交叉編譯工具鏈。
方法1相對比較困難，適合想深入學習構建交叉工具鏈的讀者。如果只是想使用交叉工具鏈，建議使用方法2或方法3構建交叉工具鏈。方法3的優點不用多說，當然是簡單省事，但與此同時該方法有一定的弊端就是局限性太大，因為畢竟是別人構建好的，也就是固定的沒有靈活性，所以構建所用的庫以及編譯器的版本也許並不適合你要編譯的程序，同時也許會在使用時出現許多莫名的錯誤，建議你慎用此方法。
方法1：分步構建交叉編譯工具鏈
下載所需的源代碼包
建立工作目錄
建立環境變數
編譯、安裝Binutils
獲取內核頭文件
編譯gcc的輔助編譯器
編譯生成glibc庫
編譯生成完整的gcc
由於在問答中的篇幅，我不能細述具體的步驟，興趣的同學請自行閱讀開源共創協議的《Linux from scratch》，網址是：linuxfromscratch dot org
。
Crosstool是一組腳本工具集，可構建和測試不同版本的gcc和glibc，用於那些支持glibc的體系結構。它也是一個開源項目，下載地址是kegel dot com/crosstool。用Crosstool構建交叉工具鏈要比上述的分步編譯容易得多，並且也方便許多，對於僅僅為了工作需要構建交叉編譯工具鏈的你，建議使用此方法。
運行which makeinfo，如果不能找見該命令，在解壓texinfo-4.11.tar.bz2，進入texinfo-4.11目錄，執行./configure&&make&&make install完成makeinfo工具的安裝
下載所需資源文件linux-2.4.20.tar.gz、binutils-2.19.tar.bz2、gcc-3.3.6.tar.gz、glibc- 2.3.2.tar.gz、glibc-linuxthreads-2.3.2.tar.gz和gdb-6.5.tar.bz2。然後將這些工具包文件放在新建的$HOME/downloads目錄下，最後在$HOME/目錄下解壓crosstool-0.43.tar.gz，命
令如下：
#cd$HOME/
#tar–xvzfcrosstool-0.43.tar.gz
建立腳本文件
接著需要建立自己的編譯腳本，起名為arm.sh，為了簡化編寫arm.sh，尋找一個最接近的腳本文件demo-arm.sh作為模板，然後將該腳本的內容復制到arm.sh，修改arm.sh腳本，具體操作如下：
# cd crosstool-0.43
# cp demo-arm.sh arm.sh
# vi arm.sh
修改後的arm.sh腳本內容如下：
#!/bin/sh
set-ex
TARBALLS_DIR=$HOME/downloads#定義工具鏈源碼所存放位置。
RESULT_TOP=$HOME/arm-bin#定義工具鏈的安裝目錄
exportTARBALLS_DIRRESULT_TOP
GCC_LANGUAGES="c,c++"#定義支持C,C++語言
exportGCC_LANGUAGES
#創建/opt/crosstool目錄
mkdir-p$RESULT_TOP
#編譯工具鏈，該過程需要數小時完成。
eval'catarm.datgcc-3.3.6-glibc-2.3.2.dat'shall.sh--notest
echoDone.
在arm.sh腳本文件中需要注意arm-xscale.dat和gcc-3.3.6-glibc-2.3.2.dat兩個文件，這兩個文件是作為Crosstool的編譯的配置文件。其中arm.dat文件內容如下，主要用於定義配置文件、定義生成編譯工具鏈的名稱以及定義編譯選項等。
KERNELCONFIG='pwd'/arm.config#內核的配置
TARGET=arm-linux#編譯生成的工具鏈名稱
TARGET_CFLAGS="-O"#編譯選項
gcc-3.3.6-glibc-2.3.2.dat文件內容如下，該文件主要定義編譯過程中所需要的庫以及它定義的版本，如果在編譯過程中發現有些庫不存在時，Crosstool會自動在相關網站上下載，該工具在這點上相對比較智能，也非常有用。
BINUTILS_DIR=binutils-2.19
GCC_DIR=gcc-3.3.6
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.6.10-8(根據實際情況填寫)
GDB_DIR=gdb-6.5
執行腳本
將Crosstool的腳本文件和配置文件准備好之後，開始執行arm.sh腳本來編譯交叉編譯工具。具體執行命令如下：
#cdcrosstool-0.43
#./arm.sh
經過數小時的漫長編譯之後，會在/opt/crosstool目錄下生成新的交叉編譯工具，其中包括以下內容：
arm-linux-addr2linearm-linux-g++arm-linux-ldarm-linux-size
arm-linux-ararm-linux-gccarm-linux-nmarm-linux-strings
arm-linux-asarm-linux-gcc-3.3.6arm-linux-objarm-linux-strip
arm-linux-c++arm-linux-gccbugarm-linux-objmpfix-embedded-paths
arm-linux-c++filtarm-linux-gcovarm-linux-ranlib
arm-linux-cpparm-linux-gprofarm-linux-readelf
然後將生成的編譯工具鏈路徑添加到環境變數PATH上去，添加的方法是在系統/etc/ bashrc文件的最後添加下面一行，在bashrc文件中添加環境變數
export PATH=/home/jiabing/gcc-3.3.6-glibc-2.3.2/arm-linux-bin/bin:$PATH
至此，arm-linux下的交叉編譯工具鏈已經完成，現在就可以使用arm-linux-gcc來生成試驗箱上的程序了！