配电终端国产化：基于米尔-全志T113实现安全启动与OTA升级

前阵子帮一位做配电自动化集成的朋友梳理现场问题时他刚从配电房回来为了给十几台跑了快五年的配电终端升固件蹲点了一整天。每台设备都得拎着笔记本、串口线进柜子断电停机才能刷结果有一台刷到一半碰上现场跳闸设备直接卡死在半升级状态最后返厂才救回来。这种场景在配电终端运维里太常见了。他把新项目的需求抛给我核心板全面国产化他看中了米尔-全志系列核心板但用户侧提了两个硬性指标——设备必须支持安全启动必须支持OTA远程升级。这两个需求单看都不难真正落地时却牵出一堆细节证书链怎么配、eFuse一次性烧录怎么规划、升级包签名怎么做、断电回滚怎么保证。这篇文章就把我们调试过程中跑通的完整方案、踩过的坑、以及背后的设计逻辑一起整理出来供做电力终端、工业控制类产品的嵌入式工程师参考。1. 配电终端的国产化选型为什么落在米尔-全志核心板上1.1 配电终端设备面对的现实约束配电终端不是常规消费电子。馈线终端FTU、站所终端DTU、配变终端TTU可能挂在户外电杆、箱变、配电房各种环境里夏天高温、冬天低温雷电和浪涌冲击都是家常便饭。这些设备一旦投运往往要连续工作5到10年不关机。现场没有人值守运维人员也不可能频繁跑站。所以终端产品的设计逻辑从一开始就和手机、路由器完全不同可靠性优先功能做扎实升级动作要谨慎再谨慎。传统做法是在出厂前把固件烧好全生命周期都不动。但近几年需求越来越现实——规约升级、功能迭代、安全漏洞修补全都逼着厂商把远程升级能力补上。随便一个小功能改动如果还要派人带着电脑去现场断电刷机成本完全不可接受。于是OTA从加分项变成了必选项而安全启动则是OTA不可信的前提没有安全启动的OTA升级包被篡改或被攻击者恶意灌入终端就成了被人遥控的木马。1.2 安全启动与OTA在安全分区、网络专用体系中的位置电力行业的安全防护讲究纵深防御主站侧、网络侧、终端侧都有对应的边界要求。终端侧的安全启动本质上解决的是身份可信和代码可信两个问题设备通电后芯片能确认自己启动的每一个阶段都是厂商签发的、未被篡改的在OTA场景下终端收到升级包后能确认包来源可信、内容完整不会照着攻击者给的镜像把自己刷死。我见过不少团队把安全启动当成一个有没有的开关觉得勾个配置打开就行。实际上它是一个体系启动链每一级都要校验证书密钥全生命周期要管理OTA流程要跟安全启动配合默契否则可能出现——安全启动开了升级包签名工具链没打通OTA功能直接废掉的情况。所以方案设计必须把这两件事放在一起规划先定整体架构再分头实现。1.3 米尔-全志核心板的选型逻辑选型时我们对比了几条路线。第一是继续用进口主控方案成熟、资料多但供货和国产化率指标让人头疼。第二是自己拿全志或者瑞芯微的芯片画板子灵活度高但要做DDR、Flash、电源管理的设计和验证周期至少多两个月对于配电终端这种量级不算大的项目不划算。第三就是走核心板路线也就是我们现在定下来的直接选米尔基于全志T113-S3做的核心板。方案路线周期风险点适合场景进口主控单板短国产化率、远期供货存量产品延续国产芯片自研底板长硬件验证、DDR调参、信号完整性问题单款大批量国产核心板自研底板中等依赖核心板厂商支持电力、工控等多品类扩展全志T113-S3是双核Cortex-A7架构带硬件浮点单元主频可以跑到1.2GHz内部集成DDR外设接口覆盖了电力终端常用的百兆网口、CAN、串口、USB和显示接口。对一个配电终端来说这类性能完全够用而且芯片本身在工业级温宽、供货持续性方面有优势。米尔把核心板做成了邮票孔封装DDR、Flash、电源管理都集成好了我们只需要画底板把对外接口、隔离电源、保护电路做出来就行。硬件工作量大幅下降团队可以把精力放在安全启动和OTA这套真正决定产品竞争力的软件架构上。2. 安全启动落地把全志启动链变成可信链2.1 先理清全志平台的启动链做安全启动之前必须先搞懂芯片是怎么把系统拉起来的。全志平台的启动流程大致是芯片上电后片内固化的一段启动代码BROM从选定启动介质SD卡、eMMC、SPI NOR、NAND的固定位置读取引导程序这段引导程序通常叫SPL或者boot0作用是把DDR初始化好随后SPL把U-Boot加载进内存运行U-Boot再负责加载Linux内核内核挂载根文件系统完成启动。整条链是环环相扣的。安全启动要做的就是在每一环启动下一环之前先对下一环的镜像做完整性校验和签名验证。BROM把SPL验完SPL把U-Boot验完U-Boot把内核验完内核再去验根文件系统。这样从芯片内部固化的信任根出发一级一级传递信任才能确保整条启动链上没有任何一环被人动过手脚。信任根一般存放在eFuse里。eFuse是一种一次性可编程存储写进去的位就永久锁定了后期无法修改。通常会把根公钥的哈希烧到eFuse里BROM启动时用这颗固定的哈希去验证SPL镜像上附带的证书和签名。这里要特别注意一个特性eFuse的写入是不可逆的一旦烧进去哪怕后来发现公钥配错了也只能换芯片。所以量产阶段的密钥规划必须慎之又慎。2.2 别把嵌入式安全启动和PC的Secure Boot混为一谈很多同事第一次接触安全启动习惯性去网上搜安全启动证书搜出来一堆Windows 11的证书更新、UEFI Secure Boot的数据库DBX更新的内容。2023年确实有一波PC领域的安全启动证书更新微软更新了吊销列表导致一批旧设备启动异常。我们当时差点被这个误导拿PC的搞法去套全志平台。实际上这是两条完全不同的技术路径。PC的Secure Boot由UEFI固件实现证书由微软和OEM厂商体系管理用的是公开的证书数据库遇到大规模证书吊销事件会通过系统更新分发新DBX。而嵌入式平台的安全启动证书链完全由设备厂商自己签发和管理不存在从某处下载官方证书这种操作。你的根密钥自己生成设备上的公钥自己烧录签名自己完成。网上那些2023版安全启动证书下载的内容对我们做配电终端的没有任何参考价值反而容易把方向带偏。2.3 证书链设计与eFuse烧录流程我们在项目里采用的是两级证书结构根证书和平台证书。操作流程分两条线一条是证书签发线一条是镜像签名线。证书签发线的步骤是先离线生成根私钥和根证书根证书自签名作为整条链的信任锚。然后生成平台私钥和平台证书用根私钥给平台证书签名。平台证书是实际给镜像签名的密钥对。根私钥保存在离线机器上最好加密存储并做备份平台私钥可以放在构建服务器上方便打包流程自动签名。镜像签名线的步骤是每次构建固件后对SPL、U-Boot、内核分别用平台私钥做签名并附带平台证书链。启动时BROM用eFuse里的根公钥哈希取出根公钥验平台证书的签名再用平台公钥验证镜像的签名。eFuse烧录是整个过程中最需要谨慎的环节。一旦把根公钥哈希写进eFuse并熔断芯片就只认这一套证书体系。我们当时分了三步走在开发板上先用一组测试密钥跑通整个安全启动流程确认签名工具、镜像格式、boot配置全部正确。把测试密钥换成正版量产密钥在几只工程板上做完整验证包括多次OTA升级测试和掉电测试。确认万无一失后才把量产密钥的烧录脚本交给生产部门同时把根私钥放进离线保险环境整个生命周期内不进入产线。提示全志平台的Secure Boot具体实现、工具链版本和镜像打包格式不同芯片系列会有差异做正式方案前建议以全志FAE提供的官方包和文档为准。我们当时拿到的是一个Secure Boot工具包包含密钥生成脚本、签名工具和烧录工具不同版本之间的命令行参数不完全一致。2.4 开启安全启动后怎么验证真的安全安全启动不是开完就完事必须在产品上做正向和反向两组验证。正向验证设备正常启动所有日志阶段通过能正常进入系统。反向验证故意篡改某个镜像的任意一个字节再烧录进设备设备应当拒绝启动或者在对应阶段停止。我们当时做了一组比较完整的反向测试改SPL的一个字节启动直接卡死改U-Boot的启动logo数据日志停在U-Boot校验阶段改内核镜像U-Boot报签名验证失败回落到recovery流程。这些测试证实了每一级校验都真正工作了而不是只在文档里画了张图。另外还要关注性能开销。安全启动增加了RSA验签运算虽然量级不大但在SPL阶段CPU主频还没起来验签会占用几十到几百毫秒不等的时间。对配电终端这种对启动时间不算苛刻的设备来说完全可接受。但对那些有秒级启动需求的产品就得提前评估考不考虑加密引擎硬件加速、是否需要缓存签名结果等优化手段。3. OTA方案设计分区策略、升级包签名与自动回滚3.1 配电终端的OTA约束和普通设备完全不同手机OTA常见的做法是用户点一下升级设备联网下载、校验、重启整个过程网络质量有保证电池基本不会断。配电终端没有这么好的环境。它挂在电力通信网络里可能走的是无线专网、运营商4G、电力载波甚至是一段质量不怎么样的光纤。现场没有用户断电完全不可控——市电故障、检修拉闸都可能发生在升级过程中。这就给OTA设计提出了三个硬约束。第一升级包要有可靠的完整性校验和签名机制任何网络中途损坏的包都不能被执行。第二整个升级过程必须支持断电恢复——无论是写到一半断电还是升级完成后重启失败设备都必须能回到一个可用状态。第三升级通道的流量可能很有限升级包不能太臃肿还要考虑断点续传、失败重试这些能力。把这些约束落到架构上就是三个核心设计双分区机制、升级包签名校验、启动回滚机制。3.2 分区表设计双分区加recovery我们规划的分区方案围绕冗余展开。核心分区包括boot分区存放U-Boot及环境变量。recovery分区存放一个最小恢复系统普通系统起不来时可以进入recovery接收升级包。kernel_a / kernel_b两个内核镜像分区交替使用。rootfs_a / rootfs_b两个根文件系统分区和内核一一对应。misc分区存放OTA升级状态标志、启动计数、回滚计数等信息。userdata分区存放系统运行数据、日志、升级包缓存。比如在eMMC上分区顺序可以是boot、misc、kernel_a、rootfs_a、kernel_b、rootfs_b、recovery、userdata。U-Boot里通过环境变量记录当前应该从A组还是B组启动misc分区里面的标志位则告诉U-Boot这次的启动是正常启动、升级后首次启动还是回滚启动。这种A/B双分区的好处是升级不是覆盖而是切换。升级时把新镜像写入当前不用的那组分区写坏了大不了标记这组无效老的系统一直在原地没动过。写入完成后设置升级完成待切换标志重启后U-Boot选择新系统。新系统如果启动失败U-Boot根据启动计数和标志自动切回旧分区设备恢复正常运行。整套逻辑下来最坏的情况不过就是升级失败设备回到旧版本而不会出现设备变砖。3.3 升级包制作、签名校验与下发链路升级包本身设计成一个自描述容器里面包含版本信息、分区镜像、镜像哈希、签名数据。我们在项目里用的是自定义打包脚本生成的tar归档格式结构大致是ota_package_v103.tar ├── manifest.json # 版本号、目标设备型号、镜像列表、各镜像SHA256 ├── boot.img # 内核镜像 ├── rootfs_a.img # 根文件系统镜像 └── signature.bin # 对manifest.json的签名生产环境里打包脚本在学校或CI构建机上完成镜像编译后先计算每个镜像的SHA256写入manifest.json然后用平台私钥对manifest做签名生成signature.bin。终端收到的第一层校验就是验签终端内置平台公钥升级程序先用公钥校验signature.bin确认manifest完整可信之后再逐项核对每个镜像的SHA256是否与manifest一致。一旦任何一项不匹配升级包直接丢弃并记录失败日志。下发链路走的是终端原本和主站通信的上行通道。主站下发一个升级任务终端按需分片下载、边下边校验下载完成后通知主站进入升级流程。考虑到弱网环境我们的下载程序实现了断点续传——按块记录已下载完成的数据索引网络断开重连后从断点继续不用整包重来。配电终端上这个能力非常重要因为无线通道的稳定性真不敢恭维。我们当时还做了升级包加密。安全启动解决的是设备不接受篡改包但配电终端经过的网络环境复杂还要防止升级包被截获后逆向分析或者回放攻击。所以升级包在签名基础上又做了一层加密对称密钥通过一次会话握手协商出来每次下发不同。加密不增加太多开发量但对安全等级要求高的电力项目是加分项。3.4 自动回滚机制怎么做才可靠自动回滚很容易做成有但不好使的状态。我们第一版只做了启动计数——U-Boot里有个bootcount环境变量每次启动加1bootmgr检查是否超出阈值。实测中发现问题如果新系统启动成功但运行半小时后才崩溃单纯靠启动计数是管不了的因为计数在早期就正常了。后来改成应用层上报心跳的联动方案。新系统启动后业务守护进程正常运行、主站链接建立、采样数据正常上送这些条件都满足时应用层才向misc分区写入系统运行正常标志表示本次升级完全成功此时才把升级状态清零。U-Boot侧的判断逻辑是读取misc分区升级标志确认是否存在升级待确认状态。如果存在读取当前启动计数计数加1后写回。如果计数超过设定阈值我们设为3次判定新系统不可用切换启动分区回旧版本同时清除升级标志。如果计数未超阈值继续正常启动新系统。新系统应用层确认正常后清除升级标志和启动计数。这套逻辑覆盖了三种失败场景新系统在U-Boot阶段起不来、新系统内核崩溃反复重启、新系统起来了但业务不正常。配电终端里最担心的就是升级成功了但设备不上送数据了现场又没人发现有了应用层确认这种问题也能自动回滚解决。4. 实测踩坑串口调试、FEL烧录救砖与硬件浮点那点事4.1 全志平台串口调试的第一道坎第一次接触全志平台最容易踩的就是调试串口。V3s、T113这些芯片的调试串口默认是UART0电平3.3V波特率通常115200。看着简单但我们在一块V3s的板子上折腾了半天没输出最后发现是电平问题——USB转串口模块用了5V电平和板子3.3V的TX/RX直接怼在一起虽然没烧坏芯片但信号完全不对。全志平台串口调试还有几个常见坑现象可能原因处理方式上电完全无输出启动介质为空或BROM未执行检查烧录、进入FEL模式用工具烧引导只有乱码波特率不匹配、TX/RX接反对照芯片手册确认波特率和引脚定义输出到U-Boot就停U-Boot配置的console串口和设备树不一致核对cmdline和设备树uart配置只输出uboot信息内核无日志设备树串口节点未使能配置pinctrl和uart节点重新编译设备树里要把对应的uart节点状态设为okay并配好引脚复用。我们板子上的调试口是UART0在设备树里需要把pinctrl的uart0引脚组打开。如果选了别的串口做调试还要在内核cmdline里通过consolettyS0,115200之类的参数指过去U-Boot也保持同样的console配置两边不一致的典型症状就是U-Boot有日志、内核没日志。4.2 FEL模式与刷机救砖安全启动之后更要谨慎全志芯片有个很实用的机制叫FEL模式——上电时芯片不进正常启动流程而是通过USB和PC通信可以用工具直接读写Flash和内存。开发阶段的救砖利器就是它。我们平时用的刷机方式有两种一种是把启动卡TF卡做成可引导镜像插卡上电自动烧录另一种是进FEL模式配合全志的烧录软件或者命令行方式直接烧写eMMC/NAND。H2、V3s、T113这些芯片玩过的人都见过变砖再救活的场景。之前遇到一次编译出来的SPL坏道板子什么都不输出就是靠FEL模式救回来的——按住板上的FEL键上电USB连电脑把正确镜像重新烧写一遍几秒钟活过来。但安全启动开启之后救砖规则变了。eFuse里的信任根已经烧死任何镜像必须带合法签名才可能启动。这时候就算进了FEL模式把SPL分区重刷刷进去的东西没有正确的平台私钥签名芯片照样拒绝执行。所以必须有意识地把这个问题前置解决维护一套完整的签名构建环境任何发布给现场的镜像都要经过签名流程从源头杜绝手头镜像没有签名的情况。FEL模式只作为底层救砖通道真正恢复要用带有效签名的完整量产镜像。密钥和签名工具要有专人管理制度。我们遇到过同事拿测试密钥签的镜像刷到量产板上启动链验签失败排查半天才意识到密钥环境搞混了。现场救砖的最后手段我们也验证过制作一张预烧了带签名镜像的应急SD卡同时提供FEL模式下的烧写脚本。即便eMMC完全损坏也可以从SD卡启动最小恢复系统之后再通过OTA把正常系统刷回来。这个方案测试下来最稳推荐有条件的项目都预置。4.3 T113的硬件浮点工具链选错性能差距跨数量级T113-S3是双核Cortex-A7带硬件浮点单元NEON和VFPv4。这个特性对配电终端很重要因为电力采样分析里大量用到傅里叶变换、滤波器、有效值计算这类浮点密集运算。但前提是编译器必须生成硬件浮点指令。嵌入式Linux工具链一般分两种arm-linux-gnueabihfhard float浮点参数用浮点寄存器传递直接发浮点指令和arm-linux-gnueabisoft float用普通寄存器传递浮点运算由libgcc软件模拟。用错了工具链性能差异非常大。我们在测试平台上跑一个简单的浮点运算压力测试硬浮点版本比软浮点快了将近一个数量级。对CPU密集的采样计算来说这个差距直接决定设备能不能扛住实时处理需求。这里给个明确的建议编译应用和内核时统一使用带hf后缀的工具链同时在编译参数里显式指定浮点ABI。# 工具链选择示例 export CROSS_COMPILEarm-linux-gnueabihf- export CC${CROSS_COMPILE}gcc export CFLAGS-marcharmv7-a -mfpuneon-vfpv4 -mfloat-abihard # 内核配置也需确认CONFIG_VFP和CONFIG_NEON已开启检查当前系统用的是硬浮点还是软浮点可以在目标板上执行命令查看# 查看连接器报告的浮点ABI arm-linux-gnueabihf-readelf -A /path/to/binary | grep Tag_ABI_VFP_args输出Tag_ABI_VFP_args: VFP registers说明用的是硬浮点ABI如果显示compatible就是软浮点。这块如果发现系统里有些库是软浮点编译的应用之间互相调用时会出现未定义指令错误排查起来很费劲。我们后来干脆把整个rootfs统一用同一套hf工具链从源码构建避免混用。4.4 一个签名时间戳引起的OTA失败排查全记录最后分享一个印象最深的OTA排查案例。安全启动和OTA上线测试后第一轮升级一切正常隔了一周做第二轮升级时终端总是报告校验失败但升级包在产线复测又是好的。一开始怀疑网络传输损坏重新下载了好几遍都一样SHA256在终端上算出来的值也和包对不上。我们顺着排查链路走了一遍先看终端日志确认报的是manifest验签失败还是镜像哈希不匹配。日志显示验签那一步就失败了也就是说终端认为signature.bin和manifest.json对不上。接着我们把升级包拿回PC上验证签名发现签名是好的不由得满脑子问号。后来看终端时间发现问题出在签名时的时间戳字段。我们的签名工具在签名时给证书附加了一个有效期终端校验签名时会校验当前时间是否在证书有效期内。终端因为长时间运行没有对时系统时间停留在上一轮OTA之前的某个点导致签名有效性判断失败。升级包本身没问题是设备本地时间不在签名有效期窗口内。这个问题的根子在构建服务器和终端之间对时间信任的假设上。我们做了两个改进一是签名工具去掉对时间窗口的强制校验仅依赖证书链信任关系配电终端这种长时间离线设备不该被时间问题卡住升级二是OTA升级流程强制增加一个对时步骤终端在执行升级任务前先向主站同步时间同步失败则拒绝升级并上报原因。这个案例说明安全启动和OTA的联动调试牵涉的环节比想象中多。不是把签名和分区做对就行签名策略里的每个字段、终端运行环境的每个状态都可能成为链路里最意想不到的那根断点。国产化方案做下来我最大的体会是这套东西真的要尽早验证。硬件选型定了就先把安全启动跑通密钥体系在生产前定好OTA的A/B架构和回滚逻辑提前做完整测试。别等到现场出了第一批货再想着补课配电终端一挂出去就是好几年真出问题的时候手里能用的牌很少。