config.txt文件
什么是config.txt?
Raspberry Pi 设备使用名为 config.txt 的配置文件,而不是传统 PC 上的 BIOS。在 Arm CPU 和 Linux 初始化之前,GPU 会读取config.txt。Raspberry Pi OS 会在 boot 分区(位于 /boot/firmware/)中查找该文件。
您可以直接从 Raspberry Pi OS 安装中编辑 config.txt。也可以移除存储设备,在另一台电脑上编辑启动分区中的文件,包括 config.txt。
对 config.txt 的更改仅在重启后生效。可以使用以下命令查看当前活动设置:
vcgencmd get_config <config>:显示特定配置值,例如 vcgencmd get_config arm_freq.
vcgencmd get_config int:列出所有非零整数配置选项(非零)
vcgencmd get_config str:列出所有非空字符串配置选项
并非所有配置设置都能使用 vcgencmd 获取。
某些旧版 config.txt 选项已不再获得官方支持。这些选项列于 旧版 config.txt 选项 中,本文未作涵盖。
文件格式
config.txt 文件由早期启动固件读取,因此使用非常简单的文件格式: 每行只有一条 property=value 语句,其中 value 既可以是整数,也可以是字符串。可以添加注释,也可以用 # 字符开头一行,注释掉并禁用现有的配置值。
条目的行长限制为 98 个字符。Raspberry Pi OS 会忽略超过此限制的任何字符。
下面是一个文件示例:
# 启用音频(加载 snd_bcm2835)
dtparam=audio=on
# 为检测到的摄像头自动加载覆盖层
camera_auto_detect=1
# 为检测到的 DSI 显示器自动加载覆盖层
display_auto_detect=1
# 启用 DRM VC4 V3D 驱动程序
dtoverlay=vc4-kms-v3d
高级功能
包括
将指定文件的内容插入当前文件。
例如,在 config.txt 中添加 include extraconfig.txt 这一行,就会在 config.txt 文件中包含 extraconfig.txt 文件的内容。
bootcode.bin 或 EEPROM 引导加载程序不支持 include 指令。
由bootloader处理的设置只有在 config.txt 文件(而不是任何其他包含文件)中指定后才会生效:
bootcode_delaygpu_mem、gpu_mem_256、gpu_mem_512、gpu_mem_1024total_memsdram_freqstart_x、start_debug、start_file、fixup_fileuart_2ndstage
条件筛选
条件筛选器在条件部分有所介绍。
autoboot.txt
autoboot.txt 是一个可选配置文件,放置在初始启动分区中,可用于指定 boot_partition 编号。
该文件可与 tryboot 功能结合使用,为操作系统升级实现 A/B 启动。它是启动加载器和固件的原生能力,独立于第三方多启动管理器运行。
autoboot.txt 文件仅控制启动加载器选择哪个启动分区。构建一个有韧性、可用于生产的 A/B 更新系统,还需要专门的分区布局(例如冗余的启动 和根文件系统)以及更新工具。如需自动化方案,请参阅 A/B 启动更新 和 rpi-image-gen 工具。
autoboot.txt 文件支持 [all]、[none] 和 [tryboot] 条件筛选器。
另请参阅 TRYBOOT 启动流程。
boot_partition
指定用于启动的分区号,除非分区号已作为参数指定给 reboot 命令(例如 sudo reboot 2)。
分区号从 1 开始。指定分区 0 会指示启动加载器选择默认分区,该分区解析为第一个可启动的 FAT 分区(通常为分区 1)。
可启动分区必须格式化为 FAT12、FAT16 或 FAT32,并包含 start.elf 文件(或树莓派 5 上的 config.txt 文件),启动加载器才会将其归类为可启动分区。
与 cmdline.txt 及根文件系统选择的关系
启动加载器只读取 autoboot.txt 来定位目标启动分区。除了将 其参数传递给操作系统内核之外,它不会解析或处理 cmdline.txt。
根分区的选择(root=...)由内核通过 cmdline.txt 处理。在双槽 A/B 系统中,每个启动分区通常包含自己独立的 cmdline.txt 文件,指向其对应的根分区。或者,如果每个启动分区使用相同的文件,您可以在 config.txt 中使用 [boot_partition=N] 条件筛选器来选择备用的 cmdline.txt:
[boot_partition=2]
cmdline=cmdline_rootfs_a.txt
[boot_partition=3]
cmdline=cmdline_rootfs_b.txt
tryboot_a_b
将此属性设为 1,可在设置 tryboot 标志时加载正常的 config.txt 和 boot.img 文件,而不是 tryboot.txt 和 tryboot.img。
这样就能在分区级而非文件级进行 tryboot 切换,而无需修改 A/B 分区中的配置文件。
A/B 启动的更新流程示例
考虑如下 A/B 分区布局:
- 分区 1(FAT): 包含
autoboot.txt的初始启动加载器分区。 - 分区 2(FAT): 槽位 A 启动分区(
boot_partition=2),包含固件、内核以及指向 Root A 的cmdline.txt。 - 分区 3(FAT): 槽位 B 启动分区(
boot_partition=3),包含固件、内核以及指向 Root B 的cmdline.txt。 - 分区 4: 槽位 A 根文件系统分区(Root A)。
- 分区 5: 槽位 B 根文件系统分区(Root B)。
- 分区 6: 可选的持久数据分区。
初始 autoboot.txt:
[all]
tryboot_a_b=1
boot_partition=2
[tryboot]
boot_partition=3
安装更新
系统默认启动到分区 2。随后,一个假设的更新服务:
-
将下一版本的操作系统安装到分区 3(及其对应的根分区)。
-
通过执行 tryboot 重启来测试更新:
sudo reboot "0 tryboot"
提交或取消更新
系统会从分区 3 启动,因为 autoboot.txt 中的 [tryboot] 筛选器求值为 true。
如果 tryboot 处于活动状态(/proc/device-tree/chosen/bootloader/tryboot 等于 1),并且我们已从 tryboot 分区启动(/proc/device-tree/chosen/bootloader/partition 与 autoboot.txt 的 [tryboot] 部分中设置的 boot_partition 相匹配):
- 该假设的更新服务随后会验证系统健康状况。
- 如果成功: 更新
autoboot.txt,交换默认分区与 tryboot 分区,从而提交更新。 - 如果失败: 在不更改
autoboot.txt的情况下执行正常重启。tryboot标志会自动清除,使系统回退到从分区 2 启动。
- 如果成功: 更新
提交后更新过的 autoboot.txt:
[all]
tryboot_a_b=1
boot_partition=3
[tryboot]
boot_partition=2
位于 /proc/device-tree/chosen/bootloader/ 下的属性(例如 tryboot 和 partition)以原始 32 位大端二进制整数形式存储。使用 cat 等工具查看它们会产生不可打印字符或显示为空。要在 shell 脚本中读取这些整数值,请使用:
printf "%d\n" "0x$(od /proc/device-tree/chosen/bootloader/tryboot -v -An -t x1 | tr -d ' ')"