3. Zephyr RTOS基础：设备树、内核配置、构建系统（CMake/West）等必备知识

Bootloader 的本质是"最小化的系统启动代码"，但在 Zephyr 生态中，它并不是孤立存在的。Zephyr 的 Bootloader（如 MCUboot）与普通应用程序共享同一套基础设施：设备树描述硬件、Kconfig 裁剪功能、CMake/West 驱动构建。如果这三块知识不扎实，开发 Bootloader 时往往会遇到"配置改了不生效""设备树节点找不到""链接脚本报错"等无从下手的问题。本章将围绕这三块核心知识展开，帮助读者建立从硬件描述到构建产物的完整认知链路，为后续编写和移植 Bootloader 打下坚实基础。

3.1 设备树：硬件资源的"活地图"

3.1.1 核心原理：从硬件描述到 C 代码

设备树（Device Tree）是一种描述硬件资源的数据结构，它独立于操作系统存在。在 Zephyr 中，设备树文件（.dts/.dtsi）经过预处理和编译后，会生成两个关键产物：DTB（Device Tree Blob） 和 devicetree.h 头文件。前者用于运行时解析（较少见），后者在编译期直接生成宏定义，供驱动代码和 Bootloader 代码直接引用。

设备树的核心语法包括：节点（Node）、属性（Property）、单元地址（Unit Address） 和 标签（Label）。例如，描述一个 UART 外设：

/ {
    soc {
        uart0: serial@40001000 {
            compatible = "ns16550";
            reg = <0x40001000 0x1000>;
            interrupts = <5 0>;
            clock-frequency = <1843200>;
            status = "okay";
        };
    };
};

其中 uart0 是标签（Label），serial@40001000 是节点名和单元地址，compatible 属性用于驱动匹配，reg 描述寄存器地址和长度。Zephyr 会为每个带标签的节点生成类似 DT_NODELABEL_UART0 的宏，Bootloader 中可以直接使用 DEVICE_DT_GET(DT_NODELABEL_UART0) 获取设备实例。

3.1.2 判断方法与操作流程：如何正确添加和修改节点

在 Bootloader 开发中，最常见的需求是：调整 Flash 分区、配置外部 Flash 芯片、修改时钟频率。操作流程如下：

1. 定位板级文件：在 boards/<arch>/<board_name>/<board_name>.dts 中查看板级设备树。
2. 确认 SoC 级文件：dts/<arch>/<soc>/<soc>.dtsi 定义了 SoC 内部外设。
3. 使用 overlay 文件：对于 Bootloader 项目，推荐使用 <board>.overlay 文件，避免修改原始 dts 文件，便于维护。
4. 验证节点状态：通过 status = "okay" 或 "disabled" 控制外设是否启用。
5. 编译检查：构建后查看 build/zephyr/include/generated/devicetree.h 确认宏是否生成。

3.1.3 案例拆解：为 Bootloader 配置外部 SPI Flash 分区

假设我们使用 nRF52840 开发板，需要为 MCUboot 配置外部 SPI Flash（如 MX25R6435F）作为固件存储区。初始现象是：Bootloader 无法识别外部 Flash，日志显示 spi_flash: device not found。分析过程如下：

• 检查设备树：发现 spi1 节点状态为 disabled，且缺少外部 Flash 子节点。
• 添加 overlay 配置：

/ {
    chosen {
        zephyr,console = &uart0;
    };
};

&spi1 {
    status = "okay";
    cs-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
    mx25r6435f: mx25r6435f@0 {
        compatible = "jedec,spi-nor";
        reg = <0>;
        spi-max-frequency = <8000000>;
        size = <0x4000000>;  /* 64 Mbit = 8 MB */
        sector-size = <0x1000>;
    };
};

&flash0 {
    partitions {
        compatible = "fixed-partitions";
        #address-cells = <1>;
        #size-cells = <1>;
        boot_partition: partition@0 {
            label = "mcuboot";
            reg = <0x0 0x10000>;
        };
        slot0_partition: partition@10000 {
            label = "image-0";
            reg = <0x10000 0x40000>;
        };
    };
};

• 重新构建：执行 west build -b nrf52840dk_nrf52840 -- -DOVERLAY_CONFIG=overlay-mcuboot.conf。
• 结果对比：构建成功后，devicetree.h 中生成 DT_NODELABEL_MX25R6435F，Bootloader 代码中通过 DT_NODELABEL_MX25R6435F 即可访问该设备。

3.1.4 常见误区与总结复盘

设备树是 Bootloader 开发中"最容易出错但最难排查"的部分。建议每次修改后，先编译生成 devicetree.h，用 grep 确认关键宏是否存在，再进入代码调试阶段。

3.2 内核配置（Kconfig）：功能裁剪的"开关面板"

3.2.1 核心原理：符号系统与依赖关系

