Bring-Up-Anything

演示(v0.1.0版)

闭环工作，一镜到底，8 分 50 秒

特点：面向Agent

我一直在做嵌入式研发效能工具：编译环境（HarborPilot）、SDK 治理（SalvageOfSDK）。这一次，工具的服务对象从人换成了 AI——我把开发板的串口、SSH、交叉编译、烧写封装成一个 MCP 工具链，接给 AI。

Bring-Up-Anything 把嵌入式调试的物理通道——串口、SSH、交叉编译、烧写——封装成 8 个 MCP 工具挂到 Claude Code 上。配一份从我自己的 bring-up 方法论翻译来的调试 SOP(SOP只做通用化的规则提供）。因此，第一个版本的目标达成了：AI 拿到板子就能闭环干（一部分的）活：读状态、查日志、改 dts、编译、部署、验证，全程几乎不需要人为介入。

架构

+------------------------+        +-----------------------+        +------------------+
| Server Docker          |        | Host（连接设备串口的主机）|        | RK3588 目标板     |
|  Claude Code (Host)    |  MCP   |  ser2net :4000        | ttyUSB |                  |
|    ↕ stdio             |=======>|    ↑                  |=======>|  调试串口         |
|  MCP Server (MCPServer)|  ssh   |  ttyUSB0 ←────────────┼────────┤                  |
+------------------------+        +-----------------------+        +------------------+
         +-- 交叉编译（SDK 内核源码树，Docker 内）

关键架构决策：
【串口-“录音笔”】：串口采集进程独立于 MCP server 常驻。MCP server 是 Claude Code 按需拉起的，没人调用时进程根本不在，而 panic / boot 日志稍纵即逝——录音笔 7×24 连 ser2net 落盘，其他工具要读串口的时候只读录音笔（包括崩溃前的最后输出）。

目标（理念）

1. 确定性复杂度封装进Server：探测、重试、降级在代码里做完；需要决策的分叉（比如"ssh 别名选哪个"）以结构化返回值抛回给 Agent，不走静默默认。
2. 返回值清楚：状态 + 证据（原始输出）+ 下一步建议。Agent 拿到 ok=false 不用猜，hint 直接告诉它往哪走。
3. docstring 即说明书：写清"干什么、何时用、返回什么"——这是 Agent 选择工具的唯一依据。
4. BSP工具能够闭环交给Agent：BSP（板级支持包）的工具能够闭环交给Agent来做。
- 【Agent操作硬件有可能】其实硬件操作根本形不成“护城河”。如果有，那跟具身智能比比，都微不足道了，后者就是打通比特世界和原子世界的藩篱。还有，即便示波器也有SCPI，只要能够以数字化的形式接入计算机，那就都可能被Agent读取。即便暂时没有的，随着AI浪潮的席卷，也会不断打通这条路。
- 【重复流程多】：BSP的调试虽然复杂，但它有非常多规则明确的操作，例如发现问题->找TRM/原理图/dts/driver->找到疑似症结->改代码或硬件->继续解决问题。
- 【AI知识面广得多】：毋庸置疑，因此AI在找到疑似症结的部分将会比人有无与伦比的优势。

8 个工具

按 SOP 依赖链排序，stepN_ 序数前缀让 /mcp 面板的字母序即执行顺序：

工具	干什么
`step1_board_setup`	首次配置引导：实测 ssh 免密可达后才写配置
`step2_board_exec`	ssh 到板子执行命令——一切交互的基础通道
`step3_read_serial`	读串口最近 N 行（录音笔落盘回放，含崩溃前历史）
`step4_wait_serial`	阻塞等串口出现匹配文本（重启后抓 boot 日志的核心）
`step5_read_register`	板端 devmem 读物理寄存器（地址白名单防注入）
`step6_compile`	Docker 内交叉编译（bootimg / dtb / 模块）
`step7_deploy`	产物上板：ko insmod；boot.img 写分区，先备份、写后回读 md5 校验
`step8_power_control`	v0.1.0 人工指引版：把"人去按电源"也纳入三段式返回

验收

验收方式：给 AI 出考卷（故意弄坏驱动）

工具链"能调通"不等于"能干活"。v0.1.0 的验收是一场故障注入大考：

在 dts 里把 PCIe 控制器 num-lanes 从 4 改成 1：链路照样 up，lspci 一切正常，只有链路宽度从 x4 掉到 x1、带宽掉到 1/4；
开一个全新 AI 会话——没见过答案，只有 8 个工具 + 调试 SOP；
考生读链路宽度、查 dmesg、翻 dts，锁定 num-lanes，改回、编译、烧写、重启验证：一轮修复。

全程人工介入两次：按了一次电源键（v0.1.0 没有继电器），回答了一次"可以修吗"（写操作前的授权裁决）。

已知局限（v0.1.0 不结案）

电源动作靠人按；v0.2 评估 ESP32 继电器。
hang 死的板子救不回来——ssh 和串口双断时，工具链没有带外通道。
v0.1.0 = Rockchip kernel only

和 BSP 案例的关系

考场就是我自己调过的战场：RK3588 PCIe 调试——那次是我用人肉方法论打；这次同一类问题，AI 用翻译自同一套方法论的 SOP 打。方法论的复用对象，从"下次的我"变成了"任何一个 agent"。

迭代计划

下一个版本会增加对原理图/pcb的阅读支持读取串口的速度和功能会提升