一台 ThinkPad X61，差不多 20 年前的老笔记本，最近跑上了 coreboot。

这事小得很技术，也大得很现实。作者用 Claude Opus 4.6 配合 Ghidra、radare2，把原本可能耗时 3 到 6 个月的固件逆向，压到几周级别。

但这不是“两条 prompt，AI 自动移植”的神话。作者自己也否认了这种说法。更准确的版本是：AI 帮老练工程师少走弯路，但还不会替人理解硬件。

X61、coreboot、AI 逆向，到底发生了什么

ThinkPad X61 用的是 Intel GM965 北桥和 ICH8 南桥。麻烦在于，这个平台缺少公开泄露文档。

GM965 和后来 X200 上的 GM45 有相似处，ICH8 和 ICH9 也有亲缘关系。但固件移植不能靠“像”。寄存器、位宽、初始化顺序，差一点就是黑屏。

过去有人用 SerialICE 之类工具做过尝试：让固件在 QEMU 里跑，把 IO 和 MMIO 转发到真硬件上追踪。但这些尝试没有形成可用移植。

这次路径更像一次 AI 辅助固件拆解。

环节具体做法价值
材料来源从 Phoenix 厂商 BIOS 提取模块拿到可分析对象
分析工具Claude Opus 4.6 + Ghidra-cli + radare2拆 16 位实模式代码和 PE32 raminit
核心目标分析 raminit、寄存器、初始化流程让内存初始化跑起来
当前状态X61 跑上 coreboot，并进入上游审查从个人 hack 走向可维护代码

作者还发现 BIOS 里至少有 3 个 raminit 版本，疑似 A/B 或恢复布局。其中只读恢复副本会跳过不少正常初始化流程。

这种细节，在传统逆向里就是时间黑洞。AI 的价值不是凭空知道答案，而是能把碎片先排成可读线索。

这对普通用户影响不大。X61 不是现代主力机，也不是值得大规模采购的新品。真正该看这件事的，是 coreboot 开发者、固件安全研究者，以及还在和二进制 blob 打交道的人。

模型提速很猛，但错在硬骨头上

AI 擅长整理反汇编、反编译、寄存器访问和初始化顺序。它能把“像 C 写出来的 Intel MRC 风格 PE32 模块”，快速变成一堆能讨论的线索。

问题也在这里。线索不是结论。

上游审查已经发现不少问题，包括寄存器命名、保留位、访问宽度、时序表索引、MCHBAR 区域语义，以及硬编码 X61 逻辑。

问题类型具体风险
寄存器理解错把相邻芯片组的命名和语义搬过来
位宽错用 32 位访问 16 位寄存器，污染高位
时序错内存 timing 表索引、bitfield 含义出错
平台写死南桥初始化里写死 X61 设备逻辑
语义混淆DDR2 速率、CAS 编码、FSB 读取位置判断错

这些不是代码风格问题。它们会让机器不开机，或者更糟：只在某根内存条、某个 BIOS dump、某个板子状态下碰巧能跑。

所以作者需要大量 hand-holding。要知道 X60、X200 怎么启动，要懂 ThinkPad 的 EC、GPIO、SMBUS，还要把可疑值和厂商 BIOS dump 反复对照。

这才是现实版 AI 编程。它不是替代工程师，而是放大工程师。懂行的人被放大，不懂行的人也会更快把错误写进底层代码。

开源固件开发者可以调整工具链了。LLM 值得进逆向流程，但不能绕过硬件验证、代码审查和反复烧录测试。更现实的动作是：准备可恢复刷写手段、保留厂商 BIOS 对照、把 AI 输出当草稿，不当证据。

维护者也要改变节奏。以后类似 patch 可能更多，审查不能只看“能不能启动”。要看寄存器依据、平台泛化、保留位处理和失败路径。

真正变薄的是封闭固件的时间壁垒

我更在意的不是 X61 本身，而是成本曲线变了。

过去逆向一个固件平台，成本太高，收益太窄。尤其是 Intel FSP 这类二进制 blob，很多人不喜欢，但少有人愿意花几个月去拆。

现在，如果 LLM 能把固件逆向压到数周，激励结构就会松动。

“天下熙熙，皆为利来。”开源固件过去输的不只是文档，也输在时间。时间成本一降，闭源厂商靠“不透明”维持的舒适区就没那么厚了。

这里不能夸大。封闭固件不会因为一次 X61 移植就终结。法律边界也不能装看不见。原作者只谨慎提到：欧盟对特定逆向有允许空间，美国限制更强。这不等于任何地方、任何场景都能随便逆向。

历史上也有类似桥段。早年 PC 兼容机能起来，一部分靠 BIOS 兼容和工程复现。但那套故事和今天不完全一样：现在牵涉更多芯片组文档、微码、平台安全、固件签名和法律约束。相同的是，人们总会重新计算“封闭”到底值多少钱。

接下来真正该观察的，不是 X61 能不能成为日用机器。答案基本是否定的。它太老，性能和内存都不适合今天的主力使用。

更该看三件事：

  • 这批 X61 coreboot 代码能否通过上游审查，尤其是 raminit 和南桥初始化部分。
  • 类似方法能不能迁移到更多缺文档老平台，而不是只在 X61 上成立。
  • 维护者是否会形成新的审查标准，专门处理 LLM 辅助逆向带来的“看似合理”代码。

对开发者，这意味着可以更大胆地把 LLM 放进逆向工作流，但要把更多时间留给验证。对芯片厂商，这意味着“没人愿意拆”这层护城河变浅了。对普通用户，这件事暂时更像技术样本，不是换机建议。

模型让入口变宽，门槛没有消失。真正稀缺的，反而是能判断模型哪里错的人。

固件世界的旧规则还在：能跑只是第一关，能解释、能维护、能上游，才算过关。