buildroot-2 构建系统探索

最新推荐文章于 2024-02-26 00:09:28 发布

MTVideoAI

最新推荐文章于 2024-02-26 00:09:28 发布

阅读量975

点赞数

分类专栏： OS 原理与用法文章标签： buildroot cmake 系统映像组件配置

本文链接：https://blog.csdn.net/shareviews/article/details/105563684

版权

OS 原理与用法专栏收录该内容

4 篇文章 1 订阅

订阅专栏

按：Buildroot是一套自动化构建Linux系统的超级编译工具链，本节目标是探索buildroot构建系统。玩转Buildroot构建系统，需要对系统配置、组件配置和工程化定制需要有相当的了解，开启我们的探索之旅。

Buildroot构建指南系列文章

❉ buildroot的配置

make * config一般提供了几个实用工具：一、配置选项都有一个帮助文本；二、提供了搜索工具，搜索结果显示匹配项的帮助消息；三、左栏中的数字提供了相应条目的快捷方式。

交叉编译工具链是一组能够为你系统编译代码的工具集。交叉编译工具链一般包括：编译器(gcc等)、二进制utils(汇编器和链接器等)和C标准库(GNU Libc/uClibc-ng)组成。Bootroot支持两种交叉编译工具链解决方案：内部工具链后端和Buildroot工具链后端，在配置界面可切换。Buildroot的交叉编译链，如下图所示。

图-X Buildroot的交叉编译工具链

编译系统一般需要以下特性。第一、支持灵活的源码构建；第二、能够快速的构建交叉编译环境；第三、简单的构建系统配置。Buildroot编译系统，利用开源或者闭源的软件包，通过高级配置之后，能够Linux操作系统所需要的交叉编译工具和操作系统映像，如下图所示。

图-X Buildroot输出的操作系统映像

❉❉ buildroot的工具链配置

内部工具链后端是Buildroot在构建目标嵌入式系统的用户空间应用程序和库之前，自行构建交叉编译工具链的后端。该后端支持多个C库：uClibc-ng，glibc和musl。内部工具链后端是Buildroot在构建目标嵌入式系统的用户空间应用程序和库之前，自行构建交叉编译工具链的后端。该后端支持多个C库：uClibc-ng，glibc和musl。选择编译后端之后，编译后端拥有很多选项，需要仔细研读，比如：编译器、二进制工具、C标准库、Linux Header相关的配置。

内部工具链后端和Buildroot之间具有良好的兼容性，而且配置选项丰富，能够只构建必须的内容。该后端进行清理时需要重建工具链，这将耗费很多构建时间，外部工具链后端无此问题。

外部工具链后端允许使用现有的预先构建的交叉编译工具链。 Buildroot支持多种知名的预编译工具链(ARM Linaro，ARM CodeBench和MIPS),并且能够自动下载/提取和安装知名工具链。Buildroot也支持自定义工具链。如果知名的预编译工具链已经存在系统中，将其路径配到Buildroot工具链即可工作。外部工具链后端不支持将分发工具链(即分发中安装的gcc/binutils/C库)用作构建目标软件的工具链。这是因为您的分发工具链不是纯工具链(即仅使用C/C ++库)，因此我们无法将其正确导入到Buildroot构建环境中。

外部工具链后端支持多种知名的预编译交叉编译工具链，预编译的交叉编译工具链能够明显减少构建时间。当然预编译的交叉编译工具链出现问题，排查问题是一件很困难的事情。

Buildroot内部工具链选项可用于创建外部工具链。这样构建生成的内部工具链并将其打包，就可被Buildroot本身认为是外部工具链。创建新的Buildroot配置详细步骤如下：

以下是构建内部工具链并将其打包以供Buildroot本身重用的一系列步骤。
● Select the appropriate Target options for your target CPU architecture
● In the Toolchain menu, keep the default of Buildroot toolchain for Toolchain type, and configure your toolchain as desired
● In the System configuration menu, select None as the Init system and none as /bin/sh
● In the Target packages menu, disable BusyBox
● In the Filesystem images menu, disable tar the root filesystem

然后，我们可以触发构建，并要求Buildroot生成SDK。这将为我们方便地生成一个包含工具链的压缩包：

$ make sdk  # images/arm-buildroot-linux-uclibcgnueabi_sdk-buildroot.tar.gz

在其他的buildroot工程中，我们重用这个预编译好的工具链。配置如下:
● Set Toolchain type to External toolchain
● Set Toolchain to Custom toolchain
● Set Toolchain origin to Toolchain to be downloaded and installed
● Set Toolchain URL to file:///path/to/your/sdk/tarball.tar.gz

❉❉ / dev管理

