Buildroot 配置

所有配置选项make *config都有一个帮助文本，提供有关该选项的详细信息。

这些make *config命令还提供搜索工具。阅读不同前端菜单中的帮助消息以了解如何使用它：

• 在menuconfig中，按 /;可调用搜索工具。
• 在xconfigCtrl，按 ctrl+f 可调用搜索工具。

搜索结果显示匹配项的帮助消息。在menuconfig中，左列中的数字提供相应条目的快捷方式。只需输入此数字即可直接跳转到该条目，或者在由于缺少依赖项而无法选择该条目时跳转到包含的菜单。

虽然菜单结构和条目的帮助文本应该足够不言自明，但许多主题需要额外的解释，而这些解释无法在帮助文本中轻易涵盖，因此在以下章节中有所介绍。

交叉编译工具链

编译工具链是一组可用于编译系统代码的工具。它由编译器（在我们的例子中为gcc）、汇编器和链接器等二进制实用程序（在我们的例子中为binutils）以及 C 标准库（例如 GNU Libc、 uClibc-ng）组成。

安装在开发站上的系统肯定已经有一个编译工具链，您可以使用它来编译在系统上运行的应用程序。如果您使用的是 PC，则编译工具链在 x86 处理器上运行并为 x86 处理器生成代码。在大多数 Linux 系统下，编译工具链使用 GNU libc (glibc) 作为 C 标准库。此编译工具链称为“主机编译工具链”。运行它以及您正在工作的机器称为“主机系统”。

编译工具链由您的发行版提供，Buildroot 与它无关（除了使用它来构建交叉编译工具链和在开发主机上运行的其他工具）。

如上所述，系统附带的编译工具链在主机系统的处理器上运行并生成代码。由于嵌入式系统具有不同的处理器，因此您需要一个交叉编译工具链 - 一个在主机系统上运行但为目标系统（和目标处理器）生成代码的编译工具链。例如，如果您的主机系统使用 x86 而目标系统使用 ARM，则主机上的常规编译工具链在 x86 上运行并为 x86 生成代码，而交叉编译工具链在 x86 上运行并为 ARM 生成代码。

Buildroot为交叉编译工具链提供了两种解决方案：

• 内部工具链后端，在配置界面调用 Buildroot toolchain。
• 外部工具链后端，在配置界面调用 External toolchain 。

Toolchain Type使用菜单中的选项在这两种解决方案之间进行选择Toolchain。一旦选择了一种解决方案，就会出现许多配置选项，它们将在以下部分中详细介绍。

内部工具链后端

内部工具链后端是Buildroot 在为目标嵌入式系统构建用户空间应用程序和库之前自行构建交叉编译工具链的后端。

该后端支持多个 C 库： uClibc-ng、 glibc和 musl。

选择此后端后，会出现许多选项。最重要的选项允许：

• 更改用于构建工具链的 Linux 内核头文件的版本。此项值得解释几句。在构建交叉编译工具链的过程中，C 库正在构建中。此库提供用户空间应用程序与 Linux 内核之间的接口。为了知道如何与 Linux 内核“对话”，C 库需要访问 Linux 内核头文件（即.h来自内核的文件），这些头文件定义了用户空间与内核之间的接口（系统调用、数据结构等）。由于此接口是向后兼容的，因此用于构建工具链的 Linux 内核头文件的版本不需要与您打算在嵌入式系统上运行的 Linux 内核的版本完全匹配。它们只需要具有与您要运行的 Linux 内核的版本相同或更早的版本。如果您使用的内核头文件比您在嵌入式系统上运行的 Linux 内核更新，那么 C 库可能正在使用 Linux 内核未提供的接口。
• 更改 GCC 编译器、binutils 和 C 库的版本。
• 选择一些工具链选项（仅限 uClibc）：工具链是否应具有 RPC 支持（主要用于 NFS）、宽字符支持、区域设置支持（用于国际化）、C++ 支持或线程支持。根据您选择的选项，Buildroot 菜单中可见的用户空间应用程序和库的数量将发生变化：许多应用程序和库需要启用某些工具链选项。大多数软件包在需要某个工具链选项才能启用这些软件包时都会显示注释。如果需要，您可以通过运行进一步优化 uClibc 配置make uclibc-menuconfig。但请注意，Buildroot 中的所有软件包都针对 Buildroot 中捆绑的默认 uClibc 配置进行了测试：如果您通过从 uClibc 中删除功能而偏离此配置，则某些软件包可能无法再构建。

