Buildroot

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 pathToolchain prefixExternal 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

特定项目的定制

...