-嵌入式高手都在偷偷用的“第35条”：用 objcopy 把版本号、校验码甚至文件系统“烙”进固件里
该文章同步至OneChan
你的产品出了批次问题，需要追溯固件版本。可你盯着手上这块 PCB，翻遍所有日志，发现板子上跑的固件既没有版本号也没有构建时间——它就是个黑盒。
这是资深工程师压箱底的编程技巧系列第三十五篇。前面我们学会了用--gc-sections极致剪裁固件体积，用.init_array实现模块自动初始化，用--wrap无侵入拦截库函数。今天这一招，作用在固件构建的最后一步——二进制映像的生成与后处理。它能让你在不修改任何 C 源码的情况下，把任意二进制数据（版本信息、校验码、文件系统镜像、Bootloader 载荷）直接嵌入最终固件的指定位置。
它就是嵌入式构建流程中一把被严重低估的瑞士军刀：
objcopy --update-section和objcopy --add-section。
这两个选项配合链接脚本中预定义的空段，可以在编译完成后、烧录之前，对 ELF 文件或二进制映像进行精确的“外科手术式”数据注入。
一、这东西到底是干什么用的？
简单说：objcopy --update-section可以将任意二进制文件的内容覆盖到 ELF 文件的指定段中；--add-section则可以直接添加一个新的段。这两个操作都在链接完成之后进行，完全不影响源码和编译流程。
典型的应用场景包括：
- 嵌入固件版本和构建信息：在固件的固定偏移处写入版本号、Git commit hash、编译时间戳，方便现场升级和故障回溯。
- 写入校验码：固件构建完成后，计算整个映像的 CRC32 或 SHA256，将其写入预留的校验字段。Bootloader 在启动时校验完整性。
- 嵌入文件系统镜像：将 LittleFS 或 FAT 镜像直接附着到固件末尾，实现单文件量产。
- 动态注入配置数据：量产时，每台设备的序列号、MAC 地址、校准参数都可以通过
objcopy单独注入，而不需要维护多套源码。
它的核心优势是：将“编译”和“数据注入”解耦。编译产出通用的固件骨架，后处理阶段再根据目标设备、批次、渠道写入差异化数据。这对于规模化生产、持续集成和固件追溯是必不可少的基础能力。
二、上硬菜，直接看怎么用
Step 1：在链接脚本中预留空段
首先，你需要在链接脚本中为即将注入的数据预留一个段。这个段只声明地址空间，不实际填充数据（或者填充全 0xFF）。
例如，为固件信息预留一个 32 字节的段：
SECTIONS { /* ... 其他段 ... */ .firmware_info 0x0800FFE0 : { KEEP(*(.firmware_info)) . = ALIGN(4); /* 不填充任何内容，编译后此区域为 0xFF */ } >FLASH }注意：这里的地址0x0800FFE0是 Flash 的末尾附近（假设 Flash 末尾是 0x08010000，这里留出了 32 字节）。你可以根据需要调整位置和大小。
编译后，这个段在 ELF 文件中存在，但内容是空的（全 0xFF），在.map文件中可以看到它占用的地址范围。
Step 2：准备要注入的二进制数据
你可以通过脚本生成一个二进制文件，包含固件版本、Git hash、编译时间等信息：
#!/bin/bash# generate_fw_info.shVERSION_MAJOR=1VERSION_MINOR=4BUILD_NUMBER=$(gitrev-list--countHEAD)GIT_HASH=$(gitrev-parse--shortHEAD)BUILD_DATE=$(date+%Y%m%d)# 写入一个二进制文件printf"FW%02d%02d%04d"$VERSION_MAJOR$VERSION_MINOR$BUILD_NUMBER>fw_info.binprintf"$GIT_HASH">>fw_info.binprintf"$BUILD_DATE">>fw_info.bin# 补零到 32 字节truncate-s32fw_info.bin这个fw_info.bin就是我们要注入的原始数据，正好 32 字节。
Step 3：用objcopy注入数据
# 先将 ELF 转为可写的 bin 格式（非必要，也可以直接操作 ELF）arm-none-eabi-objcopy-Obinary firmware.elf firmware.bin# 将 fw_info.bin 的内容写入 firmware.elf 的 .firmware_info 段arm-none-eabi-objcopy --update-section .firmware_info=fw_info.bin firmware.elf firmware_patched.elf# 重新生成最终的 bin 和 hex 文件arm-none-eabi-objcopy-Obinary firmware_patched.elf firmware_final.bin arm-none-eabi-objcopy-Oihex firmware_patched.elf firmware_final.hex现在，firmware_final.bin的0x1FFE0偏移处（对于 512KB Flash 的末尾）就永久嵌入了版本信息。你可以用 JTAG、Bootloader 或者objdump来读取它：
arm-none-eabi-objdump-s-j.firmware_info firmware_patched.elf输出类似：
Contents of section .firmware_info: 0800ffe0 46573031 30343030 31326133 34623663 FW01040012a34b6c 0800fff0 32303235 30363135 00000000 00000000 20250615........Step 4：在 C 代码中读取这些数据
你可以在固件中定义一个指向该地址的常量指针来读取版本信息：
// fw_info.c#include<stdint.h>#defineFW_INFO_ADDR0x0800FFE0typedefstruct__attribute__((packed)){charmagic[2];// "FW"uint8_tversion_major;uint8_tversion_minor;uint16_tbuild_number;chargit_hash[8];// 7 字符 + '\0'charbuild_date[9];// 8 字符 + '\0'uint8_treserved[8];}fw_info_t;constfw_info_t*fw_info=(constfw_info_t*)FW_INFO_ADDR;voidprint_version(void){printf("Firmware v%d.%d build %d (%s %s)\n",fw_info->version_major,fw_info->version_minor,fw_info->build_number,fw_info->git_hash,fw_info->build_date);}由于数据是通过objcopy直接写入 Flash 地址的，它不需要任何初始化，上电即可读取。
三、举一反三，objcopy的这些高级用法你必须知道
1. 注入固件校验码，实现安全启动
Bootloader 在启动 App 前需要校验完整性。你可以在 App 固件的预留位置写入 CRC32：
# 编译 App，.crc 段预留 4 字节全 0# 用 crc32 工具计算整个 bin 的校验值，跳过 .crc 段本身CRC_VALUE=$(crc32--skip0x1FFF0 app.bin)# 伪代码，需要实际工具支持printf"\x$(echo$CRC_VALUE|cut-c1-2)\x$(echo$CRC_VALUE|cut-c3-4)...">crc.bin arm-none-eabi-objcopy --update-section .crc=crc.bin app.elf app_final.elfBootloader 启动时重新计算 CRC 并与这个值比对，不匹配则拒绝跳转。
2. 嵌入整个文件系统镜像
如果你的嵌入式设备包含一个小型文件系统（如 LittleFS），可以将预构建的镜像直接嵌入固件：
# 制作 LittleFS 镜像mklittlefs-s65536littlefs.bin# 将其作为 .filesystem 段嵌入arm-none-eabi-objcopy --update-section .filesystem=littlefs.bin firmware.elf firmware_with_fs.elf设备上电后，文件系统已经就位，无需运行时格式化。
3. 量产时注入唯一序列号和 MAC 地址
每台设备有唯一的序列号和 MAC 地址。可以在量产烧录时动态生成并注入：
# 为当前设备生成唯一的序列号SERIAL="SN$(date+%s)$(shuf-i1000-9999-n1)"echo-n$SERIAL>serial.bin arm-none-eabi-objcopy --update-section .serial=serial.bin firmware.elf firmware_personalized.elf这避免了在编译时为每个设备维护不同的源码或配置。
4. 使用--add-section追加新段
如果你的链接脚本中没有预留段，也可以用--add-section动态追加：
arm-none-eabi-objcopy --add-section .extra_data=extra.bin firmware.elf firmware_extra.elf但需要注意：新段的地址和大小必须在链接脚本的 MEMORY 区域之内，否则可能破坏现有布局。通常推荐在链接脚本中预留空段，这样地址是确定的。
四、留两个问题给你思考
现在请你停下来，思考这两个实际问题：
- 如果
objcopy --update-section注入的二进制文件大小超过了链接脚本中预留段的大小，会发生什么？有没有办法在注入前自动检查大小？ - 用
objcopy注入数据后，如果重新编译了固件，但忘记重新执行注入脚本，旧的注入数据会留在什么位置？如何避免使用过时的注入结果？
想清楚这两个问题，你就能在 CI/CD 流水线中可靠地部署这一技术，而不会被“脏数据”坑害。
五、总结与思考题回答
核心总结：
objcopy --update-section将二进制数据覆盖到 ELF 文件的指定段中，实现固件后处理注入。- 主要用途：嵌入版本信息、校验码、文件系统镜像、唯一序列号等。
- 工作流程：链接脚本预留空段 → 编译生成骨架固件 → 脚本生成二进制数据 →
objcopy注入 → 生成最终烧录文件。 - 核心优势：将编译与数据注入解耦，支持批量生产和 CI/CD 自动化。
思考题回答
问题1：注入数据超过预留段大小怎么办？
objcopy --update-section会直接覆盖段内容，如果注入的二进制文件比段大，它会截断（只写入段大小的数据），如果比段小，则只覆盖前面部分，段末尾保留原始内容。这通常会导致数据不完整或残留旧数据，非常危险。预防措施：
- 在注入脚本中先用
stat或wc检查二进制文件大小，与链接脚本中预留的大小对比，超限则报错退出。 - 在链接脚本中使用
ASSERT(SIZEOF(.firmware_info) == 32, "...")强制段大小严格匹配。 - 使用
truncate -s将数据文件精确填充到目标大小，避免长短不一。
问题2：重新编译后忘记注入怎么办？
如果你修改了源码并重新make，ELF 文件会被重新生成。此时.firmware_info段又变成了全 0xFF（或初始值）。如果你用旧的firmware_patched.elf来烧录，可能包含过时的注入数据；如果你直接用新的firmware.elf烧录，注入数据会丢失。解决办法：
- 将注入步骤集成到 Makefile 中，作为
all或flash目标的依赖。每次编译后自动执行注入脚本。 - 在固件中增加运行时自检：如果
.firmware_info段中的 magic 字段不是预期的值，打印警告或拒绝启动。 - 在 CI/CD 中，将最终烧录文件命名为包含版本和构建号的唯一文件名，避免混淆。
好了，第 35 招我们就彻底吃透了。从今天起，别让你的固件“裸奔”出厂了。用objcopy给它打上版本烙印、签上校验码、嵌入文件系统，让它成为一个自描述、可追溯、安全的完整映像。
如果今天的内容让你对固件构建流程有了新的认识，欢迎转发和点赞。下一篇我们继续挖：组合volatile与__DSB()/__DMB()内存屏障严控外设寄存器访问顺序。咱们不见不散！