值得注意的是，只要修改了其中一个选项，就必须重建整个工具链和系统。

该后端的优点：

• 与Buildroot完美集成
• 快速，仅构建必要的内容

此后端的缺点：

• 执行时需要重建工具链make clean，这需要时间。如果您想缩短构建时间，请考虑使用外部工具链后端。

外部工具链后端

外部工具链后端允许使用现有的预构建交叉编译工具链。Buildroot 了解许多著名的交叉编译工具链（来自 Linaro for ARM、 Sourcery CodeBench for ARM、x86-64、PowerPC 和 MIPS），并且能够自动下载它们，或者可以指向自定义工具链，可下载或本地安装。

然后，您有三种使用外部工具链的解决方案：

• 使用预定义的外部工具链配置文件，让 Buildroot 下载、提取和安装工具链。Buildroot 已经知道一些 CodeSourcery 和 Linaro 工具链。只需Toolchain从可用的工具链配置文件中选择即可。这绝对是最简单的解决方案。
• 使用预定义的外部工具链配置文件，但不是让 Buildroot 下载并提取工具链，而是可以告诉 Buildroot 您的工具链已安装在系统上的位置。只需在Toolchain可用的配置文件中选择工具链配置文件，取消选择Download toolchain automatically，然后 Toolchain path在文本条目中填写交叉编译工具链的路径即可。
• 使用完全自定义的外部工具链。这对于使用 crosstool-NG 或 Buildroot 本身生成的工具链特别有用。为此，请Custom toolchain在 Toolchain列表中选择解决方案。您需要填写Toolchain path、Toolchain prefix和External toolchain C library选项。然后，您必须告诉 Buildroot 您的外部工具链支持什么。如果您的外部工具链使用glibc库，您只需要告诉您的工具链是否支持 C++ 以及它是否具有内置的 RPC 支持。如果您的外部工具链使用uClibc 库，那么您必须告诉 Buildroot 它是否支持 RPC、宽字符、区域设置、程序调用、线程和 C++。在执行开始时，Buildroot 会告诉您所选选项是否与工具链配置不匹配。

外部工具链支持已使用 CodeSourcery 和 Linaro 的工具链、 crosstool-NG生成的工具链以及 Buildroot 本身生成的工具链进行了测试。一般来说，所有支持 sysroot功能的工具链都应该可以工作。

不支持 OpenEmbedded 或 Yocto 生成的工具链或 SDK，因为这些工具链不是纯工具链（即仅包含编译器、binutils、C 和 C++ 库）。相反，这些工具链附带了大量预编译库和程序。因此，Buildroot 无法导入工具链的sysroot，因为它将包含通常由 Buildroot 构建的数百兆预编译库。

也不支持使用发行版工具链（即发行版安装的 gcc/binutils/C 库）作为工具链来为目标构建软件。这是因为您的发行版工具链不是“纯”工具链（即仅包含 C/C++ 库），因此无法将其正确导入 Buildroot 构建环境。因此，即使您正在为 x86 或 x86_64 目标构建系统，您也必须使用 Buildroot 或 crosstool-NG 生成交叉编译工具链。

如果您想为您的项目生成一个自定义工具链，可以用作 Buildroot 中的外部工具链，建议使用 Buildroot 本身或 crosstool-NG 来构建它。

该后端的优点：

• 允许使用知名且经过充分测试的交叉编译工具链。
• 避免交叉编译工具链的构建时间，这在嵌入式Linux系统的整体构建时间中通常非常重要。

此后端的缺点：