在Linux系统上，/ dev目录包含称为设备文件的特殊文件，这些文件允许用户空间应用程序访问Linux内核管理的硬件设备。没有这些设备文件，即使Linux内核正确识别了硬件设备，您的用户空间应用程序也将无法使用它们。
在系统配置/ dev管理下，Buildroot提供了四种解决方案来处理/ dev目录：
● 方案一：是使用设备表的静态。
● 方案二：仅使用devtmpfs进行动态处理。 devtmpfs是Linux内核中的一个虚拟文件系统，已在内核2.6.32中引入。使用devtmpfs需要启用以下内核配置选项：CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT。
● 方案三：使用devtmpfs + mdev进行动态处理。此方法还依赖于上面详细介绍的devtmpfs虚拟文件系统，但是在其顶部添加了mdev userspace实用程序。 mdev是BusyBox的程序部分，内核在每次添加或删除设备时都会调用。请参见http://git.busybox.net/busybox/tree/docs/mdev.txt。
● 方案四：使用devtmpfs + eudev进行动态处理。eudev是一个后台运行的守护程序，当设备从系统中添加或删除时，内核会调用它。有关更多详细信息，请参见http://en.wikipedia.org/wiki/Udev。

❉❉ 初始化系统

初始化程序是由内核启动的第一个用户空间程序(pid = 1), 负责启动用户空间服务和程序(网络服务器、图形GUI, 网络驱动等)。Buildroot允许使用三种不同类型的初始化系统，可以从系统配置(初始化系统)中进行选择。Buildroot开发人员推荐的解决方案是使用BusyBox初始化，因为它对于大多数嵌入式系统来说已经足够。 systemd可用于更复杂的情况。
● 方案一：默认busybox作为初始化系统。启用BR2_INIT_BUSYBOX将确保BusyBox将生成并安装其init程序。在启动时，BusyBox初始化程序将读取/ etc / inittab文件以知晓要启动哪些应用程序。busybox的语法参见：http://git.busybox.net/busybox/tree/examples/inittab
● 方案二：systemV作为初始化系统。sysvinit配合inittab文件完成系统初始化。
● 方案三：systemd作为初始化系统。依赖dbus和udev等来启动和激活守护服务。请参见http://www.freedesktop.org/wiki/Software/systemd。

❉ buildroot其他组件的配置

在尝试修改下面的任何组件之前，请确保您已经配置了Buildroot本身，并启用了相应的软件包。典型的使用默认配置即可，BR2_PACKAGE_${COM_NAME}_DEFCONFIG, 然后使用make ${COM_NAME}-menuconfig进行配置。

● BusyBox组件
可以使用BR2_PACKAGE_BUSYBOX_CONFIG来指定自定义的BusyBox配置文件。进行后续更改的命令是make busybox-menuconfig。

● uClibc组件
可以使用BR2_UCLIBC_CONFIG来指定自定义的uClibc配置文件。进行后续更改的命令是make uclibc-menuconfig。

● Linux kernel组件
可以使用BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG来指定自定义的Linux kernel配置文件。进行后续更改的命令是make linux-menuconfig。

● Barebox组件
可以使用BR2_TARGET_BAREBOX_USE_CUSTOM_CONFIG来指定自定义的Barebox 配置文件。进行后续更改的命令是make uboot-menuconfig。

● U-Boot
可以使用BR2_TARGET_UBOOT_USE_CUSTOM_CONFIG 来指定自定义的Barebox 配置文件。进行后续更改的命令是make barebox-menuconfig。

❉ 通用的Buildroot用法

❉❉ make提示

下面是一组系列技巧，可帮助您充分利用Buildroot。

$ make V=1 <target>     # display all commonds
$ make list-defconfigs  # display list of defconfigs
$ make help             # display all available targets
$ make clean            # explicit cleaning
$ make manual-clean     # generating the manual
$ make manual           # the manual is in output/docs/manual.
$ make -s printvars VARS=BUSYBOX_%DEPENDENCIES  # dump internal variables.
$ eval $(make -s printvars VARS=BUSYBOX_DEPENDENCIES QUOTED_VARS=YES)
$ echo $BUSYBOX_DEPENDENCIES

❉❉ 需要重新构建系统的场景

当通过make menuconfig，make xconfig或其他配置工具之一更改系统配置时，Buildroot不会尝试检测应重建系统的哪些部分。在某些情况下，Buildroot应该重建整个系统；在某些情况下，仅应重建软件包的特定子集。Buildroot没有可靠的解决方案能够检测上述情况，相反，用户有责任知道何时需要完全重建。一般下面的场景，用户需要考虑重新编译系统。
● 更改目标体系结构配置时，需要完全重建。
● 当更改工具链配置时，通常需要完全重建。
● 更改根文件系统框架后，需要完全重建。
● 将其他软件包添加到配置时，不一定需要完全重建。
● 从配置中删除软件包时，Buildroot不会执行任何特殊操作。
● 更改软件包的子选项时，不会自动重建软件包。

