结论：外置计算模块的固件刷写里，脚本退出码 0 不等于升级完成。刷写脚本对镜像只做长度上限、魔数、字节校验和与 CRC32 的格式/传输完整性校验，它不是来源认证或数字签名验证；更关键的是，ROM 恢复已提交但设备没有重新出现时，脚本仍会正常返回，上层据退出码 0 记为「刷写成功」，而此时运行态镜像并未被回读校验。正确的做法是把「发现、写入、激活、运行」拆成六种状态，不让一个布尔值吞掉它们。
它是什么，也不是什么
该模块通过 USB/PCIe 接入外置 GPU，服务于大模型推理，属于推理设备。它不是车辆 CAN 安全网关：车辆控制输出仍须经过原有的车辆接口、进程与 panda 安全链。这条定位决定了后面所有设计约束——外置模块可以失联、可以回退，但不能绕过控制安全链。
发现与状态：USB 快照不是同步断线检测器
设备发现从系统总线读取 VID/PID、链路速率、产品字符串、链路错误与接口朝向，再写入设备状态；其中「模块在位」的判定只识别运行态 VID/PID，不要求产品字符串版本匹配。状态线程约每 10 秒或总线拓扑变化时更新一次快照，队列容量为 1，主线程可以沿用旧值。因此它是一份采样快照，不是同步的断线检测器——真正判断「用哪个模型」的是另外两层证据。
刷写路径：格式校验不等于来源认证
刷写入口读取内置封装镜像，检验封装格式、产品字符串与调用方期望版本；已匹配则跳过，并设定 600 秒全局预算。镜像校验检查的是长度上限、魔数、字节校验和与 CRC32——这些字段能发现传输或格式损坏，但不能证明镜像来源或版本内容不可替换。固件写入按 4 KiB 扇区擦除、128 B 页写入，并逐页与整扇区回读验证；配置页备份为 0x100 字节，且备份文件以主机名确定路径，已有备份会优先于当前设备配置。
| 校验 / 步骤 | 检查什么 | 不保证什么 |
|---|---|---|
| 格式与产品字符串 | 封装结构、目标产品名、期望版本 | 不证明镜像内容可信 |
| 长度上限 / 魔数 / 校验和 / CRC32 | 传输与格式完整性 | 不是来源认证或数字签名 |
| 页 / 扇区回读 | 写入范围与内存目标一致 | 不证明新固件已启动 |
| 配置页备份（0x100 字节） | 保留设备侧配置 | 备份与具体设备的绑定需台架确认 |
六种状态不该合并成一个退出码
刷写与恢复会经过多条分支，每条分支得到的「证据」并不相同：首次发现时无设备会直接正常返回（没写入、没激活）；产品字符串已匹配且未强制刷写会直接返回（只核对枚举字符串，没读闪存）；普通路径完成写入并回读一致后才调用激活；而 ROM 路径若已提交但仍停留在 ROM 或已离线，恢复函数返回失败，外层却正常返回，于是退出码 0 被记成「成功」。此外，激活函数的所有普通完成分支都返回空值——调用方无法从返回值判断设备到底是否已激活并重枚举。
| 源码分支 | 脚本退出码 / 上层状态 | 实际得到的证据 |
|---|---|---|
| 首次发现时无设备 | 正常返回，记为已刷写 | 仅说明发现时无设备，未写入、未激活 |
| 产品字符串已匹配且未强制 | 正常返回，记为已刷写 | 只核对枚举字符串，未读闪存、未验证 GPU/PCIe |
| 普通路径完成写入并回读 | 调用激活，正常返回 | 写入范围与内存目标一致，不一定代表已启动 |
| ROM 已提交但仍停留 ROM 或离线 | 恢复返回失败，外层正常返回 | 未完成运行态回读校验，属「提交成功 / 验证完成」混淆 |
| 镜像、备份、读写或预算抛异常 | 退出码 1，记为失败 | 明确失败，但不自动说明设备是否仍可恢复 |
重试额度同样是状态的一部分：尝试次数在进程生命周期内不复位，产品字符串恢复匹配只清「已刷写」标志，不清尝试次数；同一进程用满三次后，即使后来版本又出现不匹配，也不会再自动重试。600 秒预算是协作式收敛预算，只在重试/恢复循环的调用点检查，不是能中断所有 USB 操作的硬截止。
模型回退与插件约束
推理侧的设计是分层的：先尝试加载并预热大模型，超时或失败则走小模型；运行中大模型异常也会回退，并把状态写入消息供上层生成加载/失败事件。监测主题标称 10 Hz，但 USB 不存在时监测线程不会按 10 Hz 发送有效消息。插件化时，固件维护接口应返回分离的状态：未找到、已匹配、已写入并验证、等待激活、运行态已验证、失败，并附目标设备身份、镜像摘要、采样时间与失败阶段；重试额度应绑定设备/版本/维护事务，而不是复用进程内布尔值。安全侧只有运行态重新枚举、产品版本与推理健康全部确认后，才能把模块标记为可用——这仍不能替代车辆控制安全链的验证，外置模块也不得获得发送 CAN 的权限。
常见问题
镜像通过 CRC32 校验，就能说明固件可信吗？
不能。长度上限、魔数、字节校验和与 CRC32 属于传输与格式完整性校验，用于发现损坏或截断；它不是来源认证或数字签名验证，改变镜像内容并重新计算校验值后仍可通过校验，因此不能据此判断镜像来源或版本不可替换。
刷写脚本返回成功，就代表升级完成了吗？
不一定。ROM 恢复已提交但设备未重新出现时会返回失败，外层却正常返回、退出码 0 被记成成功，而此时还没有完成运行态镜像校验；激活函数也无法从返回值告知调用方设备是否真的已激活并重枚举。
为什么要有三次尝试上限？
为了限制自动刷写的次数与风险。尝试次数在进程生命周期内不复位，产品字符串恢复匹配也只清「已刷写」标志、不清次数，因此同一进程用满三次后不会再自动重试，避免在异常设备上反复写入。
外置计算模块能接管车辆控制吗？
不能。它只是推理设备，车辆控制输出仍须经过原有的车辆接口、进程与 panda 安全链；固件升级是驻车维护事务，模块本身不得获得发送 CAN 的权限，也不能替代独立安全网关。
延伸阅读
- Ed25519 签名加 96 字节事务记录：让 MCU 升级不怕中途断电 —— 讲真正的签名与断电恢复，与本文「格式校验非签名」形成对照。
- EdgeDeploy：BLE 与 USB 两条通道怎么把签名包送到 ESP32-S3 —— 另一条 USB 传输通道的断点续传与校验设计。
- 固件指纹与模糊匹配：怎么判断设备到底刷了哪版 —— 版本识别与刷写结果核验的补充视角。
- 更新器的暂存与激活：为什么安装要分成两步 —— 「写入」与「激活」分离的通用做法。
参考资料
- 项目 02 ——
openpilot-research/CHESTNUT_USB_FIRMWARE_DEEP_DIVE.md（USB 发现、固件刷写路径、镜像与备份、ROM 恢复、模型回退与插件约束）
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、周期与配置均出自源文档，标注为未验证的结论保留其原有边界；刷机动作未被实际执行。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复