结论：AMD GPU 的固件链里，「固件加载成功」「GPU 队列可工作」「模型输出有效」是三个不同状态：PSP 把经过选择的镜像交给 sOS 后，后续 SMU/GFX/SDMA 才依次使用。固定 SHA-256 只保证字节与清单一致，不等于签名、可信发布者或运行时兼容性证明；而 _ring_submit() 的写指针未见软件取模，属待验证项而非已定性缺陷。
本文依据固定归档的 AMFirmware 与 AM_PSP 做静态源码与纯内存探针分析。这是 AMD GPU 计算设备的启动链，不是车辆控制或 panda 安全固件链；没有下载固件、访问 GPU/车辆、发送 CAN 或执行刷写。系统总图与 AM IP 启动顺序属于相邻专题。
主调用与关键函数
AMDev.init_sw() 先构造 AMFirmware，再创建七个 IP 对象并依次调用 init_sw()；GPU 硬件启动期间，AMDev.init_hw() 按传入 IP 顺序调用 init_hw()。数据流依次是：IP 版本 → load_fw() → 按头部拆 SOS 与 IP 描述符 → PSP msg1 缓冲 → bootloader 装 sOS → 创建 ring → TOC 与 TMR → SMU 与其他 IP 固件命令 → 后续 GPU IP 初始化。
| 入口 | 具体职责 | 需要验证的边界 |
|---|---|---|
AMFirmware.__init__() |
按 MP0/MP1/GC/SDMA IP 版本选文件；拆 SOS；形成 SMU、SDMA、PFP/ME/MEC、IMU、RLC 等描述符 | 固件集合必须与芯片/IP 版本、头部版本和硬件启动模式一致 |
load_fw() / fetch_fw() |
从本地 amdgpu 固件目录解压并比对固定 SHA-256；本地无匹配文件时取固定修订再校验哈希 |
哈希保证字节与清单一致，不等于签名或运行时兼容性证明 |
desc() |
以头部给出的 offset/size 切 memoryview，挂接 PSP 固件类型 |
普通切片会截短越界长度，未显式确认 len(slice)==size |
AM_PSP.init_sw() |
USB 路径用 SYS 映射 msg1；非 USB 路径用 VRAM；分配命令、fence、64 KiB ring，并设置 boot-time/autoload TMR 标志 | 物理/MC/虚拟地址单位、映射寿命和 DMA 可见性不能交给通用算法插件 |
init_hw() |
缺 sOS 时逐项经 bootloader 加载；重建 ring；可选 TOC/TMR；先 SMU，再设 TMR，后载各 IP 固件；最后处理 RLC | 启动依赖顺序是状态机，不宜平铺为可任意重排的插件钩子 |
_prep_msg1() / _bootloader_load_component() |
复制固件到 msg1，补 4 字节并按 16 字节填充，flush HDP；bootloader 经消息寄存器读取地址及组件 ID | 长度断言只检查原始数据，未覆盖追加和对齐后的长度 |
_ring_create() / _ring_submit() |
销毁旧 ring 后创建；写命令与 frame，推进写指针，等 fence，再查响应 status | ring 写指针没有显式按 ring_size 取模，硬件语义尚未确定 |
固件来源与信任边界
load_fw() 用 ctypes.from_address() 读取版本头和具体头部，desc() 与 SOS 拆分依赖固件给出的数量、偏移、长度。固定哈希减小意外字节变更风险，但不足以替代解析边界检查。缓存文件、镜像哈希、芯片版本、驱动版本应一起进入部署清单与启动审计。
| 信任环节 | 当前做法 | 它能证明什么 / 不能证明什么 |
|---|---|---|
| 镜像完整性 | 解压后比对固定 SHA-256；必要时取固定修订再校验 | 证明字节与清单一致；不证明签名或可信发布者 |
| 头部解析 | 按头部 offset/size 切 memoryview |
依赖固件自报数量/偏移/长度；需补结构/长度校验 |
| 离线部署 | 车端需预置并锁定镜像 | 无网络时无法即时取固定修订，必须提前锁定 |
| 启动结果 | 命令返回 status==0 |
不能扩大解释成整个 GPU 或模型健康 |
已确认边界与未验证问题
纯内存探针直接调用 _prep_msg1()，提供 32 字节 memoryview 与假的 flush_hdp()，未触碰设备：输入 16、28 字节成功；29、32 字节通过现有断言，但因追加 4 字节后填充到 16 字节导致结构不匹配的 ValueError；33 字节由断言拒绝。因此检查对象应是填充后的长度。该结果只证明函数缓冲边界，不代表现实固件恰好接近 msg1 容量。
| 问题 | 证据 | 当前定性 |
|---|---|---|
| msg1 长度检查对象 | 探针：28 字节通过、29 与 32 字节在填充后报结构不匹配、33 字节被拒 | 应检查填充后的长度，而非仅原始长度 |
| ring 写指针回卷 | 用 ring_paddr + prev_wptr * 4 定位 frame，未见软件取模；模拟实现也线性取 frame |
待验证项，不将其定性为实机越界缺陷 |
| desc 切片越界 | 普通切片会截短越界长度，未显式确认长度相等 | 后续加载前需做结构/长度校验 |
_ring_submit() 用 ring_paddr + prev_wptr * 4 定位 frame，未见软件取模；MockPSP._ring_submit() 也按旧写指针线性取 frame，不会证明真实硬件自动回卷。需要先获得 PSP 对写指针单位、回卷规则和 ring 最大积压的文档或设备跟踪，再用小 ring 故障注入验证。
TMR 与命令编码各有边界：_tmr_init() 由 TOC 响应给出 TMR 大小，部分启动从 scratch5 恢复大小，再按平台模式申请并提交 TMR——scratch 恢复值及内存保留关系须经冷/暖启动台架确认。_load_ip_fw_cmd()、_load_toc_cmd() 与 _rlc_autoload_cmd() 把镜像、TOC 或自动装载请求编码为 PSP 命令，但不能把命令返回 status==0 扩大解释成整个 GPU 或模型健康。
启动顺序本身也是契约的一部分：init_hw() 先经 bootloader 逐项加载 sOS，重建 ring，可选 TOC/TMR，然后先 SMU、再设置 TMR、后载入各 IP 固件，最后处理 RLC。把这条依赖顺序平铺成可任意重排的插件钩子，会丢掉「前一步未就绪则后一步无意义」的状态约束。
对自制硬件与插件化的结论
将 PSP/MMIO/DMA/固件装载封在受信任设备驱动，只向推理插件暴露带版本的「设备发现、固件校验、内存就绪、队列就绪、任务完成」能力及健康状态。
- 插件不得提供任意固件路径、物理地址、PSP 命令或重置入口。
- 新车载算力平台可替换计算驱动，但必须独立通过固件/ABI、内存一致性、冷暖启动、异常清理和模型数值/时限验证。
- 最终车辆输出仍受车型适配和 panda 板端 safety 约束，不能因「固件加载成功」就授权执行。
- 启动依赖顺序是状态机，不应把步骤平铺为可任意重排的插件钩子。
边界说明：本专题没有 GPU、实车或 LFS 模型验证证据；探针只证明函数缓冲边界。
常见问题
固件加载成功就等于 GPU 能跑模型吗？
不等于。PSP 把经过选择的镜像交给 sOS 后，后续 SMU/GFX/SDMA 才依次使用；「固件加载成功」「GPU 队列可工作」「模型输出有效」是三个不同状态，命令返回 status==0 不能扩大解释成整个 GPU 或模型健康。
固定 SHA-256 能证明固件可信吗？
不能。哈希只保证字节与清单一致，不等于签名、可信发布者或运行时兼容性证明。离线车端还需要预置并锁定镜像，并把缓存文件、镜像哈希、芯片版本、驱动版本一起纳入部署清单与启动审计。
_ring_submit 的写指针没有取模一定是缺陷吗？
不能下这个结论。源码用 ring_paddr + prev_wptr * 4 定位 frame，未见软件取模，模拟实现也按旧写指针线性取 frame，不会证明真实硬件自动回卷。这是待验证项，需要文档或设备跟踪，再用小 ring 故障注入验证。
为什么消息缓冲的长度断言要按填充后的长度？
因为探针显示：输入 29 或 32 字节虽通过现有断言，但因追加 4 字节后再填充到 16 字节而对齐结构不匹配并报错；28 字节可以成功，33 字节被断言拒绝。所以检查对象应是填充后的长度，而不是仅原始长度。
延伸阅读
- AM 设备 IP 启动：部分复位与生命周期 —— 承接本文的 IP 启动顺序与依赖状态机。
- tinygrad 与 Chestnut 的 USB/AMD 桥接 —— 说明计算设备在整机中的位置与可见性。
- panda bootstub 签名与刷写边界 —— 对照车辆侧固件「签名 vs 哈希」的信任口径。
- Ed25519 签名加事务记录：让 MCU 升级不怕中途断电 —— 类比「可信加载与原子回滚」的分层设计。
参考资料
- 项目 02 ——
openpilot-research/TINYGRAD_AM_PSP_FIRMWARE_BOOT_RING_TRUST_CONTRACT_DEEP_DIVE.md（取用了AMFirmware/AM_PSP函数索引、固件信任边界、msg1 与 ring 的探针结论）。 - 项目 02 ——
openpilot-research/TINYGRAD_AM_DEVICE_IP_BOOT_PARTIAL_RESET_LIFECYCLE_DEEP_DIVE.md（仅用于确认 AM IP 启动顺序，未取用其未公开内容）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复