作为参考，可以通过运行以下命令来进行完全重建：

$ make clean all

❉❉ 需要重新编译软件包的场景

如何重建给定的软件包或如何删除软件包而不重新构建所有内容？这是我们日常开发中比较关心的问题。从头开始重建单个软件包的最简单方法是在output / build中删除其构建目录。然后，Buildroot将从头开始重新提取，重新配置，重新编译和重新安装此软件包。

make <package>-dirclean       # 清空
make <package>-rebuild        # 重新编译
make <package>-reconfigure    # 重新配置
make <package>-reinstall      # 重新安装

❉❉ 环境变量

当在环境中传递make或set时，Buildroot还尊重一些环境变量：

HOSTCXX                  # HOST C++ 编译器
HOSTCC                     # HOST C 编译器
BR2_CCACHE_DIR    # 缓存文件存储的目录
UCLIBC_CONFIG_FILE = <path/to/.config>      # uClibc配置文件
BUSYBOX_CONFIG_FILE = <path/to/.config>  # busybox配置文件
$ make UCLIBC_CONFIG_FILE=uClibc.config BUSYBOX_CONFIG_FILE=bb.config
$ make HOSTCXX=g++-4.3 HOSTCC=gcc-4.3-HEAD

❉❉ 高级用法

在Buildroot之外使用交叉编译链
Buildroot编译系统构建之后，交叉编译链位于output/host/bin目录。将该目录添加到PATH环境变量中，外部世界即可使用 ARCH-linux-gcc, ARCH-linux-objdump, ARCH-linux-ld等工具。

关于使用gdb使用
Buildroot允许进行交叉调试，其中调试器在构建计算机上运行，并与目标上的gdbserver通信以控制程序的执行。当编译Buildroot内部插件工具链时，必须启用BR2_PACKAGE_HOST_GDB，BR2_PACKAGE_GDB和BR2_PACKAGE_GDB_SERVER。gdb在host机器上运行，gdbserver在目标机器上运行。
gdbserver：8989 ffmpeg # 目标机器在8989端口监听调试连接

<buildroot>/output/host/bin/<tuple>-gdb -x    # host主机
<buildroot>/output/staging/usr/share/buildroot/gdbinit ffmpeg   # host主机

特定软件的make target
运行make -将构建并安装该特定软件包及其依赖项。对于依赖Buildroot基础结构的软件包，有许多特殊的make目标，可以像这样独立调用：

$ make <package>-source
$ make <package>-depends
$ make <package>-extract
$ make <package>-patch
$ make <package>-configure
$ make <package>-build
$ make <package>-install
$ make <package>-show-depends
$ make <package>-dirclean
$ make <package>-reinstall
$ make <package>-rebuild
$ make <package>-reconfigure

❉ 工程相关的定制化

对于给定的项目，您可能需要执行的典型操作是：
● 配置Buildroot（包括构建选项和工具链，引导程序，内核，软件包和文件系统映像）
● 配置其他组件，例如Linux内核和BusyBox
● 定制生成的目标文件系统
● 在目标文件系统上添加或覆盖文件（使用BR2_ROOTFS_OVERLAY）
● 修改或删除目标文件系统上的文件（使用BR2_ROOTFS_POST_BUILD_SCRIPT）
● 在生成文件系统映像之前运行任意命令（使用BR2_ROOTFS_POST_BUILD_SCRIPT）
● 设置文件的权限和所有权（使用BR2_ROOTFS_DEVICE_TABLE）
● 添加自定义设备节点（使用BR2_ROOTFS_STATIC_DEVICE_TABLE）
● 添加自定义用户帐户（使用BR2_ROOTFS_USERS_TABLES）
● 在生成文件系统映像之后运行任意命令（使用BR2_ROOTFS_POST_IMAGE_SCRIPT）
● 将项目特定的补丁程序添加到某些程序包（使用BR2_GLOBAL_PATCH_DIR）
● 添加特定于项目的软件包

工程配置是定制化必须去啃的模块，更多信息见官方文档。

❉ 参考文献

https://buildroot.org/downloads/manual/manual.html#
https://bootlin.com/doc/training/buildroot/buildroot-slides.pdf

MTVideoAI

关注

0
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
buildroot-2 构建系统探索

按：Buildroot是一套自动化构建Linux系统的超级编译工具链，本节目标是探索buildroot构建系统。玩转Buildroot构建系统，需要对系统配置、组件配置和工程化定制需要有相当的了解，开启我们的探索之旅。buildroot的配置; 工具链配置; 其他组件的配置; 环境变量; 高级用法。Buildroot概述。Buildroot架构。Buildroot分析。rootfs编译；package编译；软件包重建；Buildroot命令。Buildroot构建指南系列
复制链接

扫一扫