uImage头部信息在mkimage工具源码中哪部分修改？

Question

常见技术问题： 在使用U-Boot的`mkimage`工具生成uImage时，若需自定义uImage头部中的`os`（操作系统类型）、`arch`（架构）、`type`（镜像类型）或`load_addr`（加载地址）等字段，应修改`mkimage`源码的哪一部分？许多开发者尝试直接修改`image.h`中的结构体定义却导致校验失败或启动异常。实际上，uImage头部由`tools/mkimage/image.c`中`mkimage_verify_header()`和`mkimage_set_header()`等函数控制，关键逻辑位于`tools/mkimage/image.c`的`image_set_header()`调用链中，而具体字段填充由各子命令（如`-A arm -O linux -T kernel`）触发的`image_check_params()`与`image_set_header()`协同完成；头信息序列化发生在`image_build_header()`（定义于`tools/mkimage/image.c`第1200行左右）。错误修改`image_header_t`原始结构或跳过CRC/size重计算，将破坏uImage合法性。正确做法是在保持ABI兼容前提下，扩展参数解析逻辑并同步更新头部填充与校验流程。

Answer 1

```html

一、常见技术问题：uImage头部字段自定义的典型误操作

在嵌入式Linux系统开发中，使用U-Boot mkimage 工具生成符合规范的 uImage 是启动流程的关键环节。开发者常需适配非标准OS类型（如RTOS）、定制架构标识（如arm64-v8a）、或指定特殊加载地址（如DDR偏移0x8000_1000），但直接修改 include/image.h 中的 image_header_t 结构体——例如扩展 ih_os 枚举值或重排字段顺序——将导致：CRC32校验失败、U-Boot启动时header验证拒绝（"Bad Magic Number"或"Wrong Image Type"）、甚至内存越界崩溃。根本原因在于：uImage是二进制序列化结构，其ABI（Application Binary Interface）由头长度（64字节固定）、字段偏移、CRC计算范围三者强耦合，任何结构体变更若未同步更新序列化逻辑与校验路径，即破坏合法性。

二、深度解析：uImage头部生成与验证的四层控制流

1. 参数解析层：命令行参数（-A arm -O linux -T kernel -a 0x80000000）经 tools/mkimage/image.c::image_check_params() 校验并存入 struct image_tool_params；
2. 头部填充层：调用 image_set_header()（位于 tools/mkimage/image.c:987），将参数映射至 image_header_t 各字段（如 ih_os = params->os;）；
3. 序列化层：image_build_header()（tools/mkimage/image.c:1200）执行字节序转换（cpu_to_uimage_*）、填充保留字段、计算 ih_size（含数据+header）、最后调用 mkimage_set_header() 写入最终二进制头；
4. 校验层：U-Boot运行时通过 lib/imagetool.c::image_get_header() 和 image_check_hcrc() 验证CRC，并用 image_check_type()/image_check_os() 校验字段合法性。

三、关键源码定位与修改边界（U-Boot v2023.04+）

文件路径	函数/宏	作用	修改安全边界
tools/mkimage/image.c	image_check_params()	校验输入参数有效性（如arch/os/type是否在白名单）	✅ 可安全扩展枚举校验逻辑（如新增 IH_OS_MYRTOS）
tools/mkimage/image.c	image_set_header()	将参数写入 image_header_t * 指针指向的内存	✅ 可安全添加字段赋值（如 hdr->ih_load = cpu_to_uimage_u32(params->addr);）
include/image.h	enum ih_os, enum ih_arch	定义操作系统/架构枚举值	⚠️ 仅可追加新值（末尾），不可删改/重排；需同步更新 tools/mkimage/fit_common.c 中的字符串映射表

四、正确扩展实践：以支持自定义OS类型 myrtos 为例

假设需支持 -O myrtos，步骤如下：

1. 在 include/image.h 中追加：#define IH_OS_MYRTOS 12（确保大于现有最大值）；
2. 修改 tools/mkimage/image.c::image_check_params()，在 switch (params->os) 中增加 case IH_OS_MYRTOS: 分支；
3. 在 image_set_header() 中确保 hdr->ih_os = cpu_to_uimage_u8(params->os); 正确赋值；
4. 更新 tools/mkimage/fit_common.c::genimg_get_os_name() 添加字符串映射；
5. 重新编译 mkimage 并验证：mkimage -A arm -O myrtos -T kernel -C none -a 0x80000000 -e 0x80000000 -d vmlinux uImage-myrtos；
6. 用 hexdump -C uImage-myrtos | head -n 2 确认第49字节（ih_os offset）为 0x0c（12的十六进制）。

五、风险规避与验证清单

• ❌ 禁止修改 image_header_t 字段顺序、大小或删除字段（破坏64字节ABI）；
• ❌ 禁止跳过 image_build_header() 中的 mkimage_set_header() 调用或CRC重计算；
• ✅ 必须同步更新所有涉及该字段的字符串映射（fit_common.c, image.c 的打印函数）；
• ✅ 必须在U-Boot目标板上实机验证：printenv → tftpboot ${loadaddr} uImage-myrtos → bootm ${loadaddr}；
• ✅ 建议编写自动化测试脚本，校验生成uImage的 ih_size、ih_hcrc、ih_os 字节值是否符合预期。

六、流程图：uImage头部生成与验证全链路

flowchart LR
  A[命令行 mkimage -A arm -O myrtos -T kernel] --> B[image_check_params\(\)]
  B --> C{参数合法？}
  C -->|Yes| D[image_set_header\(\)]
  C -->|No| E[报错退出]
  D --> F[image_build_header\(\)]
  F --> G[cpu_to_uimage_* 字节序转换]
  G --> H[计算 ih_size = sizeof\(header\) + data_len]
  H --> I[计算 ih_hcrc over header]
  I --> J[写入64字节header+data]
  J --> K[U-Boot启动时 image_get_header\(\)]
  K --> L[image_check_hcrc\(\) & image_check_os\(\)]
  L -->|Pass| M[继续加载执行]
  L -->|Fail| N[“Bad Data CRC” or “Unsupported OS”]

```