• 如果您预先构建的外部工具链有错误，可能很难从工具链供应商那里获得修复，除非您使用 Buildroot 或 Crosstool-NG 自行构建外部工具链。

使用 Buildroot 构建外部工具链

Buildroot 内部工具链选项可用于创建外部工具链。以下是构建内部工具链并将其打包以供 Buildroot 本身（或其他项目）重用的一系列步骤。

创建一个新的 Buildroot 配置，其详细信息如下：

• 为您的目标 CPU 架构 选择适当的目标选项
• 在工具链菜单 中，保留 工具链类型的默认 Buildroot 工具链，并根据需要配置工具链
• 在系统配置菜单中，选择None作为初始化系统，并选择none作为/bin/sh
• 在目标包菜单中，禁用BusyBox
• 在文件系统映像菜单中，禁用tar 根文件系统

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

make sdk

这将生成 SDK 压缩包$(O)/images，其名称类似于 arm-buildroot-linux-uclibcgnueabi_sdk-buildroot.tar.gz。保存此压缩包，因为它现在是您可以在其他 Buildroot 项目中重新用作外部工具链的工具链。

在其他 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

外部工具链包装器

当使用外部工具链时，Buildroot 会生成一个包装程序，该程序透明地将适当的选项（根据配置）传递给外部工具链程序。如果您需要调试此包装器以准确检查传递了哪些参数，您可以将环境变量设置BR2_DEBUG_WRAPPER为以下任一项：

• 0，空或未设置：无调试
• 1： 在一行上跟踪所有参数
• 2：每行跟踪一个参数

/dev 管理

在 Linux 系统上，该目录包含称为设备文件 的/dev特殊文件 ，这些文件允许用户空间应用程序访问 Linux 内核管理的硬件设备。如果没有这些设备文件，即使 Linux 内核正确识别硬件设备，您的用户空间应用程序也无法使用硬件设备。

在System configuration下，/dev management，Buildroot 提供了四种不同的解决方案来处理/dev目录：

• 第一个解决方案是使用设备表的静态方法。这是在 Linux 中处理设备文件的旧经典方法。使用此方法，设备文件将持久存储在根文件系统中（即它们在重新启动后仍然存在），并且在系统中添加或删除硬件设备时，没有任何东西会自动创建和删除这些设备文件。因此，Buildroot 使用设备表创建一组标准的设备文件，默认设备表存储在system/device_table_dev.txt源代码中。当 Buildroot 生成最终的根文件系统映像时，会处理此文件，因此设备文件在output/target 目录中不可见。该 BR2_ROOTFS_STATIC_DEVICE_TABLE选项允许更改 Buildroot 使用的默认设备表，或添加额外的设备表，以便Buildroot 在构建期间创建额外的设备文件。因此，如果您使用此方法，并且系统中缺少设备文件，您可以为实例创建一个 board/<yourcompany>/<yourproject>/device_table_dev.txt 文件，包含其他设备文件描述，然后您可以对system/device_table_dev.txt
board/<yourcompany>/<yourproject>/device_table_dev.txt设置BR2_ROOTFS_STATIC_DEVICE_TABLE。
• 第二种解决方案是仅使用 devtmpfs 的动态方法。devtmpfs是Linux 内核中的虚拟文件系统，在内核 2.6.32 中引入（如果您使用旧内核，则无法使用此选项）。在/dev中安装时，这个虚拟文件系统将随着硬件设备的添加和从系统中删除，自动使设备文件出现和消失。此文件系统在重启后不是持久的：它由内核动态填充。使用devtmpfs需要启用以下内核配置选项： CONFIG_DEVTMPFS和CONFIG_DEVTMPFS_MOUNT。当 Buildroot 负责为您的嵌入式设备构建 Linux 内核时，它会确保启用这两个选项。但是，如果您在 Buildroot 之外构建 Linux 内核，那么您有责任启用这两个选项（如果您不这样做，您的 Buildroot 系统将无法启动）。
• 第三个解决方案是使用 devtmpfs + mdev 的动态解决方案。此方法也依赖于上面详述的devtmpfs虚拟文件系统（因此仍然需要在内核配置中启用CONFIG_DEVTMPFS和 CONFIG_DEVTMPFS_MOUNT ），但 mdev 在其上添加了用户空间实用程序。mdev 是 BusyBox 的一个程序部分，内核会在每次添加或删除设备时调用它。借助 /etc/mdev.conf 配置文件，mdev可以配置为设置设备文件的特定权限或所有权、在设备出现或消失时调用脚本或应用程序等。基本上，它允许用户空间对设备添加和删除事件做出反应。例如，mdev可用于在设备出现在系统中时自动加载内核模块。如果您的设备需要固件，这也很重要，因为它将负责将固件内容推送到内核。是 mdev的轻量级实现（功能较少）。
• 第四种解决方案是使用 devtmpfs + eudev 的动态解决方案。此方法也依赖于上面详述的devtmpfs+udev虚拟文件系统，但在其上添加了用户空间守护进程。eudev 是一个在后台运行的守护进程，当设备从系统中添加或删除时由内核调用。它是一个比 更重的解决方案mdev，但提供了更高的灵活性。 eudev是 的独立版本udev，是大多数桌面 Linux 发行版中使用的原始用户空间守护进程，现在是 Systemd 的一部分。有关更多详细信息，

