v2.1.6-diag.1 — reconnect 诊断构建（issue #35/#61）

诊断构建，面向 issue #35 / #61 的 Code 12 排查实验。基线 = 官方 v2.1.6（86700e9），只加两样东西，解锁链路零改动：

1. \tx-reconnect-nonrecursive.txt 标记：存在时强制非递归 reconnect（只绑 vendor GOP，console 栈留给 bootmgfw）。背景：这批板子在 detach 后 GOP handles 清零，v2.1.6 的 stale_pathless_gop() 判定会走 recursive=true 并在固件内死锁（日志停在 RECONNECT: ConnectController (recursive=true) begin）；非递归路径是 PR#13 在 Z790 形态上验证过、从未观察到挂死的变体。
2. HANDOFF-PCI 只读快照（#61 求助点 2）：FLR/verify 之后、reconnect 之前，打印 GPU 配置头 0x00–0x3F、能力表遍历（PCIe DevCtl/LnkCtl、MSI 使能）、每座桥的 Command 与 Bridge Control（VGA 路由位）。与本轮 Windows 侧 pnputil 资源 dump 直接配对，可定位配置空间在哪一侧被动过。

SHA-256：dbc8c1d4019ceaf3f995391d44e16d0dfd901fc18b4a64da4bf29cb96337460f（BOOTX64.EFI，279,552 B，check_efi.py 验 TX banner 通过）

实验步骤见 issue #61 / #35 内的说明。U 盘上必须先删除 \no-reconnect.txt（它的优先级更高，不删则新标记不生效），源码在 diag-reconnect-nonrecursive 分支。

v2.1.6 — SEC2 环境消融矩阵（#17/#57/#62）

Pre-release，#17（TU102 22G）/#57（TITAN RTX 24G）/#62（RTX 2080 TU104-400）的 SEC2 环境消融矩阵。默认行为与 v2.1.4/v2.1.5 完全一致；三个新开关全部默认关闭，一次冷启动只开一个。

本轮背景：几何已验毕，剩余变量收敛到 SEC2 点火环境

#17 复测证实：LOCAL_MEMORY_RANGE 解码（22528 MiB）与 heap 公式（107 MiB）在真卡上全部生效、meta 与 C 成功值逐位一致，仍 0x91。#62 的 RTX 2080（TU104-400，8G 标准卡，几何与成功轮逐位相同）同样 0x91，且 EXCI 与 #17 逐位相同（0x00900100 = EXPC 0x100 取指未命中，falcon v4 EXCAUSE 0x10），而 TU106（40HX）与 TU104-450（2080 Super）在默认路径成功——装载布局三方一致（驱动 s_prepareHsFalconDirect / C 参考 / 本 loader），差异收敛在点火环境。

三个 marker（默认 OFF，各一次冷启动）

