📚 课程目录第4章 MCX启动头与镜像格式

4. MCX启动头与镜像格式

MCX系列MCU上电后，Boot ROM会按固定规则去读取外部存储介质中的启动镜像。这个镜像并不是裸的应用程序二进制，而是一个带有启动头（Boot Header）、镜像向量表（IVT）、启动数据（Boot Data）和器件配置数据（DCD）的结构化容器。理解这套格式，是后续做固件升级、双镜像切换、签名校验和量产烧录的基础。本节从镜像的字节布局讲起，再说明各字段的作用，最后给出用工具链生成镜像的实际过程。

一、启动镜像的整体布局

MCX的启动镜像通常由四个连续区域组成，按地址从低到高排列：Boot Header、IVT、Boot Data、DCD，之后才是真正的应用程序镜像（Application Image）。Boot ROM在复位后先读取Boot Header，从中获得IVT的偏移和长度，再跳转到IVT解析入口地址、镜像长度和DCD位置，最后按DCD完成外设初始化，再把控制权交给应用程序入口。

需要特别注意的是，Boot Header本身不包含入口地址，它只负责“指路”。真正的入口地址、镜像大小、DCD地址都记录在IVT中。这种分层设计让Boot ROM的解析逻辑保持简单，同时允许镜像在存储介质中灵活摆放。

二、Boot Header：镜像的入口标签

Boot Header位于镜像最前端，Boot ROM首先读取它。它包含一个固定的tag值（用于识别这是合法的启动镜像）、头部长度、IVT的相对偏移以及一组flags。tag不匹配时，Boot ROM会认为该介质上没有可启动镜像，转而尝试下一个启动源。flags中常见的有是否启用DCD、是否要求加密启动等位域。

Boot Header的长度通常是固定的，例如16字节或32字节，具体取决于芯片系列。它的存在让Boot ROM不必假设IVT一定紧跟在头部之后，而是通过偏移字段灵活定位。实际工程中，如果手工拼接镜像，最容易出错的地方就是IVT偏移写错，导致Boot ROM读到无效数据。

三、IVT：镜像向量表

IVT是启动镜像的核心索引表，通常为32字节，包含8个32位字段：header、entry、reserved、dcd_ptr、boot_data_ptr、self、csf、reserved。其中：

header：IVT自身的标签和长度，用于校验。
entry：应用程序入口地址，Boot ROM最终跳转到这里。
dcd_ptr：DCD在镜像中的地址，为0表示没有DCD。
boot_data_ptr：Boot Data的地址。
self：IVT自身的地址，用于自校验和重定位。
csf：命令序列文件地址，用于安全启动时的签名校验。

entry字段是链接脚本和镜像生成工具共同决定的。例如应用程序链接到0x20000000，那么entry就应写0x20000000。如果entry指向了未初始化或未加载的区域，Boot ROM跳转后就会取到非法指令，表现为启动即HardFault。

四、Boot Data：镜像范围描述

Boot Data通常为12字节，包含start、length和plugin三个字段。start表示镜像在存储介质中的起始地址，length表示镜像总长度，plugin用于特殊启动模式。Boot ROM用start和length来确定需要加载或校验的字节范围。如果length偏小，应用程序尾部可能没有被完整加载；如果偏大，可能把无关数据当作镜像内容。

在固件升级场景中，Boot Data的length字段尤其重要。升级工具需要根据它判断新镜像是否完整写入，以及是否需要回滚。一个常见的做法是：在镜像末尾附加CRC或哈希，升级完成后由Bootloader重新计算并比对，而Boot Data的length则用于界定计算范围。

五、DCD：器件配置数据

DCD是一段由命令组成的配置脚本，Boot ROM在跳转到应用程序之前会逐条执行。它的典型用途是初始化外部DDR、配置时钟、设置引脚复用等。DCD命令通常包括：写寄存器（Write）、延时（Delay）、检查寄存器（Check）等。每条命令带有目标地址、掩码和值。

例如，要让MCX在启动阶段把某个时钟控制寄存器的分频值设为2，可以写一条Write命令：地址为时钟控制寄存器，值为对应分频编码。如果DDR初始化需要等待锁相环稳定，则在写命令之后插入Delay命令。Check命令用于确认某个状态位已经置位，若检查失败，Boot ROM会中止启动。

DCD 命令示例（示意）：
Write  0x40064000 = 0x00000002   // 设置时钟分频
Delay  100                        // 等待100个周期
Check  0x40064004, 0x00000001     // 检查PLL锁定位
Write  0x400A0000 = 0x12345678   // 配置DDR控制器

DCD不是必须的。如果应用程序运行在内部Flash且不需要外部DDR，可以省略DCD，此时IVT中的dcd_ptr写0。但一旦应用程序链接到外部DDR地址，DCD就必须存在，否则Boot ROM跳转时DDR尚未初始化，取指会失败。

六、镜像生成工具链

手工拼接上述结构容易出错，NXP提供了镜像生成工具，常见的是elftosb和mkimage类工具。典型流程是：先用编译器生成ELF文件，再用objcopy转成二进制，然后由镜像工具把Boot Header、IVT、Boot Data、DCD和应用程序二进制按顺序打包成最终镜像。

以elftosb为例，需要先编写一个描述文件（.bd或.commands），在其中指定输出镜像名、目标芯片、入口地址、DCD文件路径和输入二进制。工具读取描述文件后，自动计算各段偏移并填充IVT中的指针字段。生成完成后，可以用hexdump查看镜像头部，确认tag、entry和length是否符合预期。

# 生成应用程序二进制
arm-none-eabi-objcopy -O binary app.elf app.bin

# 使用elftosb打包镜像
elftosb -f mcx -c app.bd -o app_image.bin

# 查看镜像头部，确认Boot Header与IVT
hexdump -C app_image.bin | head -n 8

生成后建议做一次“反向检查”：从镜像中读出IVT的entry字段，确认它等于链接脚本中的入口地址；读出boot_data的length，确认它等于镜像文件实际大小减去头部区域。如果这两个值不一致，说明描述文件或链接脚本有误，需要回到工具链配置中修正。

在量产烧录前，建议把Boot Header、IVT、Boot Data的关键字段做成一张检查表，逐项核对tag、entry、dcd_ptr、length。很多“烧录成功但无法启动”的问题，根源都在这些字段与链接地址不匹配。

七、常见错误与判断依据

启动失败时，可以按以下顺序排查：第一，确认Boot Header的tag是否正确，若tag错误，Boot ROM会直接跳过该镜像；第二，确认IVT的entry是否指向有效代码区，若指向未初始化区域，通常表现为取指异常；第三，确认DCD是否被正确执行，若DDR未初始化，入口在DDR中的程序无法运行；第四，确认Boot Data的length是否覆盖完整镜像，若偏小，尾部代码可能缺失。

实际调试中，可以借助Boot ROM的启动状态寄存器或串口日志来判断卡在哪一步。如果日志显示已经进入应用程序但很快复位，多半是entry正确但DCD未完成必要初始化；如果完全没有日志，则优先检查Boot Header和IVT的偏移字段。掌握这套结构后，固件升级中的镜像校验、双备份切换和回滚设计都会变得有据可依。