一块全新的评估板就是一张白纸。这块板卡是一个能力很强的软件无线电平台， 但到手时只是裸硬件，附带几个底层的示例程序，没有操作系统。在这样一块板卡上把一个能用的 Linux 立起来，通常是一个人好几天、一步一步的活。
这一次，整个调试过程都由 AI 操盘。它连上板卡，逐个测试每一块硬件，把结果从芯片上读 回来，编译并安装 Linux，盯着启动日志，修好出问题的地方，然后重复。工程师负责定计划、 定顺序。一天之内，这块板卡从刚上电的硬件走到了登录提示符，ssh 也能通过网络连上。
这块板卡是什么
这是一块板卡，上面放了两颗大的 AMD 芯片。一颗是 Zynq UltraScale+ RFSoC（型号 XCZU67DR）：一个四核 Arm Cortex-A53 处理器、一片可编程逻辑，以及一个八路接收、八路发射、 采样率 2.8 GSPS 的射频前端。旁边是一颗 Kintex UltraScale FPGA（型号 XCKU115），用来补充 逻辑资源。两颗芯片之间由八条高速串行链路相连。Linux 跑在 RFSoC 里的那个 Arm 处理器上。
每一层验证过再往上搭
这次调试没有一上来就装 Linux，而是一格一格往上爬，每一格都留下日志和读数，才开始下 一格。先是调试链路，再是处理器内存，然后是网络，接着是启动设备、逻辑侧内存、两颗芯片之 间的高速链路，以及射频前端。只有当这些地基都验证过了，Linux 才搭上去。
处理器那四个吉字节的内存跑完了一整轮模式扫描，零错误。千兆以太网在吞吐测试里稳定跑到 948 Mbps。射频前端通过板上的一个接口把一个单音直接环回，落点与发出去的频率相差不超过一 个频率单元。
这样做的道理很简单。如果上面一格出了问题，而它底下的地基从没验证过，就没法判断到底是 新加的东西坏了，还是底子本来就没通。一格一格来，能把故障锁在它发生的那一格里。
Linux 镜像是怎么编出来的
地基都验证过之后，Linux 镜像本身就顺理成章了。起点是板卡自带的那份硬件描述文件，它的 工具版本正好和手上的工具对得上，直接拿来用。从这里编出整套系统（6,377 个构建任务，内核 6.6.40），再打包成一个启动镜像、一个内核镜像和一个根文件系统，写进 SD 卡：一个分区用来 启动，一个分区放根文件系统。把板卡设成从卡启动，上电，引导程序就把内核拉起来。
结果：一个登录提示符和 ssh
板卡把内核一路引导到登录提示符。登录进去，把网络接口拉起来，配上一个固定地址，它就能 应答另一台机器发来的 ssh。到这一步，板卡不再是裸硬件，而成了一台工程师可以登录、可以操 控的网络仪器。
读机器的实际状态，不靠猜
调试过程并非没有坑。能把它控制在一天之内，靠的是每一个坑都用读机器实际状态的方式去定 位，而不是靠猜。
一个启动模式开关含义不清，于是直接读芯片里的启动模式寄存器，确认板卡实际进入了哪个模 式。第一次启动挂上了一个放在内存里的临时根文件系统，把真正的那个盖住了，于是把它追出来， 改从 SD 卡的根分区挂载。内核设置里的一个网络接口名字和硬件对不上，于是把它改成板卡实际用 的名字，网络就通了。每一个修复都来自一次读数，而不是一个假设。
这件事的意义
同一套纪律贯穿我们做的每一件事：在往上搭下一层之前，先用一个真实的测量把这一层验证 过，并且相信机器的实际状态，而不是文档上说它应该是什么样。我们就是这样调试板卡的，这也 是我们的设计服务和经过验证的 IP 核背后同样的严谨。最后交付的是一个你能测量、能登录进去的 可用系统，每一层都验证过。