该文章同步至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_MAJOR1VERSION_MINOR4BUILD_NUMBER$(gitrev-list--countHEAD)GIT_HASH$(gitrev-parse--shortHEAD)BUILD_DATE$(date%Y%m%d)# 写入一个二进制文件printfFW%02d%02d%04d$VERSION_MAJOR$VERSION_MINOR$BUILD_NUMBERfw_info.binprintf$GIT_HASHfw_info.binprintf$BUILD_DATEfw_info.bin# 补零到 32 字节truncate-s32fw_info.bin这个fw_info.bin就是我们要注入的原始数据正好 32 字节。Step 3用objcopy注入数据# 先将 ELF 转为可写的 bin 格式非必要也可以直接操作 ELFarm-none-eabi-objcopy-Obinary firmware.elf firmware.bin# 将 fw_info.bin 的内容写入 firmware.elf 的 .firmware_info 段arm-none-eabi-objcopy --update-section .firmware_infofw_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#includestdint.h#defineFW_INFO_ADDR0x0800FFE0typedefstruct__attribute__((packed)){charmagic[2];// FWuint8_tversion_major;uint8_tversion_minor;uint16_tbuild_number;chargit_hash[8];// 7 字符 \0charbuild_date[9];// 8 字符 \0uint8_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 .crccrc.bin app.elf app_final.elfBootloader 启动时重新计算 CRC 并与这个值比对不匹配则拒绝跳转。2. 嵌入整个文件系统镜像如果你的嵌入式设备包含一个小型文件系统如 LittleFS可以将预构建的镜像直接嵌入固件# 制作 LittleFS 镜像mklittlefs-s65536littlefs.bin# 将其作为 .filesystem 段嵌入arm-none-eabi-objcopy --update-section .filesystemlittlefs.bin firmware.elf firmware_with_fs.elf设备上电后文件系统已经就位无需运行时格式化。3. 量产时注入唯一序列号和 MAC 地址每台设备有唯一的序列号和 MAC 地址。可以在量产烧录时动态生成并注入# 为当前设备生成唯一的序列号SERIALSN$(date%s)$(shuf-i1000-9999-n1)echo-n$SERIALserial.bin arm-none-eabi-objcopy --update-section .serialserial.bin firmware.elf firmware_personalized.elf这避免了在编译时为每个设备维护不同的源码或配置。4. 使用--add-section追加新段如果你的链接脚本中没有预留段也可以用--add-section动态追加arm-none-eabi-objcopy --add-section .extra_dataextra.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重新编译后忘记注入怎么办如果你修改了源码并重新makeELF 文件会被重新生成。此时.firmware_info段又变成了全 0xFF或初始值。如果你用旧的firmware_patched.elf来烧录可能包含过时的注入数据如果你直接用新的firmware.elf烧录注入数据会丢失。解决办法将注入步骤集成到 Makefile 中作为all或flash目标的依赖。每次编译后自动执行注入脚本。在固件中增加运行时自检如果.firmware_info段中的 magic 字段不是预期的值打印警告或拒绝启动。在 CI/CD 中将最终烧录文件命名为包含版本和构建号的唯一文件名避免混淆。好了第 35 招我们就彻底吃透了。从今天起别让你的固件“裸奔”出厂了。用objcopy给它打上版本烙印、签上校验码、嵌入文件系统让它成为一个自描述、可追溯、安全的完整映像。如果今天的内容让你对固件构建流程有了新的认识欢迎转发和点赞。下一篇我们继续挖组合volatile与__DSB()/__DMB()内存屏障严控外设寄存器访问顺序。咱们不见不散