Buildroot构建指南——工具链【转】

本文转载自：http://blog.csdn.net/zhou_chenz/article/details/52346134

Linux系统的交叉编译工具链用来将源代码变成bin文件或者库文件的一个软件。一般大家默认工具链等于gcc或者arm-linux-gcc，但是实际上，gcc只是工具链的编译器部分，不是全部，制作一个工具链的原材料，除了gcc，还需要linux内核，libc库等一系列的软件包。所谓万事开头难，如何在Buildroot中使用自己的交叉编译工具链则是第一道难关。

Buildroot支持从零开始用原材料软件包自动构造工具链，也支持直接使用第三方制作好的工具链。

toolchain-buildroot 从零开始自动制作工具链

在make menuconfig –> Toolchain –>Toolchain type中，有2个选项，选择buildroot toolchain则是使用buildroot默认的自动化脚本从零开始制作交叉编译工具链，如果是选择externaltoolchain 则是使用外部制作好的工具链。

Figure 1  toolchain type 选项

在mini2440_defconfig的配置文件中，我们可以看到，它并没有toochain相关的选项，只是在cpu指令集部分选择了ARM920T  ，这种情况它会采用buildroot-toolchain也就是buildroot默认的自动化脚本，从零开始制作工具链。实际上，你只要make toolchain然后等待几分钟，Buildroot就会将制作好的全新工具链放到output/host/目录下了。

Figure 2 mini2440_defconfig配置部分截图

      整个工具链自动化制作过程可以参考toolchain/ 目录下的toolchain-buildroot/ 、toolchain.mk、helpers.mk、toolchain-wrapper.mk等几个脚本，我就不详细说了。但是有几个关键点我还是强在下面列一下。总之制作过程还是很复杂的，所以如果是初学者，用手工方法从零开始做交叉编译工具链，将是多大的挑战。

a).  从图3中我们可以看到制作交叉工具链大概需要的原材料软件包

Figure3 制作交叉工具链的原材料

工具链主要的原材料包括：gcc,、libc库,、linux内核头文件、binutils以及一系列自动构建打包工具如m4、gmp、mpc等。

另外要强调的是，从工具链的原材料可以知道为什么Linux内核、驱动以及应用软件要用同一个工具链编译，为什么内核版本要适配它的工具链。这是因为工具链本身的制作依赖于特定版本的Linux内核和libc库。

b). 从图1的makemenuconfig –> Toolchain这一系列选项可以看到，制作工具链还可以选择libc库(uclibc还是glibc，自己添加Android特有的Bionic libc)，不同的libc性能，size，效率，稳定性以及GPL协议支持上有着一定的差异，需要使用者谨慎选择和测试。mini2440直接采用buildroot提供的默认的uclibc，不保证其稳定性和bug。

另外，toolchain后面还有Linux内核版本以及MMUsupport以及gcc版本的选择，可见如果需要定制特定的Linux内核(比如不带MMU的实时版)，除了移植内核之外，还需要特别为其定制工具链。

c). make menuconfig –> Target option 中的选项也是与交叉工具链密切相关的。

其中芯片的CPU的大小端，是否编译成elf格式，指令集，ABI的类型(EABI是Embeded ABI的意思，EABIHF是采用硬浮点的ABI)，以及软硬浮点特性(软浮点不会有编译兼容性问题，但是在支持硬浮点的高级嵌入式芯片，采用软浮点配置，很多性能会发挥不佳，但是ARM9这种低端平台用软浮点应该OK)等等选项，都是应该考虑的点。

 

Figure4 与交叉工具链相关的target option选项

toolchain-external 使用第三方现成工具链

这节用友善的Tiny4412开发板官方提供的工具链为例，介绍如何将外部第三方工具链移植到到Buildroot的编译环境。Tiny4412开发板用的SOC芯片的基于ARM-Cortex-A9内核的三星Exyons-4412 真四核SOC芯片，曾经是三星旗舰手机Galaxy-S3的主打SOC。