Buildroot 开发人员的建议是从仅使用 devtmpfs 的动态解决方案开始，直到您需要在添加/删除设备时通知用户空间，或者需要固件时，在这种情况下，使用 devtmpfs + mdev 的动态通常是一个很好的解决方案。

注意，如果选择 systemd 作为 init 系统，/dev 管理将由udev提供的程序systemd执行。

初始化系统

init程序是内核启动的第一个用户空间程序（它的 PID 编号为 1），负责启动用户空间服务和程序（例如：Web 服务器、图形应用程序、其他网络服务器等）。

Buildroot 允许使用三种不同类型的 init 系统，可以从System configuration中选择：Init system：

• 第一个解决方案是BusyBox。在众多程序中，BusyBox 有一个基本init程序的实现，对于大多数嵌入式系统来说已经足够了。启用BR2_INIT_BUSYBOX将确保 BusyBox 将构建并安装其init程序。这是 Buildroot 中的默认解决方案。BusyBox的init程序将在启动时读取/etc/inittab文件以了解要做什么。该文件的语法可以在 http://git.busybox.net/busybox/tree/examples/inittab中找到（请注意，BusyBox的inittab语法很特殊：不要使用inittab 来自互联网的随机文档来了解 BusyBox inittab）。Buildroot inittab中的默认文件存储在中 package/busybox/inittab。除了挂载一些重要的文件系统之外，默认的 inittab 的主要工作是启动 /etc/init.d/rcS的shell 脚本，并启动一个getty程序（提供登录提示）。
• 第二种解决方案是systemV。此解决方案使用旧的传统sysvinit程序，该程序在 Buildroot 中打包 package/sysvinit。这是大多数桌面 Linux 发行版中使用的解决方案，直到他们转向 Upstart 或 Systemd 等较新的替代方案。sysvinit也可以使用inittab文件（其语法与 BusyBox 的语法略有不同）。inittab此 init 解决方案的默认安装位于package/sysvinit/inittab。
• 第三个解决方案是systemd。systemd它是新一代的 Linux 初始化系统。它的功能远远超过传统的初始化 程序：积极的并行化能力、使用套接字和 D-Bus 激活来启动服务、提供守护进程的按需启动、使用 Linux 控制组跟踪进程、支持快照和恢复系统状态等。systemd对于相对复杂的嵌入式系统非常有用，例如需要 D-Bus 和服务相互通信的系统。值得注意的是，systemd 带来了相当多的大型依赖项：dbus等等 。

Buildroot 开发人员推荐的解决方案是使用 BusyBox init，因为它对于大多数嵌入式系统来说已经足够了。systemd可用于更复杂的情况。