嵌入式系统启动流程基础：CPU 复位、向量表、链接脚本、启动代码、Bootloader 与应用程序的关系
嵌入式系统的启动流程是理解 Bootloader 工作原理的基石。无论是 ARM Cortex-M 系列 MCU，还是 RISC-V、x86 架构处理器，上电后都必须经历一条从硬件复位到软件主函数的固定路径。这条路径涉及 CPU 复位行为、向量表解析、链接脚本对内存布局的约束、启动代码对运行环境的初始化，以及最终 Bootloader 与应用程序之间的交接关系。本章将逐层拆解这些核心概念，并揭示它们如何协同工作，为后续深入 Zephyr Bootloader 的移植与调试打下坚实基础。
CPU 复位行为与向量表机制
核心原理
CPU 复位是启动流程的物理起点。以 ARM Cortex-M 为例，复位后处理器从 0x00000000 地址读取初始栈指针（MSP），从 0x00000004 地址读取复位向量（Reset_Handler 地址）。这两个地址位于向量表的最前端。向量表本质上是一个地址数组，按异常号顺序存放各异常服务函数的入口地址。Cortex-M 的向量表偏移量由 SCB->VTOR 寄存器控制，这为 Bootloader 跳转 App 后重定位向量表提供了硬件基础。
对于 Cortex-A 或 RISC-V 架构，复位流程略有不同：Cortex-A 通常从固定地址（如 0x00000000 或 0xFFFF0000）取第一条指令；RISC-V 则根据 mtvec 寄存器指向的地址开始执行。理解这些差异对跨架构移植 Zephyr 至关重要。
判断方法与操作流程
在实际调试中，可通过以下步骤确认复位行为是否正确：
- 使用调试器（如 J-Link、OpenOCD）连接目标板，复位后暂停 CPU。
- 检查 PC 寄存器是否指向 Reset_Handler 对应的地址。
- 检查 MSP 是否等于链接脚本中定义的
_stack_top值。 - 若 PC 指向 0xFFFFFFFF 或异常地址，说明向量表未正确烧录或链接脚本内存布局有误。
CONFIG_TEXT_SECTION_OFFSET 和 CONFIG_ROM_START_OFFSET 会影响向量表在 Flash 中的位置。修改这些配置后，务必重新生成链接脚本并确认向量表对齐到 128 字节（Cortex-M 要求）或 256 字节（部分 Cortex-M7）。案例拆解：复位后 PC 跑飞问题
某产品使用 STM32F427（Cortex-M4），烧录 Zephyr 固件后上电，程序无法进入 main。调试器显示 PC = 0x08000000，但该地址存放的是向量表而非可执行代码。分析发现，链接脚本中 ROM_START 被设置为 0x08000000，但向量表首字（初始 SP）被错误地放置为 0x00000000，导致 CPU 复位后从 0x00000000 读取 SP 失败。修正方法是在链接脚本中显式定义 _vector_start 符号，并确保 KEEP(*(.isr_vector)) 段被放置在 Flash 起始地址。
常见误区与复盘
- 误区一：认为所有 CPU 复位后都从 0x00000000 执行。实际上 Cortex-M 是取向量，而 Cortex-A/RISC-V 是取指令。
- 误区二：忽略向量表对齐要求。Cortex-M 的 VTOR 寄存器低 7 位必须为 0，否则硬件异常。
- 复盘：复位问题排查应首先确认硬件上电时序（NRST 引脚、电源稳定时间），再检查软件向量表，最后才考虑外部看门狗干扰。
链接脚本：内存布局的蓝图
核心原理
链接脚本（Linker Script）定义了目标文件中的段（Section）如何映射到目标芯片的物理内存。对于嵌入式系统，最关键的是 ROM（Flash） 和 RAM 的地址范围划分。Zephyr 使用 zephyr.ld 作为默认链接脚本模板，它通过 include 机制引入 SoC 级和板级的内存配置。典型布局如下：
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.text : { *(.text*) *(.rodata*) } > FLASH
.data : { *(.data*) } > RAM AT > FLASH
.bss : { *(.bss*) } > RAM
}其中 .data 段使用 AT> FLASH 表示加载地址在 Flash，运行地址在 RAM，启动代码需要将其从 Flash 拷贝到 RAM。
判断方法与操作流程
检查链接脚本是否正确，可执行以下操作：
- 编译后查看
build/zephyr/zephyr.map文件，确认各段地址符合预期。 - 使用
arm-none-eabi-size查看各段大小，判断是否溢出。 - 若使用 Zephyr 的
west build，可通过CONFIG_ROM_SIZE和CONFIG_RAM_SIZE覆盖 SoC 默认值。
| 段名 | 存储位置 | 内容 | 初始化责任 |
|---|---|---|---|
| .text | Flash | 代码、只读常量 | 无需初始化 |
| .rodata | Flash | 字符串、const 变量 | 无需初始化 |
| .data | RAM（加载在 Flash） | 已初始化全局变量 | 启动代码从 Flash 拷贝 |
| .bss | RAM | 未初始化全局变量 | 启动代码清零 |
| .heap | RAM | 动态内存池 | 可选，由 libc 管理 |
| .stack | RAM 顶部 | 栈空间 | 由链接脚本分配，启动代码设置 SP |
案例拆解：Bootloader 与 App 的链接脚本隔离
在 Zephyr 的 MCUboot 方案中，Bootloader 和 App 使用不同的链接脚本。Bootloader 链接脚本将 Flash 起始地址设为 0x08000000，长度 64KB；App 链接脚本则设为 0x08010000，长度 960KB。关键操作包括：
- 在 App 的
prj.conf中设置CONFIG_TEXT_SECTION_OFFSET=0x10000。 - 在链接脚本中定义
__app_flash_start符号供 Bootloader 跳转时使用。 - App 编译时需指定
-Wl,-T,app.ld以使用独立链接脚本。
这种隔离确保了 Bootloader 升级 App 时不会覆盖自身代码，同时 App 的向量表可以独立重定位。
常见误区与复盘
- 误区一：在链接脚本中随意修改 ORIGIN 而不更新 Bootloader 的跳转地址，导致跳转后 HardFault。
- 误区二：忘记为 .data 段添加
AT> FLASH，导致启动代码从 RAM 地址读取初始值（此时 RAM 未初始化，数据随机）。 - 复盘：每次修改内存布局后，应同时检查 map 文件、反汇编文件（.lst）和实际运行时内存内容，三者一致才能确认链接脚本正确。
启动代码：从汇编到 C 世界的桥梁
核心原理
启动代码（Startup Code）是复位后执行的第一段软件，通常用汇编编写。其核心任务包括：
- 设置初始栈指针（若硬件未自动加载）。
- 初始化 .data 段（从 Flash 拷贝到 RAM）。
- 清零 .bss 段。
- 调用
SystemInit()（可选，用于时钟配置）。 - 跳转到
main()或 Zephyr 的z_cstart()。
在 Zephyr 中，启动代码位于 arch/arm/core/cortex_m/prep_c.c 和 reset.S。Zephyr 使用 z_arm_reset 作为复位入口，随后调用 z_cstart() 完成内核初始化。
判断方法与操作流程
验证启动代码是否正常执行，可以通过以下方式：
- 在
reset.S的bl z_cstart处设置断点，观察是否到达。 - 检查 .data 段拷贝前后的 RAM 内容，确认拷贝方向正确。
- 使用 Zephyr 的
CONFIG_BOOT_DELAY和CONFIG_BOOT_BANNER打印启动信息，辅助定位卡死位置。
bss clear 循环。案例拆解：Zephyr 启动代码中的栈检查
Zephyr 在 z_cstart() 之前会调用 z_arm_init_cpu 和 z_arm_init_hw。某项目在启动时进入 HardFault，通过 RTT 日志发现 z_arm_init_hw 中访问了未使能的 GPIO 外设。原因是启动代码未配置 GPIO 时钟。解决方法是检查 SoC 的 clock_control 驱动是否在 z_arm_init_hw 之前被调用，或在 prj.conf 中启用 CONFIG_CLOCK_CONTROL=y。
常见误区与复盘
- 误区一：在启动代码中过早调用依赖堆栈的函数，而堆栈尚未设置完成。
- 误区二：使用 C 语言编写启动代码时，编译器可能插入对
memset等库函数的调用，而这些函数本身依赖 .bss 段，形成循环依赖。 - 复盘：启动代码应保持极简，只做必要的硬件初始化和内存准备，其余功能推迟到 main 中执行。
Bootloader 与应用程序的关系
核心原理
Bootloader 与应用程序（App）是嵌入式系统中两个独立的固件镜像，它们共享同一颗芯片但运行在不同的 Flash 分区。Bootloader 负责硬件初始化、固件校验、升级流程，最终跳转到 App。App 则专注于业务功能。两者通过 分区表 和 跳转协议 协作。Zephyr 的 MCUboot 是当前最主流的开源 Bootloader，它定义了镜像头、签名算法和升级策略。
判断方法与操作流程
设计 Bootloader 与 App 的交互时，需明确以下决策点：
- 跳转条件：Bootloader 在何种情况下跳转 App？通常为：无升级请求、App 签名校验通过、App 起始地址合法。
- 向量表重定位：App 启动后需将 VTOR 指向自身向量表，否则中断无法响应。
- 共享资源交接：Bootloader 初始化的外设（如 UART、Flash）是否需要关闭或保持？
| 对比维度 | Bootloader | 应用程序 |
|---|---|---|
| Flash 起始地址 | 0x08000000（典型） | 0x08010000（典型） |
| 向量表位置 | Flash 起始处 | App 分区起始处 |
| 中断处理 | 使用自身向量表 | 跳转后重定位 VTOR |
| 升级能力 | 支持固件下载、校验、回滚 | 通常不具备升级能力 |
| 运行周期 | 上电后短暂运行 | 长期运行 |
案例拆解：MCUboot 跳转 App 的完整流程
以 nRF52840 为例，MCUboot 跳转 App 的典型流程如下：
- MCUboot 启动，初始化时钟、Flash 和 UART（用于日志）。
- 读取分区表，定位 primary slot 中的 App 镜像头。
- 验证镜像签名（ECDSA P-256）和 SHA256 哈希。
- 若校验通过，关闭中断，设置 VTOR 为 App 向量表地址。
- 将 MSP 设置为 App 向量表首字，PC 跳转到 App 的 Reset_Handler。
关键代码片段（Zephyr MCUboot 的 boot_go() 函数）：
static void do_boot(struct boot_rsp *rsp)
{
uintptr_t flash_base;
uintptr_t img_base;
uintptr_t sp;
uintptr_t pc;
flash_base = rsp->br_flash_dev->drv->base_addr;
img_base = flash_base + rsp->br_image_off;
sp = *(uintptr_t *)img_base;
pc = *(uintptr_t *)(img_base + 4);
sys_arch_reboot(0);
__set_MSP(sp);
((void (*)(void))pc)();
}这段代码展示了从读取向量表到跳转的完整过程。注意 sys_arch_reboot(0) 用于关闭外设和中断，避免 App 启动时受到残留状态干扰。
常见误区与复盘
- 误区一：跳转前未关闭全局中断，导致 App 启动过程中被旧中断打断。
- 误区二：App 链接脚本的向量表地址与 Bootloader 跳转地址不一致，导致 PC 跳转到错误位置。
- 误区三：Bootloader 和 App 使用不同的时钟配置，跳转后外设波特率或时序异常。
- 复盘：建议在 Bootloader 跳转前执行
__disable_irq()，并在 App 启动代码中重新配置所有外设时钟。同时，使用CONFIG_APP_LINK_OFFSET确保 App 编译时知道自身在 Flash 中的偏移。