Buildroot

分类于 阅读次数： Disqus： 本文字数： 1.3k 阅读时长 ≈ 5 分钟

Buildroot 配置

交叉编译工具链

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

  • 内部工具链后端，在配置界面中调用“Buildroot toolchain”
  • 外部工具链后端，在配置界面中调用“External toolchain“；有三种方式来使用外部工具链：
    • 让 Buildroot 基于预定义的外部工具链 profile 自动下载、安装。在 Toolchain 中选择已有的 profile 即可
    • 为 Buildroot 手动指定提前安装好的、预定义了 profile 的工具链。在 Toolchain 中选择 profile 后，反选掉 Download toolchain automatically 并在 Toolchain path 中填写已有工具链路径即可
    • 使用定制的外部工具链。通常用于使用 crosstool-NG 或 Buildroot 生成的已有定制工具链。选择 Toolchain 列表中的 Custom toolchain ，然后填写 Toolchain path, Toolchain prefix, External toolchain C librrary 选项。若外部工具链使用 glibc 库，只需要选择工具链是否支持 C++ 以及是否内建 RPC 支持即可。如果使用 uClibc 库，则还有宽字符、本地化、程序 invocation、线程支持等选项

Buildroot 不支持由 OpenEmbedded、Yocto 支持的工具链，因为这些工具生成的工具链并不是单纯的工具链——它们除了编译器、binutils、C/C++ 库之外还加了一大堆预编译的库和程序。因此 Buildroot 并没有办法导入它们的 sysroot 。Buildroot 也不支持发行版提供的工具链，这些工具链包含的东西也比较复杂，所以无法加载到构建环境中。

/dev 管理

  • 第一种方式是“Static using device table”
    设备文件会被持久存储在根文件系统中（即重新启动后它们仍然存在），并且在系统添加或者移除硬件设备时，不能自动创建和删除这些设备文件。

  • 第二种方式是“Dynamic using devtmpfs only”
    使用 devtmpfs 时需要启用以下内核配置选项：CONFIG_DEVTMPFS 和 CONFIG_DEVTMPFS_MOUNT。

  • 第三种方式是“Dynamic using devtmpfs+mdev”
    每次添加或移除设备时，内核都会调用 mdev。由于使用/etc/mdev.conf 配置文件，因此 mdev 可以进行相关配置，例如给设备文件设置特定的权限或所有权、在设备出现或消失时调用脚本或应用程序等等

  • 第四种方式是“Dynamic using devtmpfs+eudev”
    eudev 是后台运行的守护程序，当系统添加或者移除设备时，内核将会调用它。与 mdev 相比，它是重量级的解决方案，但是具有更高的灵活性。eudev 是 udev 的独立版本

初始化系统

  • 第一种是“BusyBox”：BusyBox init 程序会在启动时去读取/etc/inittab 文件
  • 第二种是“systemV”：Sysvinit 同样使用 inittab 文件（其语法与 BusyBox 中的语法略有不同）
  • 第三种是“systemd”：systemd 是用于 Linux 的新一代 init 系统。它的功能远远超过传统的 init 程序：强大的并行处理能力、使用 socket 和 D-Bus 激活启动服务、按需启动守护程序、使用 Linux 控制组跟踪进程、支持对系统状态进行快照和还原等等。

ildroot一般用法

目录树外构建

1
cd /tmp/build; make O=$PWD -C path/to/buildroot

注意：“O”指定的路径可以是绝对路径，也可以是相对路径，但如果是相对路径，则需要注意，它是相对于 Buildroot 的主目录而不是当前工作目录。

1
2
3
4
5
6
7
8
9
10
11
12
13
#! /bin/bash

CURRENT_DIR=$(cd $(dirname $0); pwd)
make O=${CURRENT_DIR}/output -C ./Buildroot-2023.11/ stm32mp157_pro_ddr512m_systemV_core_defconfig

# 生成构建软件包依赖关系图
make graph-depends

# 生成构建时间图
make graph-build

# 绘制软件包对文件系统大小贡献图
make graph-size

在开发期间使用 Buildroot

问题：直接在 output/build/-中进行修改是不合适的，因为在“make clean”时会删除该目录。

解决办法：Buildroot 针对此场景提供了一种特定的机制：_OVERRIDE_SRCDIR 机制。Buildroot 会读取 override 文件，而该文件可以让用户告诉 Buildroot 某些软件包的源码位置

override 文件的默认位置是\((CONFIG_DIR)/local.mk，由 BR2_PACKAGE_OVERRIDE_FILE 配置选项定义。\)(CONFIG_DIR)是 Buildroot 中.config 文件的位置，因此默认情况下，local.mk 与.config 文件在同一个目录下，这意味着： • 在目录树内构建的 Buildroot 源码顶级目录中（即不使用“O=”时） • 在目录树外构建的“O”参数指定的目录中（即使用“O=”时） 如果需要的位置与默认位置不同，则可以通过 BR2_PACKAGE_OVERRIDE_FILE 配置选项指定该位置。在该 override 文件中，Buildroot 希望找到以下形式的参数行：

1
2
<pkg1>_OVERRIDE_SRCDIR = /path/to/pkg1/sources
<pkg2>_OVERRIDE_SRCDIR = /path/to/pkg2/sources

例如：

1
2
LINUX_OVERRIDE_SRCDIR = /home/bob/linux/
BUSYBOX_OVERRIDE_SRCDIR = /home/bob/busybox/

当 Buildroot 发现指定软件包已经定义了_OVERRIDE_SRCDIR 时，它将不再尝试下载、提取和修补软件包。取而代之的是，它将直接使用指定目录中可用的源代码，并且使用“make clean”时不会删除该目录。

此机制最好与 make -rebuild 和 make -reconfigure 目标结合使用。make -rebuild all 将使源代码从_OVERRIDE_SRCDIR 同步到 output/build/-custom（由于 rsync，它仅复制修改过的文件），然后重新启动该软件包的构建过程。

在上述 linux 软件包示例中，开发人员可以在/home/bob/linux 中更改源代码，然后运行：

1
make linux-rebuild all

特定项目的定制

...