marker	作用
\tx-sec2-c-load.txt	C 参考 SEC2 点火：不复位（入口必须已 halted）、FBIF CTL bit7 置位但不改 TRANSCFG（默认路径强制 `(x&!7)
\tx-host-probe.txt	C 参考主机探测写序列（PLM=u32::MAX→0→0xfffffffe、SS0/SS1 探测写并回读；其日志证明这些写会改变可写位，非只读诊断）
\tx-ptimer-seed.txt	C 参考 PTIMER 播种（RTC，"月初+时分秒"——参考实现的日字段缺失原样保留，非精确实时时钟）

组合建议：首选单独 \tx-sec2-c-load.txt（EXPC=0x100 直指装载/点火环节）；若仍 0x91，第二轮加 \tx-ptimer-seed.txt + \tx-host-probe.txt 全开（完整 C 环境等价）。

继承内容

heap 公式化（8+align1MiB(96K×alignUp1GiB)+96，钳位 [88,280] MiB）、LOCAL_MEMORY_RANGE 驱动同源 FB 解码（ECC ×15/16）、\tu10x-fb-gb.txt 回退覆盖，均保持。

测试与判据

1. 只换 BOOTX64.EFI，放对应 marker（纯 ASCII 文件名，内容任意），冷启动（Shift 关机 + 彻底断电）。
2. 每轮附 loader.log，保留 BOOTER-C: / HOST-PROBE: / PTIMER-SEED: / layout inputs: / LOCAL_MEMORY_RANGE 原始行。
3. 判据：BOOTER-C: post-quiet CPUCTL=… mailbox0=0x0 … → SELECTOR RESULT: SS0=0x88888888 SS1=0x8 → PLM relock unlock_persist=true。

产物

• BOOTX64.EFI（rustc 1.95.0，--features tx，tag v2.1.6 → min-tu102-22g@3bb069b）
• SHA256: 279eb6c10e485b582d8368c0583402ed16ffea9ee5c48e146ba735427a69abb3

v2.1.5 — 无路径 GOP 安全重连（PR #13）+ GOP 归属判定修复 + ssdiag 首发

v2.1.5 头条：PR #13（steppergg）合入——修复一类 AMI 固件上"解锁成功后、进 Windows 前平台复位"的问题（无路径 GOP 分裂子句柄幸存 + 递归重连重挂 console 栈）。贡献者在 ASUS ROG MAXIMUS Z790 APEX + RTX 4060 Ti 8 GB（10de:2803，卡跨刷 ROG Strix VBIOS）上完成全链验证：FP16 +70% / BF16 +75%（FP32 对照持平），10 分钟烤机 PASS——据我们所知这是 4060 Ti 8 GB 的首个公开 Windows 解锁。同批合入 GOP 归属判定修复（三例误判同根因）与 ssdiag 首次随 release 分发（Windows 在系统内解锁判定 + 免重启修复）。TU106（1f07）回归通过：启发式在既有机上保持递归重连不变。

Headline of v2.1.5: PR #13 (steppergg) — fixes a class of AMI firmware where the platform resets after a successful unlock, right before Windows (a pathless GOP splitter child survives the detach; the recursive reconnect re-binds the console stack over it). Verified end-to-end by the contributor on an ASUS ROG MAXIMUS Z790 APEX + RTX 4060 Ti 8 GB (10de:2803, card running a cross-flashed ROG Strix VBIOS): FP16 +70% / BF16 +75% (FP32 control flat), 10-minute soak PASS — to our knowledge the first public Windows unlock of a 4060 Ti 8 GB. Also in: the GOP-ownership fix (three misjudgment instances, one root cause) and the first release shipment of ssdiag (in-OS unlock verdict + no-reboot repair on Windows). TU106 (1f07) regression passed: the heuristic keeps the recursive reconnect on existing-verified machines.

---

中文

加载器（BOOTX64.EFI）

• 无路径 GOP 幸存者的安全重连（PR #13）：AMI 固件会在 NVIDIA GOP 之上叠一个无设备路径的 console 分裂子句柄，detach 后它幸存；此前两处递归 ConnectController 会把 console 栈重挂上去并当场复位平台（逐行日志止于 POST-FLR: verified）。现在检测到无路径 GOP 幸存即改为只连 vendor GOP（非递归）——bootmgfw 自己会重建 console；\no-reconnect.txt 可整体跳过重连；链前 map -r 式 pass 不再碰 NVIDIA 显示函数
• GOP 归属判定修复：旧的字节前缀比对把父路径的 END 节点算进比较，而 NVIDIA GOP 子路径用 AcpiAdr + END 替换了那个 END——目标卡自己的 GOP 被判成"别人的"，已三例（issue #14 翻转板、ASUS Z790、TU106 1f07）。改为节点对齐比对（剥 END），多卡安全性不变；9 个真实形状测试在 sim/src/devpath.rs
• 确认键：空格或回车均可继续；banner 三行大字 PRESS SPACE or ENTER to CONTINUE；ABORT 行明确写出 "NOTHING was unlocked this boot (zero GPU writes)"——消除"日志像跑完其实什么都没做"的误判
• 崩溃证据日志：逐行 flush 在慢 U 盘上可见秒级开销、只在 finish 时 flush 则复位后留下 0 字节文件——折中为每 16 行 + 关键阶段行必 flush（PHASE/RESULT/POST-*/FINAL/RECONNECT/DETACH/CHAIN/SELECTOR/HANDOFF/WATCHDOG），文件先于 console
• 事务期间禁用 UEFI watchdog：挂死就停在原地（不会自动复位回 U 盘再来一遍——宪法 §2 同会话不重试），恢复手段 = 断电
• detach 前后输出显示拓扑诊断（GOP 句柄、设备路径长度、OpenProtocolInformation 占用者）
• 宿主 clippy / 测试构建 / loader 三种构建 0 warning

tu10x 高位 >4GB staging：2080 / 2080S / 2070 移动 报告线的修复（v2.1.1–v2.1.4 pre-release 线，本版首次收入 stable）

• 根因（issue #19）：tu10x 的 ">4GB staging" 门实际把 DMA 分配落在 4GB 以下——v2.1.1 的 AllocateMaxAddress(u64::MAX) 撞上厂商固件的 MaxAddress 钳制（上游 EDK2 无此钳制），7 次分配全落 3.2–3.4 GiB，booter 拒收 meta/staging 报 exit 0x91
• 修复（v2.1.2 1dffa86 + v2.1.3 判定修正）：dma_alloc_high 改走 GetMemoryMap 找 ≥4GiB conventional 描述符后 AllocateAddress（确定性，不依赖分配器行为假设），分配全数落 4GB 以上；EFI MEMMAP 常开自动采集（高位无空间时日志直接可见）；HIGH/LOW 标签从实际设备地址推导
• 实证：issue #16（RTX 2070 移动 1f14，无核显独显直连准系统）v2.1.1 报 0x91 → v2.1.3 全链成功，FP16 20.76 → 37.4–38.0 TFLOPS（+80%），时钟不变——已关闭；issue #14（2080S）报告人确认 v2.1.3 完整成功且 tu10x_unlock=true，换回 v0.2.0 复跑 0x91 复现（>4GB staging 即决定因子），GOP 因素 A/B 排除
• 仍开放：issue #17（2080 Ti 22GB 改装卡，TU102 1e07）在 >4GB staging 与 \tu10x-fb-gb.txt 布局扫描（10/22/11 GiB 三轮）下仍 0x91，诊断继续——有该卡的欢迎按 issue 内清单补日志

ssdiag v0.4.8（首次随 release 分发）

Windows 在系统内的解锁状态判定与修复工具（无需重启、无需 U 盘）：

• 判定：OS 自发现每张 NVIDIA 显示卡及其 MMIO 范围（陈旧地址一律拒绝——曾被旧地址硬死机过），转储核心/debug 块 + 双家族 FEAT 簇（Turing 0x4096xx 含 READOUT、Ampere/Ada 0x823xxx），SS0/SS1 == 0x88888888/0x8 即 UNLOCKED（Turing relock 链下该值在 Windows 会话内持久，系统内读回即有效判据；门关则保持只读，重跑 U 盘即可）
• --reapply 免重启修复（separate-lock，issue #6/#19 谱系）：Ampere/Ada 门开着但 SS 覆盖值被驱动 devinit 重推导掉时（驱动初始化、睡眠唤醒、雷电 rail 掉电重枚举），写回 SS0=0x88888888 / SS1=0x8 并读回验证
• 转储面 = 参考 unlocker 寄存器并集：Ada 四写目标（WPR/WPR_CFG/FBPA PLM）、AD10x 64G-BAR1 线（CYA/CFG/XVE/cap 镜像）、cmp170hx 26 寄存器 PLM survey、Ampere FEAT sweep；badf 分桶着色（管道/NO_COLOR 退化纯文本）
• 多卡：逐卡转储、DeviceID 分组、--select 过滤；对读数退化的卡按需经驱动自家 NVAPI GC6Control 唤醒 GC6/GCOFF 停泊卡（4060 Laptop 实测）
• 家族覆盖 Maxwell..Rubin（含 GA10x BOOT_0=0xb7xx00a1 怪癖）；FEAT 判定仅在 Turing/Ampere/Ada 提供
• 驱动安全：pmxdrv.sys（Intel 签名、构建期 hash 钉死、启动期复验 fail-closed）内嵌在 exe 里，部署到自有服务名 SSDIAG_PMXDRV，每条退出路径停服务+删服务+删临时文件；已有 PMXDRV 设备则借用、零服务改动

证据

• docs/ad106-asus-z790-windows-unlock.md：ASUS Z790 + 4060 Ti 8 GB 全链报告（根因、修复表、安全注记、VBIOS 跨刷披露）；匹配 A/B：FP16 8192³ 48.06 → 81.94、BF16 47.78 → 83.53、FP32 12.72 → 12.73（同驱动 581.42、同功率墙 216 W + 同 Afterburner 曲线）；10 分钟烤机 PASS（~182 W，峰值 80 °C，无 Xid/WHEA）
• docs/evidence/tu106-pr13-regression/：TU106 1f07 合并前回归（解锁闭环 + recursive=true 走向与既往一致 + Windows 正常接管），以及 GOP 误判第三例的完整拓扑证据
• docs/evidence/ad106-asus-z790/：replay/unlock 全套日志与 bench 原始 JSON

资产纪律

本 zip 不含任何 NVIDIA 固件（逐文件名扫描核验：无 gsp_/fwimage_/fwsignature_/booter_/sec2_bl_/scrubber_/v67-/.rom；pmxdrv.sys 为 Intel 签名的 Windows 内核驱动，内嵌于 ssdiag.exe，非 NVIDIA IP 亦非散装文件）。全部固件件由 make-usbroot.ps1 / make-usbroot.sh 在构建机上从钉 SHA-256 的 610.43.03 公开输入现场再生；Turing proven BL（0x6000 字节，de676bae…）由脚本从钉 hash 的 cmp50hx 仓库自动获取。

产物校验（SHA-256）

9c615a3f5f16dfbe4800a5c46251cdb20f2886bbb4bec70fecab3400a3c2f7c9  BOOTX64.EFI
48a5cfa8f612750766d0b59788550f36f9aa973cd0b9cf4b62cd0ec93c47183a  assets-x86_64-windows.exe
b13c81a7ffa5f543b558218f7122023175d3c4aa324f02cfbcac83b05dd8edc0  assets-x86_64-linux
9283eaa42b81d66680880fd3264c42117fd77691bfd66c40946540e51f9d2c27  ssdiag-x86_64-windows.exe
82da87394cd2f619cdb85c44c76f2b514e81f908941d91698427961a5eec648e  nv-uefi-unlocker-v2.1.5.zip

---

English

Loader (BOOTX64.EFI)

• Safe reconnect on pathless-GOP firmware (PR #13): AMI boards layer a pathless console splitter child on top of the NVIDIA GOP; it survives the detach, and two recursive ConnectController calls re-bound the console stack over it, resetting the platform on the spot (the per-line log ended exactly at POST-FLR: verified). If a pathless GOP survived the detach the loader now reconnects the vendor GOP only (non-recursive) — bootmgfw re-establishes its own console; \no-reconnect.txt skips the reconnect entirely; the pre-chain map -r-style pass no longer touches NVIDIA display functions
• GOP-ownership fix: the old byte-prefix compare included the parent path's END node, and NVIDIA GOP child paths replace that END with AcpiAdr + END — the target's own GOP read as "foreign" (three instances: the issue #14 flip board, ASUS Z790, TU106 1f07). Now node-aligned (END excluded); multi-GPU safety unchanged; 9 real-shape tests in sim/src/devpath.rs
• Confirm key: Space or Enter proceeds; the banner carries a triple PRESS SPACE or ENTER to CONTINUE; ABORT lines say explicitly "NOTHING was unlocked this boot (zero GPU writes)" — no more runs that look finished but did nothing
• Crash-evidence logging: per-line flush was visibly slow on USB media, finish-only flush left 0-byte files after resets — now every 16th line plus stage/verdict marker lines always flush (PHASE/RESULT/POST-*/FINAL/RECONNECT/DETACH/CHAIN/SELECTOR/HANDOFF/WATCHDOG), file before console
• UEFI watchdog disabled during the run: a hang stays put (no auto-reset back into the stick — constitution §2, no same-session retries); recovery is a power cycle
• Display-topology diagnostics around the detach (GOP handles, device-path lengths, OpenProtocolInformation openers)
• Zero warnings across host clippy, the test build and all loader builds

tu10x above-4GB staging: the 2080 / 2080S / 2070-mobile report line fixed (shipped across the v2.1.1–v2.1.4 pre-releases; first stable to carry it)

• Root cause (issue #19): the tu10x ">4GB staging" gate actually allocated below 4 GB — v2.1.1's AllocateMaxAddress(u64::MAX) hit the vendor firmware's MaxAddress clamp (upstream EDK2 has no such clamp), putting all 7 allocations at 3.2–3.4 GiB; the booter rejected the meta/staging with exit 0x91
• Fix (v2.1.2 1dffa86 + the v2.1.3 verdict rework): dma_alloc_high now walks GetMemoryMap for a ≥4 GiB conventional descriptor and uses AllocateAddress (deterministic, no allocator-behavior assumptions) — allocations land above 4 GB; the EFI MEMMAP is always captured now (if no high memory exists, the log shows it); HIGH/LOW labels are derived from the actual device address
• Proven: issue #16 (RTX 2070 mobile 1f14, no-iGPU dGPU-direct barebone) went from 0x91 on v2.1.1 to a full-chain success on v2.1.3, FP16 20.76 → 37.4–38.0 TFLOPS (+80%) at unchanged clocks — closed; the issue #14 (2080S) reporter confirmed v2.1.3 fully succeeds with tu10x_unlock=true, while re-running v0.2.0 reproduces 0x91 (the above-4GB staging is the deciding factor); the GOP factor was ruled out by their A/B
• Still open: issue #17 (2080 Ti 22GB modded card, TU102 1e07) still reports 0x91 under the above-4GB staging plus the \tu10x-fb-gb.txt layout sweep (10/22/11 GiB rounds) — diagnosis continues; if you have that card, the issue has a checklist for logs

ssdiag v0.4.8 (first time shipped in a release zip)

In-OS Windows tool: unlock-state verdict and repair without a reboot:

• Verdict: discovers every NVIDIA display GPU and its MMIO ranges from the OS itself (stale addresses are refused — a remembered base once hard-hung a machine), dumps the core/debu...

v2.1.4 — \tu10x-fb-gb.txt 显存大小覆盖（22G 改装卡线）+ MEMMAP 常开采集

Pre-release，针对 #17（TU102 22528 MiB）的布局嫌疑线。

#17 已证实：v2.1.3 下 staging 真正落位 4GB 以上（meta=0x10001f000）、GOP 双模式均 0x91（console 变量排除）——剩下的头号嫌疑是 layout 几何：SKU 表喂的是 8192 MiB，而这张卡实际 22528 MiB，booter 会拿 WprMeta 和真实 FB 尺寸对账，参考谱系里"layout 破损"正是 exit 0x91 的成因之一（chenxluo 同类 22G 卡的可用 dmesg 反解出 fbSize=0x280000000=10GiB、heap=0x7F00000——我们表里恰好有这对已证常量）。

v2.1.4 变更

1. \tu10x-fb-gb.txt（纯文本十进制 GiB）覆盖 SKU 表；vga/frts/wpr/heap 全链由这一个数驱动。
2. MEMMAP 采集常开：每 boot 首次分配前自动采集 ≥2GiB 全类型描述符（#17 指出 v2.1.3 只在分配失败时才采，正确批评，已修）。

#17 的建议扫描（每次冷启动一个值）

1. \tu10x-fb-gb.txt 写 10 → 跑（首选：同改装路线的已证配对）
2. 仍 0x91 → 写 22 → 跑
3. 仍 0x91 → 写 11 → 跑

日志确认行：layout: \tu10x-fb-gb.txt override: FB size = 10 GiB + layout: fb=0x280000000 ...。

v2.1.3 — unlock 旗帜修正 + 全类型 MEMMAP 采集 + GOP A/B 标记

Pre-release，针对 #14 翻转后的下一步隔离实验。

#14 用 v2.1.1 成功（46→68 TFLOPS），但日志显示 staging 地址与 v0.2.0 失败时逐字节相同——地址类别在该机上不是判别器。两次构建间事务路径的真实 delta：多卡 GOP 归属检查（v0.2.0 之后才入库）使 console 保持连接（且在该机上是误判：2080S 是唯一的显示设备，自己的 GOP 被当成了别家的）；以及分配器调用路径变化。

v2.1.3 变更

1. 解锁判读修正：tu10x_unlock 改为按 "SS 覆盖值在关门后持续" 判定（relock 链的成功形态）——#14 日志里 SS=0x88888888/0x8 已持续却报 unlock=false 的旗帜 bug 修正。
2. MEMMAP 全类型采集：≥2GiB 的所有内存类型描述符逐条落日志（v2.1.2 只记 conventional）——固件把高位 RAM 标成了什么，正是各板 0x91 差异的未解问题。
3. \tx-gop-disconnect.txt：强制 v0.2.0 的无条件 GOP 断开，用于在同代码上单变量测试 GOP 因素。

#14 报告人的三个引导（每次冷启动一个变量）

1. v2.1.3 默认跑一次：预期继续成功 + 采集内存映射。
2. U 盘根目录放 \tx-gop-disconnect.txt 再跑一次 v2.1.3：若变 0x91 → GOP 断开被实证为该机判别器；若仍成功 → GOP 排除。
3. （可选）换回 v0.2.0 跑一次：若失败 → 构建差异为真；若成功 → 当初的 0x91 是启动状态偶发。

v2.1.2 — >4GB staging 真实现（GetMemoryMap+AllocateAddress，回应 #19）

Pre-release，修复 v2.1.1 的一个关键实现错误（#19 指出，成立）。 不替换 Latest。

#19 的指控与核实结论

• 成立：v2.1.1 的 MaxAddress(u64::MAX) 在三台机器上全部落在 ~1–2 GiB（0x81e83000 等），"HIGH" 标签来自分支而非实际地址——>4GB 理论从未真正上机测试，\tx-low-staging.txt 也是空操作。#17 报告人独立观察到了同一事实。
• 机制描述需更正：EDK2 CoreFindFreePagesI 不是"从最低描述符向上 first-fit"——Target=0、best match 为 DescEnd > Target，即cap 之下最高空闲区间（MdeModulePkg/Core/Dxe/Mem/Page.c）。三台机器落低地址的直接原因：它们的内存映射里 >4GB 处没有更高的 free conventional 区间（高位内存被 carve-out/reserved 占据）。

v2.1.2 修复

1. dma_alloc_high 改为：自己走 GetMemoryMap，在 ≥4GiB 的 conventional 描述符内 AllocateAddress——按 UEFI 规范要么精确落在请求地址要么失败，任何固件上都确定。
2. 无可用高位空间时，把 ≥2GiB 的 conventional 描述符逐条打进日志（#17 要的 EFI 内存映射现在自动采集）。
3. HIGH/LOW 标签改为从实际设备地址推导（#19 要求），PciIo 路径同样。

判别行：TX 段应出现 DMA alloc: N pages ... HIGH dev=0x1_xxxx_xxxx (descriptor ...)——dev= 高于 0x100000000 才是真的。若出现 MEMMAP: conventional ... 列表和 no usable >4GB conventional space，说明该机高位无 free 内存，请回传日志。

测试步骤同前：备份并替换 \EFI\BOOT\BOOTX64.EFI，7 个 tu10x 资产不动，冷启动一次，回传完整 loader.log。

v2.1.1 — tu10x >4GB staging 诊断版（issues #14/#16 的 booter 0x91）

Pre-release, 诊断/修复验证版 — 面向 issue #14 / #16 的 0x91 失败。 不替换 Latest（v0.2.0）。

只包含 BOOTX64.EFI，放到你现有 U 盘的 \EFI\BOOT\BOOTX64.EFI（覆盖前备份旧文件）。7 个 tu10x 资产不动。

变更（commit 896f7fa）

1. tu10x 专用 >4GB staging：WprMeta/签名/radix 等全部 booter 可读缓冲优先分配在 4GB 以上（驱动本体的 proven 配置，live dump meta=0x110BB0000）。cmp50hx/chenxluo 谱系记载 sub-4GB sysmem 读在某些卡上被锁 → booter exit 0x91——正是 #14/#16 的签名。GA10x/Ada 路径逐字节不变。
2. booter 前后取证：点火时 meta 地址与 mailbox 写值、运行中 mailbox 实时轮询（中间状态码在 halt 前会被最终码覆盖）、halt 后 SEC2 FBIF 审计、按实测数据出 DMEM 判读行。
3. A/B 开关：U 盘根目录放 \tx-low-staging.txt = 强制回退旧路径。

判读

• 新构建横幅显示 v2.1.1，且 TX 阶段开头出现 TX: >4GB staging gate: true (family tu10x)、DMA alloc: N pages ... HIGH dev=0x...——没有这两行就是旧文件没换成功。
• 成功判据不变：PLM 翻转 + HANDOFF-OUT tu10x_unlock=true。
• 若仍 0x91：新日志的 mbox live 行、post-halt SEC2 FBIF 行、fire meta dev= 行会是关键判读材料，请回传完整 loader.log。

QEMU 负控覆盖不到此路径（无 NVIDIA 设备，事务阶段不执行），首次验证即真机。安全模型不变：易失、FLR/断电回滚、不写 ESP、无常驻引导项。

v2.1.0 — 多系统构建 + 白名单全开（30 系 GA10x 实测转正，issue #11）

2026-10-28 转正为 stable：issue #11 的 RTX 3060 Ti LHR（GA104）报告人用本版解锁成功——MSI B450M 迫击炮 + 5700X3D（AMD 平台），卡刷过映众冰龙 3060 Ti VBIOS（跨 VBIOS 亦正常），截图与 loader.log 见 issue。30 系 GA10x 成功判据修复实证有效（#6：V67 载荷从不 HALT、无 marker，权威判据 = PLM 读回等待；旧判据会把实际成功的解锁误报为失败）。相对 v0.2.0 的加载器改动（白名单全开、chain-target、武装模式等）至此有 GA10x 真机全链佐证；Turing 轨 tu10x >4GB staging 诊断另见 v2.1.1。

Promoted to stable on 2026-10-28: the issue #11 reporter (RTX 3060 Ti LHR / GA104, MSI B450M Mortar + 5700X3D — AMD platform; the card runs a flashed Inno3D iChill 3060 Ti VBIOS) confirmed a successful unlock with this build — screenshot and loader.log in the issue. The GA10x success-verdict fix is confirmed effective on 30-series silicon (#6: the V67 payload never HALTs and sets no marker; the authoritative verdict is the PLM read-back wait — the old criterion misreported actually-successful unlocks as failures). The loader changes since v0.2.0 (fully-open ID whitelist, chain-target, armed mode, etc.) now have full real-machine GA10x evidence behind them; for the Turing tu10x >4GB staging diagnostics see v2.1.1.

---

中文

加载器（BOOTX64.EFI）

• 多卡缺省逐张处理全部受支持卡（EALREADY/不支持自动让位、单卡失败只 emergency-FLR 不阻断；\tx-select-bdf.txt 仍可钉单卡）
• 确认环节改为空格键；新增武装模式 \i_know_what_i_am_doing.txt（5 秒倒计时后自动运行，倒计时内按任意键终止——无人值守/自动化用）
• 新增 \chain-target.txt：双系统用户可把自定义 EFI 路径插到链回顺序最前（issue #8 建议）；引导器候选链新增 Limine
• 设备 ID 白名单对 Turing/Ampere/Ada 全开（按家族路由；GA100 mismatch 移除）——⚠️ 无上游硅证据的 ID（如 AD106 2820 魔改卡）首跑请附 \loader.log 全文，验证后再升级矩阵层级
• 构建时间戳改用系统时钟 API（PR #7）

工具链（本版主打：多系统构建）

• 新增 Linux/WSL/Git Bash 版 USB maker：make-usbroot.sh，参数与 PowerShell 版一一对应（--family/--out/--work/--assets/--boot-efi/--proven-blob/--skip-gsp-check）
• release 首次附带 Linux 版资产管线 assets-x86_64-linux（glibc ≥ 2.34，Ubuntu 22.04+/Debian 12+；zip 不带执行位，脚本会自动 chmod +x，或用 bash make-usbroot.sh 运行）
• tu10x 的 GSP 门在 Linux 端读 nvidia-smi 运行态（545+ 驱动对 Turing+ 缺省 GSP-RM，门拦"驱动过旧"与"modprobe 强关 GSP"两种 legacy 态）；全族构建时探测本机 RTD3 并给出 issue #9 提示
• 离线兜底：仓库检出内无预编译管线时自动 cargo build -p assets

文档（README 中英双语）

• 新增「Linux 用户注意：runtime D3（RTD3）会在交接后擦掉解锁」+ 排障表（issue #9：modprobe.d 同名 basename 遮蔽规则、initramfs 重建、生效值读回）
• 新增「雷电/热插拔根口 eGPU：解锁易失环境（已知限制）」（TB 隧道重建 ≈ hot reset/PERST#；受支持环境 = 原生插槽/独显直连）

资产纪律

本 zip 不含任何 NVIDIA 固件（逐文件扫描核验：无 gsp_/fwimage_/fwsignature_/booter_/sec2_bl_/scrubber_/v67-*/gsp_rm_boot_dbg.bin）。全部固件件由 make-usbroot.ps1 / make-usbroot.sh 在构建机上从钉 SHA-256 的 610.43.03 公开输入现场再生，产物 hash 硬校验；Turing proven BL（0x6000 字节，de676bae…）由脚本从钉 hash 的 cmp50hx 仓库自动获取。

产物校验（SHA-256）

b5e96f4e0ca162b98693af00452a6933ea47dd7e24f0d4b3c804b48a05ec9dea  BOOTX64.EFI
59f311ffe0be8e62951e1cf350e1703f9d67f86f1a989c99c0b1511bceb0c1d4  assets-x86_64-windows.exe
c515a60baa526220e1749869965d3ea18019c92f28581daef7cfdf92db70bb0e  assets-x86_64-linux

---

English

Loader (BOOTX64.EFI)

• Multi-GPU default is now "process every supported card" (EALREADY/unsupported cards yield; a single-card hard failure only emergency-FLRs that card; \tx-select-bdf.txt still pins one card)
• The confirm key is now Space; new armed mode via \i_know_what_i_am_doing.txt (a 5-second countdown then runs automatically; any key during the countdown aborts — for unattended/automated use)
• New \chain-target.txt: dual-boot users can put a custom EFI path first in the chainload order (issue #8 suggestion); Limine added to the loader candidate chain
• The device-ID whitelist is now fully open for Turing/Ampere/Ada (per-family routing; GA100 mismatch removed) — ⚠️ for IDs without upstream silicon evidence (e.g. the AD106 2820 modded card), please attach the full \loader.log on the first run so the matrix tier can move up only after verification
• Build timestamp now comes from system clock APIs (PR #7)

Tooling (the headline of this release: multi-OS builds)

• New Linux/WSL/Git Bash USB maker: make-usbroot.sh, with options mapped 1:1 to the PowerShell version (--family/--out/--work/--assets/--boot-efi/--proven-blob/--skip-gsp-check)
• The release ships a Linux asset-pipeline binary assets-x86_64-linux for the first time (glibc ≥ 2.34, Ubuntu 22.04+/Debian 12+; zips carry no exec bits — the script chmod +x's it automatically, or run via bash make-usbroot.sh)
• The tu10x GSP gate on Linux reads the nvidia-smi runtime state (545+ drivers run GSP-RM by default on Turing+; the gate catches "driver too old" and "GSP force-disabled via modprobe config"); all families get an RTD3 probe with an issue #9 notice at build time
• Offline fallback: inside a repo checkout without the prebuilt pipeline, the script runs cargo build -p assets automatically

Documentation (README, bilingual zh/en)

• New section "Linux note: runtime D3 (RTD3) erases the unlock after handoff" + triage table (issue #9: the modprobe.d same-basename shadowing rule, initramfs rebuild, effective-value read-back)
• New section "Thunderbolt / hot-plug root port eGPU: a volatile-unlock-hostile environment (known limitation)" (TB tunnel re-establishment ≈ hot reset/PERST#; supported environments = native slots / dGPU-direct)

Asset discipline

This zip contains no NVIDIA firmware (verified by a per-file scan: no gsp_/fwimage_/fwsignature_/booter_/sec2_bl_/scrubber_/v67-*/gsp_rm_boot_dbg.bin). Every firmware file is regenerated on the build machine by make-usbroot.ps1 / make-usbroot.sh from the SHA-256-pinned 610.43.03 public inputs with hard artifact-hash verification; the Turing proven BL (0x6000 bytes, de676bae…) is fetched by the script from the pinned cmp50hx repository.

Artifact hashes (SHA-256)

b5e96f4e0ca162b98693af00452a6933ea47dd7e24f0d4b3c804b48a05ec9dea  BOOTX64.EFI
59f311ffe0be8e62951e1cf350e1703f9d67f86f1a989c99c0b1511bceb0c1d4  assets-x86_64-windows.exe
c515a60baa526220e1749869965d3ea18019c92f28581daef7cfdf92db70bb0e  assets-x86_64-linux

v0.2.0 — Turing (RTX 20 系) 解锁轨：TU106 实测 +67~75%

Turing (RTX 20 系) 解锁轨落地

RTX 2070 (TU106, 10de:1f07) 实测闭环：FWSEC 点火 → BOOT_DIRECT booter → V67 起爆 → FEAT PLM (0x409650) 全开 → SS0/SS1 写入读回 → 签名还原 → 无 FLR 交棒。Windows GSP 固件模式下 FP32 累加 GEMM 36 → 60–63 TFLOPS（+67~75%），落在 chenxluo 2080Ti 22G 同类 Linux 解锁性能测试参照带（+51~75%）内。

包内只有脚本与自产二进制（不含任何 NVIDIA bin）

资产全部由 make-usbroot.ps1 从钉 SHA-256 的公开输入现场再生，产物逐级 hash 校验，不符即硬失败。20/30/40 三族可选：

.\make-usbroot.ps1 -Family tu10x -Out E:\   # 20 / 16 系（rtx20 / 20 同义）
.\make-usbroot.ps1 -Family ga102 -Out E:\   # 30 系（rtx30 / 30 同义）
.\make-usbroot.ps1 -Family ad102 -Out E:\   # 40 系（默认；rtx40 / 40 同义）

Turing 的实证 BL 归档 gsp_rm_boot_dbg.bin 由脚本自动从钉 SHA-256 的 cmp50hx 仓库下载；离线时用 -ProvenBlob <path> 指本地文件。gsp_boot_tu10x.bin 必须是 24576 字节（0x6000，GSP_RM_BOOT_SIZE）、SHA-256 de676bae…——这是 v0.2.0 实测成功那一火的输入（loaded 24576/24576）。GSP ELF 前 0x6000（c76c43b1…）和 4 KiB BINDATA v4 图都不是它，maker 对源归档与输出双层校验。

Turing 用户必读：GSP 固件模式前置

Turing 的 Windows 驱动只有在 GSP-RM 模式下才接受 pre-OS 解锁态（legacy 路径会 TDR/Code 43；40 系/Ada 无此要求，v0.1.x 用户不受影响）：

# 管理员 PowerShell，运行一次（脚本在包根目录）
.\enable-turing-unlock.ps1

脚本自动枚举显示类下的 NVIDIA Turing 卡（按 MatchingDeviceId 识别 0x1E02–0x1FFF / 0x2182–0x2192 段）写 EnableGpuFirmware=1。更换驱动模式必须！！！重启（Restart）生效，不要依赖休眠恢复（更换完了之后一直GSP模式是可以休眠恢复的）（休眠恢复不重新初始化驱动，旧会话遇解锁态会 TDR）。

make-usbroot.ps1 -Family tu10x 在构建时强制双检：注册表 EnableGpuFirmware=1 且 nvidia-smi 报告 GSP 固件运行中，任一不满足即拒绝并给出上述修复步骤；异机构建加 -SkipGspCheck。通过的构建会在 U 盘根写 gsp-gate.txt 存档。

Turing U 盘根布局（40 系五件 + 两件）

• 40 系原有五件不变（ad102 资产仍兼容）
• 新增 sec2_bl_tu10x.bin（768B）+ v67-tu10x-four-plm.bin（64000B）
• gsp_boot_tu10x.bin 为 24KB 实证切片（非旧 4KB）

机制要点（全部读回验证，16 火证据链见 docs/evidence/m3-tu106/）

• Turing FEAT 块在 0x4096xx（0x823xxx 是另一个锁定块——M1 旧结论已改写）
• Turing FEAT PLM 非 AON：FLR 会重锁，tu10x 链不跑 FLR（与 Ada 的代际差异）
• 出厂钳制实测：SS0 冷值非默认（0x15000/0x11000/0x0 引导间漂移）——"20 系无 segmentation"旧假设修正
• PLM re-lock（开门写字关门）实测不可行：SS 覆盖与门绑定，解锁必须门开交付

兼容性

• TU106 1f07 ✅ 本机实测；TU102/TU104/TU116 🟢 同族资产+社区硅验证（2080Ti 谱系）
• 40 系（v0.1.x 用户）不受影响，无注册表要求
• GA10x 仍为 🟡（无 EFI 硅证据）
• TU11X 16系 待实测

SHA-256（发布件）：

BOOTX64.EFI              6788aa5a799f8c931714aecd3e86e93a8e33525059edf82cdde00f603e99a321
assets-x86_64-windows.exe e0c2fe786c847b49b94a0bab392bd0e066b600c18ca512954f17a6172dc23c2d
make-usbroot.ps1         74ee4ec6053c108eb4853d554c05a47713e3894e2c6cd3f34bd3df36790da42d
enable-turing-unlock.ps1 4e7f55222fae36cba98d6d7c246dd7101f47fc273d85a0e58d319536f4edbf42
zip                      f57d27935be1bec058ac8741c6ecd8b960a06ae7e4775f33e841a0307c1c11c0

SHA-256（现场再生的关键产物，用于核对）：

gsp_boot_tu10x.bin       de676bae28a480011d3d012db14bef539324e62a841a9627863c689bea168af3  (24576B)
v67-tu10x-four-plm.bin   b0ec90294d1de3c67e024631c0a11000f281470d76eed806fc24c66b7fd1ef41
sec2_bl_tu10x.bin        f21f1cfbb8fffa8067685314367fc4c50f3f84dd99eda7c19db4292d9269b9d9

v0.1.4 — desktop fix（桥 Bus Master 修复）

v0.1.4 — desktop fix release（台式机修复版）

Fix / 修复: booter status 0x89 on desktop machines. The loader now enables Bus Master on the GPU's upstream PCI bridges before firing the booter, and restores the original state afterwards (PR #5 by @8bit2qubit). Root cause: desktop firmware leaves the GPU's upstream bridge without bus master, so the booter's first device-initiated DMA was aborted at the root port (Received Master Abort, PCI status bit13) and the booter read all-1s. Vendor-independent — reproduced on H310 / B760 / B850 desktops. Full mechanism: docs/bridge-bme-root-cause.md.

台式机 booter status 0x89 已修复：loader 现在会在 booter 点火前自动为 GPU 上游 PCI 桥使能 Bus Master 并读回确认，事务结束后原样还原（PR #5，感谢 @8bit2qubit）。根因是台式固件未给上游桥开 Bus Master，booter 的第一笔设备 DMA 在根端口被终结。与芯片组厂商无关（H310 / B760 / B850 均复现），机理详见 docs/bridge-bme-root-cause.md。

New verified silicon / 新增验证卡: AD106 RTX 4060 Ti desktop (2803) — replay + unlock + four writes read back verified; GEMM 8192³ FP16 46.78 → 75.28 TFLOPS, BF16 47.24 → 76.71 (docs/evidence/ad106-4060ti-desktop/)。AD106 桌面实测：FP16 45.12→68.87 / 46.78→75.28，BF16 47.24→76.71 TFLOPS。

Also in this build / 本版另含:

• warm/resume entry preflight (entry D-state check, D0 pull-up with readback; optional x-require-d0.txt abort gate) / 休眠恢复入口预检
• HANDOFF-OUT exit-state log line / 交棒前出口状态行
• GOP reconnect after the transaction / 事务后 GOP 重连
• DMA-PATH / BRIDGE-BME diagnostic log lines (always on) / DMA 路径取证日志
• named 0x89-0x90 hint + CPU-side meta readback / 0x89 具名提示与 meta 回读
• marker-gated experiments (off by default): x-force-continue.txt, x-meta-in-vram.txt（实验开关，默认关闭）

BOOTX64.EFI SHA-256: 50b0a4609fd6638ff8d19363ffee963e8d1b30bfcdcafbdd321363c4f37bb5ac

Usage unchanged: make-usbroot.ps1 (or manual FAT32 layout) → boot from USB → Space to proceed; 30 s timeout aborts safely to Windows. 用法不变：U 盘启动，空格确认，30 秒超时安全回退 Windows。