从友善官方提供的交叉编译工具链的包命名来看，工具链使用的gcc版本是4.5.1，有vfp则说明工具链支持应付点编译。V6应该是指令集是ARMV6，但是ARM-V6实际上是ARM11的指令集，Cortex-A9的应该是ArmV7才对， 这里应该是命名出错了，算是一个小漏洞吧。

Figure5  友善官方提供的tiny4412交叉编译工具链

移植步骤如下：

1.      为了不产生命名误导，我们将工具链的压缩包中4.5.1/* 目录下的所以内容拷贝出来，放到一个叫toolchain-tiny4412重新压缩成名字为arm-linux-gcc-4.5.1-tiny4412.tar.bz2的压缩包，将其cp到/mnt/sdb/3rd-pkg目录下，细心的朋友已经发现，根据前面一篇Buildroot快速入门的内容，这个文件夹是我保存第三方软件包的专门文件夹，待会Buildroot会用file的方法从该文件夹中把工具链cp到buildroot/dl/目录下的。

Figure6 保存在/mnt/sdb/3rd-pkg 目录下的工具链压缩包

2.      在make menuconfig –> Toolchain –>Toolchain type中选中external toolchain，下面的Toolchain栏中的arm-linux-gcc-4.5.1for tiny4412选项，实际上原本是没有的，是我自己加上去的。

Figure7 Toolchain的选择

3.      那么如何把自己的工具链加上去呢？cd buildroot/toolchain/toolchain-external/文件夹，根据前一篇文章快速上手的经验，要加自己的工具链，肯定是该配置，再改mk文件啦！

在该目录的Config.in文件的108行，有一个现成的第三方ARM cortex-A9 第三方交叉工具链的配置代码。

Figure8  buildroot/toolchain/toolchain-external/Config.in中的ARM Cortex-A9现成参考配置

我们可以参考模仿这段代码，稍微修改，在这段代码后面加入我们自己的配置代码：

注意，命名很重要，变量名一定是BR2_TOOLCHAIN_EXTERNAL_开头，后面加上自己的工具链名。

Figure9 Config.in中参考修改的tiny4412工具链配置代码

在我的修改中，出来提示字符串和help部分的相关注释和提示文字，主要是把主机gcc版本的最低要求降低到4.5，再去掉了内核头文件最低版本限制(这里其实是友善官方的疏忽，友善在制作工具链的时候，采用的Linux内核头文件版本很低，和编译的内核版本不匹配，导致头文件版本检查会报错，因而我去掉了最低版本的限制，这也是潜在漏洞之一吧)。

4.      配置交叉工具链前缀名。在Config.in的690行左右，为刚才添加的BR2_TOOLCHAIN_EXTERNAL_TINY4412_ARM选择工具链前缀名。

前缀名的格式组成是这样的：目标cpu-厂商-操作系统-库和abi格式，我们参考之前模仿的配置，选择arm-nonelinux-gnueabi，

实际上，友善官方给的工具链就是以arm-nonelinux-gnueabi作为前缀命名的。

Figure10  工具链前缀名配置

Figure11 tiny4412官方的工具链命名

5.      修改toolchain-external.mk 文件，加入自己配置。在296行，仿照前面一个工具链的变量配置，为BR2_TOOLCHAIN_EXTERNAL_TINY4412_ARM的配置增加下载地址和压缩包的名字，压缩包名字在第一步已经做好。至于下载地址，直接抄过来就行了，友善提供的定制化工具链，网上下载不到的。

Figure12 为toolchain-external.mk 加入tiny4412工具链的配置

事实上，打开那个地址，我们可以看到由sourcery官方维护的很多现成制作好的工具链，所以嘛直接拿来用就好了，自己从零制作工具链多麻烦啊！当然这些工具链的稳定性还是需要自己测试一番。

Figure13 sourcery网上可下载的现成工具链

6.      在menuconfig中设置下载的镜像地址。这个和前一篇文章一样，将本地保存工具链的地址，按照格式，设置为file的镜像地址。实际上，Buildroot的下载脚本，默认的规定是优先去本地的file镜像地址找软件包，找不到之后，才会走git或者网站下载等其它方法。当然网上肯定是下载不到的，但是先从本地找到就OK，这也是第一步为什么要保存工具链压缩包到该地址的原因。

关于Buildroot下载软件包的顺序，可以参考package/pkg-download.mk的脚本，在214行可以看到，只有在本地file路径找不到了，才会采用配置的(PKG)_SITE_METHOD方法去获取软件包。

Figure14  工具链的下载镜像地址

Figure15 Buildroot自动下载脚本的下载过程

7.      menuconfig中的几项配置。修改完配置脚本和编译构建mk脚本后，还得在menuconfig中把修改的东西配置进去。

在target Option的配置中，注意上一节提到的几点。但是这里有几个新的选项需要注意

a). CPU架构选择的是Cortex-A9

b) vfp友善官方给的工具链是支持的，所以这里可以打开，这样就能支持硬浮点了

c) NEON SIMD是CPU支持的高性能多媒体引擎的功能，这是4412这种级别的多媒体处理器的杀手级功能，但是我们现在并不了解它的特性，也不知道友善的工具链在制作的有没有把该功能加上去，因而暂时不打开。但是专业的工程师要去了解这项功能，以便发挥SOC和CPU的潜能。

d). VFP硬浮点的版本，这一项由于友善的资料不明确，暂时选VFPv3-D16版本，根据说明，Coretex-A9对这个版本都会支持的。

e). ABI的问题，根据图11的内容，友善的工具链应该只是用了EABI来做的，没有用EABIhf。这几项是什么意思呢？浮点选项其实有软浮点、硬浮点EABI(softfp)和硬浮点EABIhf三个。

软浮点就是用软件模拟浮点运算

硬浮点EABI就是用浮点指令，但是为了兼容旧版本的软浮点编译出来的库还是用整数寄存器传递浮点数，这样牺牲了一些效率，但是在工具链中存在旧的软浮点库时，是可以兼容并不会出现编译错误的。

硬浮点EABIhf则是使用纯粹的硬浮点指令和浮点寄存器来计算浮点数，这样效率会更高，但是不再兼容工具链中旧版的软浮点下编译出来的库，如果不重新制作硬浮点EABIhf的工具链，可能会出现编译问题。

EABIhf需要知道整个工具链的库的兼容特性，目前看起来友善官方工具链不支持这个选项，其工具链命名也是EABI，但是有支持vfp,因而我们选择硬浮点EABI的配置。具体要如何支持EABIhf，可以搜其它相关文章，这个可能需要重新制作整个工具链。

以上这些选项实际上都是编译toolchain-wrapper传递的，toolchain-wrapper是一个中间层，负责编译时，传递某些特定选项给工具链，以上这些选项确定后，都会被toolchain-wrapper以参数的时候在编译时传递给交叉工具链的。

 

Figure 16 menuconfig -->target option的配置

 

Figure 17 menuconfig -->toolchain的配置

在加入了tiny4412的配置后，最后在toolchani中选择自己的工具链，选上MMU功能，然后用pipe选项进行编译加速。

最后，make toolchain  ，你就可以看到Buildroot系统如何构建出tiny4412的工具链了。

小结

整体而言，从零制作一个工具链，对嵌入式的知识掌握还是需要深入的掌握，另外，工具链对整个系统代码的稳定性有着极大的影响，所以直接用自动制作的工具链，一定要经过严格的压力测试，否则容易出现各种隐患。

因而，采用第三方制作好的，有专门公司维护的工具链，应该是一个更为有效的开发方式。

转载于:https://www.cnblogs.com/zzb-Dream-90Time/p/7644051.html