Kconfig 是 Zephyr 的配置系统，它通过 符号（Symbol） 控制内核和组件的编译行为。每个符号有类型（bool、int、string）、默认值、依赖关系（depends on）和反向依赖（select）。配置结果最终生成 autoconf.h 头文件，C 代码中通过 CONFIG_XXX 宏判断功能是否启用。

对于 Bootloader 而言，Kconfig 的意义在于：最小化功能集。例如，MCUboot 不需要完整的 POSIX 文件系统，只需要 Flash 驱动、加密算法和简单的日志输出。通过 Kconfig 裁剪，可以显著减小固件体积和启动时间。

3.2.2 操作流程：如何配置 Bootloader 项目

1. 创建 prj.conf：在 Bootloader 项目根目录创建 prj.conf，写入需要的配置项。
2. 使用 defconfig：对于多板卡支持，可以在 boards/ 目录下为每个板卡创建 <board>_defconfig。
3. 配置碎片（fragments）：通过 -- -DOVERLAY_CONFIG=xxx.conf 叠加配置，适合不同场景切换。
4. 查看配置结果：构建后查看 build/zephyr/.config 文件，确认最终生效的配置。
5. 使用 menuconfig：执行 west build -t menuconfig 进行图形化配置，适合探索性开发。

3.2.3 案例拆解：裁剪 MCUboot 的日志与加密选项

场景：某 IoT 产品使用 MCUboot 进行固件升级，但 Flash 空间紧张（仅 32KB 分配给 Bootloader）。初始构建产物为 48KB，超出限制。关键输入数据：CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y、CONFIG_LOG=y、CONFIG_BOOT_UPGRADE_ONLY=y。分析过程：

• 查看空间占用：west build -t ram_report 和 west build -t rom_report 发现日志系统占用约 8KB，加密库占用约 12KB。
• 优化措施：

# prj.conf 优化
CONFIG_LOG=y
CONFIG_LOG_MODE_IMMEDIATE=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_USE_MBEDTLS=n
CONFIG_BOOT_USE_TINYCRYPT=y
CONFIG_BOOT_UPGRADE_ONLY=y
CONFIG_BOOT_SWAP_USING_MOVE=y

• 结果对比：关闭 UART 日志后端后，日志功能保留但不再输出到串口，节省 4KB；切换 TinyCrypt 替代 mbedTLS，节省 6KB。最终固件体积降至 31KB，满足要求。

3.2.4 常见误区与总结复盘

Kconfig 的调试技巧：当某个配置不生效时，优先检查 build/zephyr/.config 中该符号的值，再向上追溯依赖链。使用 west build -t guiconfig 可以可视化查看依赖关系。

3.3 构建系统（CMake/West）：工程组织的"流水线"

3.3.1 核心原理：West 与 CMake 的分工

West（Zephyr's meta-tool）负责项目管理、多仓库拉取和命令调度；CMake 负责实际的编译、链接和生成产物。两者通过 west build 命令串联：West 解析 west.yml 中的项目清单，调用 CMake 配置和构建。

Bootloader 项目的典型目录结构：

my_bootloader/
├── CMakeLists.txt
├── prj.conf
├── src/
│   └── main.c
├── boards/
│   └── my_board.overlay
└── west.yml

其中 CMakeLists.txt 是构建入口，通过 find_package(Zephyr) 引入 Zephyr 构建系统。Zephyr 的 CMake 模块会自动处理设备树编译、Kconfig 解析、链接脚本生成等复杂流程。

3.3.2 操作流程：从零构建一个 Bootloader 项目

1. 初始化工作区：west init -m https://github.com/zephyrproject-rtos/zephyr --mr v3.5.0
2. 更新子模块：west update
3. 创建项目：在 app/ 目录下创建 CMakeLists.txt 和 prj.conf。
4. 构建：west build -b <board> -d build
5. 烧录：west flash

对于 Bootloader 开发，推荐使用 west build -t runner 查看可用的烧录方式，或使用 west build -t flash 直接烧录。

3.3.3 案例拆解：为自定义板卡添加 CMake 支持

场景：团队设计了一款基于 STM32F407 的自定义板卡，需要将 MCUboot 移植到该板卡。初始现象：west build -b my_board 报错 Board not found。分析过程：

• 创建板卡目录：在 boards/arm/my_board/ 下创建 my_board.dts、my_board_defconfig、board.cmake、Kconfig.board、Kconfig.defconfig。
• 编写 board.cmake：

include(${ZEPHYR_BASE}/boards/common/openocd.board.cmake)
board_set_flasher_ifnset(openocd)
board_set_flasher(openocd)
board_set_openocd_target_ifnset(stm32f4x)

• 修改 CMakeLists.txt：在项目根目录添加 list(APPEND BOARD_ROOT ${CMAKE_CURRENT_SOURCE_DIR}/boards)。
• 重新构建：west build -b my_board 成功生成 zephyr.elf。

3.3.4 常见误区与总结复盘

构建系统的核心价值在于可重复性。建议将 west.yml 锁定到具体版本（如 v3.5.0），并在 CI 中使用相同的构建命令，确保不同开发者产出完全一致的固件。