Linux Kernel（24）
U-boot（25）
转自 ：http://blog.csdn.net/youyudehexie/article/details/7583657
Buildroot简介
Buildroot就是一个自动化生成交叉编译工具的工具，记得当年我搭建自己的ARM交叉编译器的时候，花了很大力气和时间，最好因为各种错误而无奈放弃了，最后还是用别人的交叉编译器，不曾想到有这么有个好用的工具出现，它大大缩减了生成交叉编译器的难度，让嵌入式开发变得更加轻松，让精力花到刀刃上。除了提供自动生成的交叉编译工具外，他还提供了很多选项，例如应用软件的安装，例如vsftp,ssh等。这么好的工具，要一天写完，比较困难，分开一点点弄吧。
官网：http://buildroot.uclibc.org/
说明文档：http://buildroot.uclibc.org/downloads/buildroot.html
下载Buildroot：http://buildroot.net/downloads/
安装Buildroot与简单配置命令
菜单选项有很多，就不一一介绍了。需要关注的配置地方，主要是
Target Architecture
Target Architecture Variant
交叉编译工具的所采用的系统头文件版本。这些都需要根据自己目标板来配置。
配置完毕make后，编译完成。
PS:实在不会配置，可以参考buildroot根目录下的config文件夹，里面存放着arm,x86和MIPS等架构的经典配置，可以再这个基础上裁剪
Buildroot目录简介
就主要目录简单介绍一下
/dl 存放下载的源码包
/toolchain 放置编译交叉工具的配置文件与源代码
/fs/ 主要存放各种文件系统的源代码
/fs/skeleton 存放骨架，第一次生成文件系统镜像的地方
/linux linux源码存放地方
/configs 预先放置了一些开发板的配置参考，有arm，X86和MIPS等，还发现了我的入门开发板Mini2440，亮瞎眼了。。
/board 发现友善之臂的配置文件
/boot bootloader的一些配置，可以通过配置下载源码
/package 主要存放应用软件的配置文件，未来开发的主战场，可以通过配置其文件，增加源码包或者删减，利用 buildroot来实现交叉编译
/Output 编译的生成目录
/Output/images 编译生成镜像
/Output/build 编译的源码包，buildroot从dl的包解压缩到build里面，然后再编译
/Output/staging 这个目录非常重要，它提供了交叉编译依赖的库，一般进行make的时候，都会利用staging的库文件进行链接
/Output/target 嵌入式设备下的根文件系统，里面是我们实际烧写的根文件系统镜像
/Output/host 交叉编译工具位置如arm-linux-gc
/Output/toolchain 第三方交叉编译工具位置，我的目录是空的。
从目录发现buildroot，只要合理使用buildroot完全可以从bootloader开发到QT图像界面应用程序，笔者，手上的几块开发板也是使用buildroot来实现文件系统和应用软件服务的。已经快10点下班了，今天先这样。
Buildroot的执行流程
下载源代码文件配置，编译和安装交叉编译器，或者导入第三方的交叉编译器编译和安装所选择的源码包编译内核编译bootloader编译根文件系统并打包成相应镜像。
如何重新编译软件包
& & & & 经过第一次完整编译后，如果我们需要对源码包重新配置，我们不能直接在buildroot上的根目录下直接make，buildroot是不知道你已经对源码进行重新配置，它只会将第一次编译出来的文件，再次打包成根文件系统镜像文件。不过，我们可以通过以下两个方法修改源码的配置。
1. 直接删除源码包，例如我们要重新编译openssh，那么可以直接删除output/build/openssh-vesion 文件夹，那么当你make的时候，他就会自动从dl文件夹下，解压缩源码包，并重新安装
2. 也是以openssh为例子，如果我们不想重新编译，只想重新配置，也就是./configure，
我们可以直接删除 output/build/openssh-version 目录下的 .stamp_configured如果你只是想重新安装可以删除.stamp_target_install重新make可以删除.stamp_built
如何buildroot外面使用buildroot的交叉编译器
& & & & 交叉编译器的路径在Output/host目录下，你可以使用arm-linux-gcc ,arch-linux-objdump等等，虽然看上去非常美好的，但笔者时候的时候却是非常难受，因为当移植一个软件的时候，你需要编译的东西，可能不仅仅是一个源码包，这个软件可能需要到另外一个源码包的库，而这个源码包更可能需要其他的库，结果到最后，编译的包各种多，如果你对库依赖熟悉还好，不熟悉的情况，实在让人头痛，这种方法，笔者不太推荐，buildroot的优势有点类似在CentOS下的YUM，大部分的包，他都能够识别依赖，你需要的库，只要选上，基本编译就不成问题了，如果实在不行，你稍微制定路径就可以，路径一般在/output/host/usr/ARCH-unknown-linux-gnu/sysroot/usr下，这个目录相当于交叉编译的编译环境，他提供了很多库依赖，减轻了很多移植工作，buildroot的强大之处。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：46142次
排名：千里之外
转载：284篇
(7)(2)(10)(21)(57)(2)(8)(11)(9)(19)(30)(7)(14)(95)【基本解决】给diff生成的patch文件添加注释
期间，希望用diff生成的patch文件的最开始可以添加对应的注释内容，就像之前看到的：
D:\tmp\tmp_dev_root\cgwin\home\CLi\develop\buildroot\buildroot-2013.05\package\m4\m4-1.4.16-no-gets.patch
中的这样的效果：
Since the 2.16 release of the glibc, 'gets' is not any more defined in the gnulib.
No m4 version synchronized with gnulib since [1] has been released yet.
This patch avoids the following error occurs when building m4 &=1.4.16 on host using
a glibc &=2.16:
make[4]: Entering directory `/opt/buildroot/output/build/host-m4-1.4.16/lib'
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT gl_avltree_oset.o -MD -MP -MF .deps/gl_avltree_oset.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT c-ctype.o -MD -MP -MF .deps/c-ctype.Tpo -c -o c-ctype.o c-ctype.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT c-stack.o -MD -MP -MF .deps/c-stack.Tpo -c -o c-stack.o c-stack.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo -c -o clean-temp.o clean-temp.c
mv -f .deps/c-ctype.Tpo .deps/c-ctype.Po
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT close-hook.o -MD -MP -MF .deps/close-hook.Tpo -c -o close-hook.o close-hook.c
In file included from clean-temp.h:22:0,
from clean-temp.c:23:
./stdio.h:477:20: error 'gets' undeclared here (not in a function)
make[4]: *** [clean-temp.o] Error 1
References:
[1] http://git.savannah.gnu.org/gitweb/?p=gnulib.a=h=e93e5c518ebcc807348
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch?diff_format=h&revision=1.1&view=markup
Signed-off-by: Samuel Martin &s.&
diff -purN host-m4-1.4.16.orig/lib/stdio.in.h host-m4-1.4.16/lib/stdio.in.h
--- host-m4-1.4.16.orig/lib/stdio.in.h
19:11:40. +0200
+++ host-m4-1.4.16/lib/stdio.in.h
20:46:05. +0200
@@ -162,7 +162,9 @@ _GL_WARN_ON_USE (fflush, &fflush is not
so any use of gets warrants an unconditional warning.
Assume it is
always declared, since it is required by C89.
#undef gets
+#if defined(__GLIBC__) && !defined(__UCLIBC__) && !__GLIBC_PREREQ(2, 16)
_GL_WARN_ON_USE (gets, &gets is a security hole - use fgets instead&);
#if @GNULIB_FOPEN@
# if @REPLACE_FOPEN@
【折腾过程】
1.觉得，给diff生成的patch中添加注释，应该是其参数中可以添加的。
结果针对diff的参数：
找了半天，也没找到有关加注释的参数。
2.后来找了半天，看到：
中的解释：
The format starts with the same two-line
as the context format, except that the original file is preceded by &---& and the new file is preceded by &+++&. Following this are one or more change hunks that contain the line differences in the file. The unchanged, contextual lines are preceded by a space character, addition lines are preceded by a , and deletion lines are preceded by a .
If the recipient is supposed to use the -pN option, do not send output that looks like this:
diff -Naur v2.0.29/prog/README prog/README
— v2.0.29/prog/README Mon Mar 10 15:13:12 1997
+++ prog/README Mon Mar 17 14:58:22 1997
because the two file names have different numbers of slashes, and different versions of patch interpret the file names differently. To avoid confusion, send output that looks like this instead:
diff -Naur v2.0.29/prog/README v2.0.30/prog/README
— v2.0.29/prog/README Mon Mar 10 15:13:12 1997
+++ v2.0.30/prog/README Mon Mar 17 14:58:22 1997
才意识到：
貌似，此处patch文件中的内容，在三个短横线：
之前的内容，都算是注释，即，之前看到的，第一行的：
diff -Naur v2.0.29/prog/README prog/README
其实也是注释，也是patch语法中，所不识别，当做注释处理的。
貌似没有工具和（diff的）参数，可以给生成的patch添加注释的
如果想要实现开头的效果，则：
自己去手动，照葫芦画瓢，在patch最开始的部分，加上对应的内容即可。
diff -purN -X - host-m4-1.4.16.orig/lib/stdio.in.h host-m4-1.4.16/lib/stdio.in.h
--- host-m4-1.4.16.orig/lib/stdio.in.h
00:39:29. +0800
+++ host-m4-1.4.16/lib/stdio.in.h
16:53:28. +0800
@@ -162,7 +162,11 @@ _GL_WARN_ON_USE (fflush, &fflush is not
so any use of gets warrants an unconditional warning.
Assume it is
always declared, since it is required by C89.
#undef gets
+#if defined(__GLIBC__) && !defined(__UCLIBC__)
+#if !((__GLIBC__ & 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ &= 16))
_GL_WARN_ON_USE (gets, &gets is a security hole - use fgets instead&);
#if @GNULIB_FOPEN@
# if @REPLACE_FOPEN@
Since the 2.16 release of the glibc, 'gets' is not any more defined in the gnulib.
No m4 version synchronized with gnulib since [1] has been released yet.
This patch avoids the following error occurs when building m4 &=1.4.16 on host using
a glibc &=2.16:
make[4]: Entering directory `/opt/buildroot/output/build/host-m4-1.4.16/lib'
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT gl_avltree_oset.o -MD -MP -MF .deps/gl_avltree_oset.Tpo -c -o gl_avltree_oset.o gl_avltree_oset.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT c-ctype.o -MD -MP -MF .deps/c-ctype.Tpo -c -o c-ctype.o c-ctype.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT c-stack.o -MD -MP -MF .deps/c-stack.Tpo -c -o c-stack.o c-stack.c
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT clean-temp.o -MD -MP -MF .deps/clean-temp.Tpo -c -o clean-temp.o clean-temp.c
mv -f .deps/c-ctype.Tpo .deps/c-ctype.Po
/opt/buildroot/output/host/usr/bin/ccache /usr/bin/gcc -std=gnu99
-O2 -I/opt/buildroot/output/host/include -I/opt/buildroot/output/host/usr/include -MT close-hook.o -MD -MP -MF .deps/close-hook.Tpo -c -o close-hook.o close-hook.c
In file included from clean-temp.h:22:0,
from clean-temp.c:23:
./stdio.h:477:20: error 'gets' undeclared here (not in a function)
make[4]: *** [clean-temp.o] Error 1
References:
[1] http://git.savannah.gnu.org/gitweb/?p=gnulib.a=h=e93e5c518ebcc807348
[2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch?diff_format=h&revision=1.1&view=markup
Signed-off-by: Samuel Martin &s.&
diff -purN -X - host-m4-1.4.16.orig/lib/stdio.in.h host-m4-1.4.16/lib/stdio.in.h
--- host-m4-1.4.16.orig/lib/stdio.in.h
00:39:29. +0800
+++ host-m4-1.4.16/lib/stdio.in.h
16:53:28. +0800
@@ -162,7 +162,11 @@ _GL_WARN_ON_USE (fflush, &fflush is not
so any use of gets warrants an unconditional warning.
Assume it is
always declared, since it is required by C89.
#undef gets
+#if defined(__GLIBC__) && !defined(__UCLIBC__)
+#if !((__GLIBC__ & 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ &= 16))
_GL_WARN_ON_USE (gets, &gets is a security hole - use fgets instead&);
#if @GNULIB_FOPEN@
# if @REPLACE_FOPEN@
好像就可以了。
至此，没有找到有工具和特殊diff的参数，可以给生成的patch文件加注释的。
好像只需要手动去给patch文件，最开始部分，一般都是—之前的行，加上自己所需要的注释即可。
diff -purN -xxx xxx
add anything you want
diff -purN -xxx xxx
共享此文章：
免费的格式化Javascript源码的网站
查询Unicode字符，且还带Oct,Decimal,Hex,HTML Entity
HTML和Javascript都支持，很好用。1827人阅读
Buildroot的用法和文档由Thomas Petazzoni提供，文稿由Karsten Kruse、Ned Ludd、Martin Herren等整理。
最后修改时间： 02:08:10 -0700 (Wed, 19 Sep 2007)
l&&&& 关于Buildroot
l&&&& 获取Buildroot
l&&&& 使用Buildroot
l&&&& 定制目标文件系统
l&&&& 定制Busybox的配置
l&&&& 定制uClibc的配置
l&&&& Buildroot运行方式
l&&&& 使用uClibc 工具链
l&&&& 在Buildroot外部使用 uClibc 工具链
l&&&& 被下载包的存放位置
l&&&& 使用其他软件来扩展Buildroot
l&&&&&&&& 资源
关于Buildroot
Buildroot是一个Makefiles和patches的命令集，它可以非常简单的为你的目标系统产生一个交叉编译工具链和根文件系统 。这个交叉编译工具使用uClibc ()，uClibc是一个很小的标准库。
Buildroot那些从事于嵌入式系统的人来说是很有用处的。嵌入式系统经常使用的处理器都不是平常用于普通电脑的x86处理器它可能是PowerPC、 MIPS、ARM等处理器.
一个编译工具链就是一些工具的的命令集，这些工具允许你为你的目标系统编译源代码。它主要由编译器（在我们的例子中为gcc），二进制的工具集，如汇编程序和连接器（在我们的例子中为binutils），还有就是C的标准库（如GNU Libc、uClibc或者是dietlibc）。在你的开发平台上安装的系统里面要包含一个编译工具链，这个编译工具链是你可以在你的系统上编译应用程序。如果你使用的是一台PC机，你的编译工具链运行在x86处理器上，或者生成x86处理器可以运行的代码。在大多数的Linux系统里面，这个编译工具链使用的是GNU libc作为C的标准库。这个编译工具链被称之为&主机编译工具链&，而且通常来说，这台你在上面工作的电脑被称之为&主机系统&。这个编译工具链由你的系统提供，与Buildroot无关。
如同上面所说的一样，这个编译工具链随着你操作系统一起为你的主机系统上的处理器运行或者生成源代码。就像你的嵌入式系统拥有一个不同的处理器一样，你需要一个交叉编译工具链：它是一个运行在你的主机系统上但是为你的目标系统(和处理器)生成代码的工具链。举例来说，如果你的主机系统用的是x86处理器，你的目标系统用的是ARM处理器，你主机上的这个普通的编译工具链运行在你的x86处理器上并且为x86生成代码，但是交叉编译工具运行在你的x86处理器上但是为ARM生成代码
及时你的嵌入式系统用的是一个x86处理器，你也可能对Buildroot产生情趣，主要原因有以下两点：
&&& 显然，你的主机系统上的编译工具集用的是GNU Libc，GNU Libc是一个完整的标准库，但是它体积庞大。与你在你的目标系统上使用GNU Libc相比，你可以使用uClibc，uClibc是一个很微小的标准C库。如果你想使用这个C库，你需要一个编译工具集来生成二进制工具去链接它。Buldroot能够替你完成这些事。
&&&& Buildroot 自动地使用工具如busybox来建立一个根文件系统。它比手工完成一个根文件系统的制作更简单。
你可能很好奇了，为什么这样一个工具在你手工编译gcc、binutils、uClibc和其他所有的工具的时候是必须的。当然，手工完成它也是可能的。但是在处理所有的配置选项的时候，由于所有的问题如每一个gcc或者binutls版本都是耗费时间和令人厌倦的Buildroot通过使用Makefiles文件来自动操作这个过程，并且收集了每一个gcc和binutils版本的补丁，使他们能应用于更过的体系架构上面。
获取 Buildroot
Buildroot通过每天的SVN镜像文件或者直接使用SVN就可以得到。最新的镜像文件一直都放置在 ，并且之前的镜像也是放置在 .
使用SVN来下载Buildroot，你可以简单的使用uClibc buildroot 网站()下面的&Accessing SVN&页面()里描述的规则，并且下载SVN的各个模块。为了不让你着急，下面是一个简介的方法：
&$ svn co svn://uclibc.org/trunk/buildroot
使用 Buildroot
Buildroot有一个较好的配置工具，就像你在Linux()内核和Busybox()里面看到的类似。 注意的是你作为一个普通用户，你可以在里面构造任何东西。这里不需要你是一个超级用户来配置和是用Buildroot。第一步是运行配置助手：
&$ make menuconfig
对于配置的每个条目来说，你都可以找到相关联的帮助，帮助信息描述了该条目的用途。
一个关键的配置项目是PROFECT，它决定了在构建这些包的位置，以及结果安装的位置。
一旦所有的都配置完成了，配置工具将产生一个.config文件，里面包含了了你的配置信息，它将会被Makefile使用，来决定需要哪些文件。
让我们继续：
这个命令将下载、配置并且编译所有被选择的工具，并且最后产生一个目标文件系统。这个目标文件系统被命名为root_fs_ARCH.EXT,ARCH是你的处理器架构类型，EXT依赖于你在配置工具中选择的目标文件系统。这个文件存放在&binaries/$(PROJECT)/&目录里面。
创建你自己的目标板支持
一旦一个包被打开了，就可以手动的升级配置文。Buildroot能自动的保存buildroot、linux、busybox、uclibc和u-boot的配置文件，存放在 &local/$(PROJECT) &中，使用的命令如下：
&$ make saveconfig
一旦一个buildroot的配置文件同过saveconfig被创建了，缺省的&$(TOPDIR)/.config& 文件就可以通过下面的方式被覆盖了：
&$ make BOARD=&project&
Buildroot以后会使用 &local/&project&/&project&.config&而不是&.config&。
如果你想修改你的目标板，你可以使用下面的命令来复制该工程的配置文件到&.config&:
&$ make BOARD=&project& getconfig
你可以设置环境变量BUILDROOT_LOCAL使它指向这个目录来在多个buildroot树中共享你定制的目标板支持的文件夹。
如果你想离线构建，并且仅仅是想下载之前在&make menuconfig&中选择了的所有的源代码，执行如下：
&$ make source
你现在可以断开连接，复制你的dl目录中的内容到你的build-host。
Buildroot可以选择的遵循了部分已经通过的环境变量：
&&&& HOSTCXX
&&&& HOSTCC
&&&& UCLIBC_CONFIG_FILE=&path/to/.config&
&&&& BUSYBOX_CONFIG_FILE=&path/to/.config&
一个例子，使用config文件来定位顶级目录文件夹和你的$HOME:
$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=$HOME/bb.config
如果你想在你的主机上使用一个编译器而不是缺省的gcc或者是g++来构建helper-binaries，执行如下：
$ make HOSTCXX=g++-4.3-HEAD HOSTCC=gcc-4.3-HEAD
使用自动完成
如果你很懒散，你不想打字打出make menuconfigminglingh，你可以在你的shell中使用自动完成。这里是怎么样你才可以使用你的bash：
$ complete -W menuconfig make
然后只是打出一行开头的字符，通过按TAB键来调用bash去完成它:
$ make me&TAB&
这样bash就会为你附加上nuconfig！
作为选择，有些发行版（其中Debian和Mandriva就是一个例子）可以更好的补充。根据你的发行版本，你可能必须安装一些软件包以便完成. 在Mandriva上，这个包为bash-completion, 而Debian把它作为了bash软件包的一部分。
其他的shells，比如zsh, 也有完成这个任务的措施。具体的查看你的shell的文档。
定制目标文件系统
这里有一些定制最终目标文件系统的方法：
&&&& 直接定制目标文件系统，并且重建映像文件。目标文件系统存放在project_build_ARCH/root/ 目录下面，这里的ARCH就是你选择的目标架构。你可以很简单的在这里修改，并且重新编译来重建目标文件系统。这个方法允许你在目标文件系统上进行任何的改变，但是如果你决定完全重新构建你的工具链和工具集，这些修改都会被被丢失。
&&&& 定制目标文件系统框架，存放在target/generic/target_skeleton/目录下面，你可以在这里自定义配置文件或者其他东西。但是，完整的目录层次还没有实现，它是在编译的过程中创建的。所以你不能在这个文件系统框架上做任何事情，即使你完全重建了交叉编译工具链和工具集，但是这种改变依然被存在。你也可以自定义target/generic/device_table.txt 文件，它是被工具集用来创建目标文件系统的权限设置和设备节点。target/generic/skel.tar.gz 文件包含了根文件系统的主要文件夹，而且我们没有要去改变它。在这个压缩包里面的主要文件目录都在框架里面，因为它包含了指向框架的符号链接，以防被损坏。这些自定义配置在真正的映像产生之前将被展开到project_build_ARCH/root/ 目录里面。所以通过运行make来重建映像会把所有的修改都传递到映像里面。
&&&& 当使用make menuconfig来配置要建立的系统时，你可以指定在PROJECT 中的/etc/hostname和/etc/issue (欢迎条)的内容。
定制Busybox的配置
Busybox是完全可以配置的，而且你也想定制它。你可以遵循下面的简单步骤来配置它，它不是最佳的方式，但是它最简单额日期额可以正常工作。
1. 首先使用buildroot运行一次busybox，在这一次里面不需要进行任何的配置。
2. 调用make busybox-menuconfig。这个配置工具使你可以电脑告知所有的东西。
3. 再一此运行编译buildroot的编译。
另外，如果你知道你想要的修改的选项而不需要配置工具的话，你也可以修改package/busybox/busybox-&version&.config 文件 。
如果你想使用busybox的已经存在的配置文件，请参照后面的环境变量。
定制uClibc的配置
就像BusyBox一样，uClibc提供了许多配置选项。 他们允许你根据你不同的需求和局限性选择不同的功能。
最简单的修改uClibc配置的步骤如下：
1. 首先不定制uClibc来编译运行一次buildroot。
2. 调用make uclibc-menuconfig。这是一个很好的配置工具，它与曾在Linux内核和Buildroot里面所使用的类似。然后进行你的正确配置。
3. 拷贝.config到toolchain/uClibc/uClibc.config或者是到 toolchain/uClibc/uClibc.config-locale。如果你没有在Buildroot里面选择本地支持的话就使用前者，相反就用后者。
4. 再一此运行编译buildroot的编译。
另外，你也可以直接修改toolchain/uClibc/uClibc.config或者 toolchain/uClibc/uClibc.config-locale而不需要使用上面的配置工具。
如果你想使用一个已经存在uclibc配置文件，I请参照后面的环境变量。
Buildroot的运行方式
如上面所说的一样， Buildroot是一个基本的并使用恰当的选项去下载、配置、编译软件的命令集。它还包括了一些软件的补丁，主要的都是与交叉编译工具链有关 (gcc，binutils 和uClibc)。
主要的是每一个软件都有一个Makefile文件，他们都被命名为以.mk为扩展名。Makefiles主要分成以下四部分：
&&&& 工程 (在 project/ 目录) 包含了在这个相同buildroot目录树里面涉及到构建根文件系统Makefiles和相关联的文件。
&&&& 工具链 (在toolchain/ 目录) 包含了所有的设计到交叉工具链（binutils，ccache, gcc，gdb，kernel-headers and uClibc）的Makefiles和相关联的文件。
&&&& 包 (在package/ 目录) 包含了Buildroot编译并要加载到目标系统上的用户空间的工具的Makefiles和相关联的文件。对于每一个工具都有想对应的子目录。.
&&&& 目标 (在target/目录) 包含了用于生成一目标文件系统映像的软的Makefiles和相关文件。有四种类型的文件系统被支持：ext2，jffs2，cramfs和squashfs。他们中的每一个，都有一个子目录来存放需要的文件。这里也有一个缺省的default/ 目录，里面包含了目标文件系统的框架。
每个文件夹至少包含两个文件：
&&&& something.mk 是一个用于下载、配置、编译和安装的Makefile。
&&&& Config.in是配置工具描述文件的一部分，它描述了当前软件的相关选项。
核心的Makefile文件通过下面的步骤来完成任务（在配置完成以后）：
1. 创建下载目录(缺省的为dl/)。该目录就是被下载的压缩包存放的地方。非常有必要去了解该目录下的压缩包，我们可以将它保存到其他地方以免将来使用的时候再去下载。
2. 创建共享的构建目录(缺省的为build_ARCH/ ，ARCH是目标系统的体系架构)。在这个目录里面存放的是已经被编译了的不需要配置的用户空间的工具。当使用同一架构构建多个目标系统的时候，首先构建的会完全的通过下载、配置、编译等步骤，但是第二个或者以后的就只需要拷贝第一次的结果，主要可以加速构建的进度。
3. 创建工程的详细目录 (缺省的为project_build_ARCH/$(PROJECT), ARCH是目标系统的体系架构)。这里是所有的可配置的用户空间工具的被编译的目录。这个特殊的构建目录是必须的, 如果两个不用的目标体系架构都需要使用一个特殊的软件包，这样这个软件包就根据目标体系架构有不同的配置，busybox和linux就是其中的例子。
4. 创建工程的结果目录(缺省的为binaries/$(PROJECT)，ARCH是目标系统的体系架构)。这个目录是根文件系统映像存放的地方，也是存放目标系统的Linux内核映像和其他工具集、boot-loaders 等的地方。
5. 创建工具链目录(缺省的为toolchain_build_ARCH/，ARCH是目标系统的体系架构)。在这里交叉工具链被编译。
6.&&& 设置平台目录(缺省的为build_ARCH/staging_dir/)。这里是交叉编译工具链安装的地方。如果你想使用相同的交叉编译工具链来作为其他的用途，比如说编译第三方的应用软件，你可以添加build_ARCH/staging_dir/usr/b路径到PATH中，只有你就可以使用arch-linux-gcc来编译你的程序了。为了设置这个目录，首先应该移除这个它，然后它在该目录里面创建子目录和符号连接。
7. 创建目标文件系统 (缺省的为project_build_ARCH/root/) 和目标文件系统框架。这个目录将包含最终的根文件系统。要使它更新，首先应该删除它，然后解压 target/generic/skel.tar.gz 文件来创建主要的子目录文件夹和符号链接，并拷贝在target/generic/target_skeleton中可用的框架，然后删除没有用的.svn/目录。
8. 添加TARGETS的依赖关系。一般将会检查这些包的配置选项是否可用，然后通过把它添加到TARGETS全局变量中来定制要被编译的软件包。
在相同的buildroot源代码目录树构建几个不同的工程
如果每个工程都是为不同的体系架构构建的话，buildroot支持在同一个源代码目录树中构建若干不同的工程。
根文件系统被创建在&build_&ARCH&/root&文件夹中，对于每一个体系架构来说，它都是唯一的。交叉工具链被建立在&toolchain_build_&ARCH&&目录。
如果用户希望为相同的体系架构构建若干个根文件系统，就应该在配置中加上前缀或者后缀，这样的话，建立的根文件系统就被放置在&&PREFIX&_build_&ARCH&_&SUFFIX&/root&。通过设置唯一的前缀和后缀，使每一个工程都有一个唯一的根文件系统树。
这个方法的缺点就是为同一个芯片建立两个工程，每一个工程都要建立一个新的工具链，这个构建过程将耗费更多的时间。
如果使用的是gcc-4.x.y 的话，这个缺点就不是那么的明显了，因为gcc-4.x.y 允许使用外部工具链。由于某些软件包需要一些特殊功能，如果使用的一个外部的工具链，这可能就缺少一些必要的功能，来构建一个根文件系统。
一个更大的问题是build_&ARCH&目录树也是拷贝的，这样的话，每个软件包也都为每一个工程重建一次，导致花费更长的时间。
共享工程的工具链和构建的软件包
当工作在一个工程的时候，允许用户在同一个目录树为同一个体系架构构建多个根目录树。工具链个软件包的构建目录将会被共享，但是每一个具体的工程都有一个专门的目录。
在使用的这个方法的时候，更多的是，如果在第一个工程建立时，所有的软件包都没有被编译。这个过程就几乎同原来的过程一样了，所有下载的软件包被下载然后提取到共享目录&build_&ARCH&/&package&&中，然后配置、编译。
二进制软件包和头文件被安装到共享目录$(STAGING_DIR)中，然后这个工程专门的根文件系统被设置到&$(TARGET_DIR)&。
在构建结束的时候，还要通过这个根文件系统来生成一个最后的二进制根文件系统。
一旦第一个工程构建结束，在构建其他工程的时候就只是调用已经共享在&build_&ARCH&/&&&目录下的内容来生成新的文件系统。
如果一些软件包没有用于第一个工程，就只能通过提取-配置-编译的步骤了。
核心是要建立两个新的目录：
&&&& project_build_&ARCH&
&&&& binaries；
每个目录里面都包含了每个工程的子目录。子目录的名字是用户在配置buildroot的时候配置的，它由下面的内容组成：
Project Options ---& Project name
这里定义$(PROJECT)变量。
缺省的名字（project name）为&uclibc&。
"package/Makefile.in"定义为：
&&& PROJECT_BUILD_DIR:=project_build_$(ARCH)/$(PROJECT)
&&& BINARIES_DIR:=binaries/$(PROJECT)
它也定义了目标根文件系统的本地路径：
&&& TARGET_DIR:=$(PROJECT_BUILD_DIR)/$(PROJECT)/root
也就是说：如果用户使用&myproject&作为$(PROJECT) 名称：
&&&& "project_build_&ARCH&/myproject"
&&&& "binaries/myproject"
就会被创建。
现在，根文件系统，busybox和AtmelU-Boot版本，还有Atmel专门的一些bootloader像阿通1-bootstrap和dataflashboot.bin都被构建在&$(PROJECT_BUILD_DIR)&中。
所有体系架构最后的二进制文件都存放在&$(BINARIES_DIR)&目录中。
工程将会共享不会引起冲突的文件夹，但是使用唯一的构建目录，在该目录中，用户可以配置自己的配置。
该做的事情
当前的Linux版本总是有缺陷的， 它仅仅工作在用户选择使用较少额选项作为内核基本的头文件。它仅服务于用户选择的少量的内核作为主要内核的基础。虽然Makefle有一些关联，允许开发者在target/device/*/* Makefiles中指定内核的版本，但是如果选择了其他的版本，构建将会失败的。
原因是内核的补丁没有被"target/linux/linux.mk"用来编译脚本片段。他们仅用于"toolchain/kernel-headers/*.makefile"去编译脚本片段。
如果内核头文件和Linux版本不一样的话，在&build_&ARCH&/&&&将会有两个&linux-2.6.X.Y&文件夹，每一个都自己的补丁命令。
在这个方案中的解决办法是，将Linux的构建目录移动到&project_build_&ARCH&/&project name&/linux-2.6.X.Y&，结合这个方法把可以应用的补丁进行配置。用于产生头文件的Linux的源代码目录树很可能会被移动到&toolchain_build_&ARCH&&目录中去。
用户可以选择下面三种不同的策略：
o&& 保守策略: 仅仅使用内核头文件支持的版本
o&& 稳定Linux的策略: 允许任何的2.6.X.Y 的组合体（最小为2.6.19）
o&& 激进用户策略: 允许&-git&或者是&-mm&，或者是用户下载内核
The current kernel patches can be configured to be applied to the linux source tree even if the version differs from the kernel header version.
Since the user can select any kernel-patch he/she will be able to select a non-working combination. If the patch fails, the user will have to generate a new proprietary kernel-patch or decide to not apply the kernel patches
Other optional patches will be board specific or architecture specific patches.
There will also be a way for the user to supply absolute or relative paths to patches, possibly outside the main tree. This can be used to apply custom kernel-header-patches, if the versions available in buildroot cannot be applied to the specific linux version used
Maybe, there will also be a possibility to supply an "URL" to a patch available on Internet.
2. Configurable packages
Many packages can, on top of the simple "enable/disable build", be further configured using Kconfig. Currently these packages will be compiled using the configuration specified in the ".config" file of the first project demanding the build of the package.
If another project uses the same packages, but with a different configuration,these packages will not be rebuilt, and the root file system for the new project will be populated with files from the build of the first project
If multiple project are built, and a specific package needs two different configuration, then the user must delete the package from the "build_&ARCH&" directory before rebuilding the new project.
A long term solution is to edit the package makefile and move the build of the configurable packages from "build_&ARCH&" to "project_build_&ARCH&/&project name&" and send a patch to the buildroot mailing list.
3. Naming conventions
Names of resulting binaries should reflect the "project name"
4. Generating File System binaries
Packages which needs to be installed with the "root" as owner, will generate a ".fakeroot.&package&" file which will be used for the final build of the root file system binary.
This was previously located in the "$(STAGING_DIR)" directory, but was recently moved to the "$(PROJECT_BUILD_DIR)" directory.
Currently only three packages: "at", "ltp-testsuite" and "nfs-utils" requests fakeroot.
The makefile fragments for each file system type like "ext2", "jffs2" or "squashfs" will, when the file system binary is generated, collect all present ".fakeroot.&package&" files to a single "_fakeroot.&file system&" file and call fakeroot.
".fakeroot.&package&" files are deleted as the last action of the Buildroot Makefile.
It needs to be evaluated if any further action for the file system binary build is needed.
Using the uClibc toolchain
You may want to compile your own programs or other software that are not packaged in Buildroot. In order to do this, you can use the toolchain that was generated by Buildroot.
The toolchain generated by Buildroot by default is located in build_ARCH/staging_dir/. The simplest way to use it is to add build_ARCH/staging_dir/usr/bin/ to your PATH environnement variable, and then to use arch-linux-gcc, arch-linux-objdump, arch-linux-ld, etc.
For example, you may add the following to your .bashrc (considering you're building for the MIPS architecture and that Buildroot is located in ~/buildroot/) :
export PATH="$PATH:~/buildroot/build_mips/staging_dir/usr/bin/"
Then you can simply do :
mips-linux-gcc -o foo foo.c
Important : do not try to move a gcc-3.x toolchain to an other directory, it won't work. There are some hardcoded paths in the gcc configuration. If the default toolchain directory doesn't suit your needs, please refer to the Using the uClibc toolchain outside of buildroot section.
If you are using a current gcc-4.x, then use --sysroot and -isysroot since these toolchains have fully functional sysroot support. No hardcoded paths do exist in these configurations.
Using the uClibc toolchain outside of buildroot
By default, the cross-compilation toolchain is generated inside build_ARCH/staging_dir/. But sometimes, it may be useful to install it somewhere else, so that it can be used to compile other programs or by other users. Moving the build_ARCH/staging_dir/ directory elsewhere is not possible if using gcc-3.x, because there are some hardcoded paths in the toolchain configuration. This works, thanks to sysroot support, with current, stable gcc-4.x toolchains, of course.
If you want to use the generated gcc-3.x toolchain for other purposes, you can configure Buildroot to generate it elsewhere using the option of the configuration tool : Build options -& Toolchain and header file location, which defaults to $(BUILD_DIR)/staging_dir/.
Location of downloaded packages
It might be useful to know that the various tarballs that are downloaded by the Makefiles are all stored in the DL_DIR which by default is the dl directory. It's useful for example if you want to keep a complete version of Buildroot which is know to be working with the associated tarballs. This will allow you to regenerate the toolchain and the target filesystem with exactly the same versions.
If you maintain several buildroot trees, it might be better to have a shared download location. This can be accessed by creating a symbolic link from the dl directory to the shared download location.
ln -s &shared download location& dl
Another way of accessing a shared download location is to create the BUILDROOT_DL_DIR environment variable. If this is set, then the value of DL_DIR in the project is overridden. The following line should be added to "~/.bashrc".
export BUILDROOT_DL_DIR &shared download location&
Extending Buildroot with more software
This section will only consider the case in which you want to add user-space software.
Package directory
First of all, create a directory under the package directory for your software, for example foo.
Config.in file
Then, create a file named Config.in. This file will contain the portion of options description related to our foo software that will be used and displayed in the configuration tool. It should basically contain :
config BR2_PACKAGE_FOO
&&&&&&& bool "foo"
&&&&&&& default n
&&&&&&& help
&&&&& This is a comment that explains what foo is.
Of course, you can add other options to configure particular things in your software.
The real Makefile
Finally, here's the hardest part. Create a file named foo.mk. It will contain the Makefile rules that are in charge of downloading, configuring, compiling and installing the software. Below is an example that we will comment afterwards.
&&&& 1& #############################################################
&&&& 3& # foo
&&&& 5& #############################################################
&&&& 6& FOO_VERSION:=1.0
&&&& 7& FOO_SOURCE:=foo-$(FOO_VERSION).tar.gz
&&&& 8& FOO_SITE:=http://www.foosoftware.org/downloads
&&&& 9& FOO_DIR:=$(BUILD_DIR)/foo-$(FOO_VERSION)
&&& 10& FOO_BINARY:=foo
&&& 11& FOO_TARGET_BINARY:=usr/bin/foo
&&& 13& $(DL_DIR)/$(FOO_SOURCE):
&&& 14&&&&&&&&& $(WGET) -P $(DL_DIR) $(FOO_SITE)/$(FOO_SOURCE)
&&& 16& $(FOO_DIR)/.source: $(DL_DIR)/$(FOO_SOURCE)
&&& 17&&&&&&&&& $(ZCAT) $(DL_DIR)/$(FOO_SOURCE) | tar -C $(BUILD_DIR) $(TAR_OPTIONS) -
&&& 18&&&&&&&&& touch $@
&&& 20& $(FOO_DIR)/.configured: $(FOO_DIR)/.source
&&& 21&&&&&&&&& (cd $(FOO_DIR); rm -rf config. /
&&& 22&&&&&&&&&&&&&&&&& $(TARGET_CONFIGURE_OPTS) /
&&& 23&&&&&&&&&&&&&&&&& $(TARGET_CONFIGURE_ARGS) /
&&& 24&&&&&&&&&&&&&&&&& ./configure /
&&& 25&&&&&&&&&&&&&&&&& --target=$(GNU_TARGET_NAME) /
&&& 26&&&&&&&&&&&&&&&&& --host=$(GNU_TARGET_NAME) /
&&& 27&&&&&&&&&&&&&&&&& --build=$(GNU_HOST_NAME) /
&&& 28&&&&&&&&&&&&&&&&& --prefix=/usr /
&&& 29&&&&&&&&&&&&&&&&& --sysconfdir=/etc /
&&& 30&&&&&&&&& )
&&& 31&&&&&&&&& touch $@
&&& 33& $(FOO_DIR)/$(FOO_BINARY): $(FOO_DIR)/.configured
&&& 34&&&&&&&&& $(MAKE) CC=$(TARGET_CC) -C $(FOO_DIR)
&&& 36& $(TARGET_DIR)/$(FOO_TARGET_BINARY): $(FOO_DIR)/$(FOO_BINARY)
&&& 37&&&&&&&&& $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) install
&&& 38&&&&&&&&& rm -Rf $(TARGET_DIR)/usr/man
&&& 40& foo: uclibc ncurses $(TARGET_DIR)/$(FOO_TARGET_BINARY)
&&& 42& foo-source: $(DL_DIR)/$(FOO_SOURCE)
&&& 44& foo-clean:
&&& 45&&&&&&&&& $(MAKE) prefix=$(TARGET_DIR)/usr -C $(FOO_DIR) uninstall
&&& 46&&&&&&&&& -$(MAKE) -C $(FOO_DIR) clean
&&& 48& foo-dirclean:
&&& 49&&&&&&&&& rm -rf $(FOO_DIR)
&&& 51 #############################################################
&&& 53 # Toplevel Makefile options
&&& 55 #############################################################
&&& 56 ifeq ($(strip $(BR2_PACKAGE_FOO)),y)
&&& 57 TARGETS+=foo
&&& 58 endif
First of all, this Makefile example works for a single binary software. For other software such as libraries or more complex stuff with multiple binaries, it should be adapted. Look at the other *.mk files in the package directory.
At lines 6-11, a couple of useful variables are defined :
&&&& FOO_VERSION : The version of foo that should be downloaded.
&&&& FOO_SOURCE : The name of the tarball of foo on the download website of FTP site. As you can see FOO_VERSION is used.
&&&& FOO_SITE : The HTTP or FTP site from which foo archive is downloaded. It must include the complete path to the directory where FOO_SOURCE can be found.
&&&& FOO_DIR : The directory into which the software will be configured and compiled. Basically, it's a subdirectory of BUILD_DIR which is created upon decompression of the tarball.
&&&& FOO_BINARY : Software binary name. As said previously, this is an example for a single binary software.
&&&& FOO_TARGET_BINARY : The full path of the binary inside the target filesystem.
Lines 13-14 defines a target that downloads the tarball from the remote site to the download directory (DL_DIR).
Lines 16-18 defines a target and associated rules that uncompress the downloaded tarball. As you can see, this target depends on the tarball file, so that the previous target (line 13-14) is called before executing the rules of the current target. Uncompressing is followed by touching a hidden file to mark the software has having been uncompressed. This trick is used everywhere in Buildroot Makefile to split steps (download, uncompress, configure, compile, install) while still having correct dependencies.
Lines 20-31 defines a target and associated rules that configures the software. It depends on the previous target (the hidden .source file) so that we are sure the software has been uncompressed. In order to configure it, it basically runs the well-known ./configure script. As we may be doing cross-compilation, target, host and build arguments are given. The prefix is also set to /usr, not because the software will be installed in /usr on your host system, but in the target filesystem. Finally it creates a .configured file to mark the software as configured.
Lines 33-34 defines a target and a rule that compiles the software. This target will create the binary file in the compilation directory, and depends on the software being already configured (hence the reference to the .configured file). It basically runs make inside the source directory.
Lines 36-38 defines a target and associated rules that install the software inside the target filesystem. It depends on the binary file in the source directory, to make sure the software has been compiled. It uses the install target of the software Makefile by passing a prefix argument, so that the Makefile doesn't try to install the software inside host /usr but inside target /usr. After the installation, the /usr/man directory inside the target filesystem is removed to save space.
Line 40 defines the main target of the software, the one that will be eventually be used by the top level Makefile to download, compile, and then install this package. This target should first of all depends on all needed dependecies of the software (in our example, uclibc and ncurses), and also depend on the final binary. This last dependency will call all previous dependencies in the correct order.
Line 42 defines a simple target that only downloads the code source. This is not used during normal operation of Buildroot, but is needed if you intend to download all required sources at once for later offline build. Note that if you add a new package providing a foo-source target is mandatory to support users that wish to do offline-builds. Furthermore it eases checking if all package-sources are downloadable.
Lines 44-46 define a simple target to clean the software build by calling the Makefiles with the appropriate option. The -clean target should run make clean on $(BUILD_DIR)/package-version and MUST uninstall all files of the package from $(STAGING_DIR) and from $(TARGET_DIR).
Lines 48-49 define a simple target to completely remove the directory in which the software was uncompressed, configured and compiled. The -dirclean target MUST completely rm $(BUILD_DIR)/ package-version.
Lines 51-58 adds the target foo to the list of targets to be compiled by Buildroot by first checking if the configuration option for this package has been enabled using the configuration tool, and if so then "subscribes" this package to be compiled by adding it to the TARGETS global variable. The name added to the TARGETS global variable is the name of this package's target, as defined on line 40, which is used by Buildroot to download, compile, and then install this package.
Conclusion
As you can see, adding a software to buildroot is simply a matter of writing a Makefile using an already existing example and to modify it according to the compilation process of the software.
If you package software that might be useful for other persons, don't forget to send a patch to Buildroot developers !
To learn more about Buildroot you can visit these websites:
本文来自CSDN博客，转载请标明出处：
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：366395次
积分：4373
积分：4373
排名：第4803名
原创：38篇
转载：318篇
评论：10条
(1)(1)(1)(3)(4)(2)(1)(2)(1)(1)(1)(1)(1)(4)(10)(26)(8)(4)(23)(32)(29)(12)(47)(24)(58)(19)(4)(9)(7)(6)(1)(2)(2)(1)(2)(6)