无线烧录器：Linux 本地烧录网关方案
1. 核心定义
本方案将无线烧录器做成一台专用的嵌入式 Linux 设备，而不是远程 USB Hub：
浏览器 / 手机 / 产线系统
│ HTTPS + WebSocket（Wi-Fi 或以太网）
▼
自研 Linux 烧录器
├─ Web UI / API / 用户与任务管理
├─ 固件仓库、签名与日志
├─ Rockchip / Allwinner / NXP / MCU 烧录适配器
├─ USB Host、UART、SWD/JTAG、RESET/BOOT/PWR 控制
└─ 本地执行实际烧录与校验
│
▼
被烧录的 MCU / SoC / 开发板
用户浏览器只上传固件、选择芯片配置并查看日志；烧录器下载/缓存文件后，在自己的 Linux 系统中调用封装好的烧录逻辑。其本质与一台连接了专用接口的 Linux 工控机相同，但可做成体积更小、接口固定、便于自动化和批量部署的设备。
这个架构可以覆盖多类型 MCU 与 SoC，且不需要 PC 安装 Rockchip、NXP、Allwinner 等工具。USB over IP 不是主链路，不做也不影响烧录能力。
2. 为什么这比“无线 USB Hub”更适合烧录
| 对比项 | Linux 本地烧录网关 | 无线 USB 透传 |
|---|---|---|
| 实际烧录工具运行位置 | 设备内，版本可控 | 用户电脑，因系统而异 |
| 网络中断 | 上传完成后烧录可继续 | 可能中断 USB 会话 |
| 手机支持 | 浏览器/App 可直接操作 | 无法通用映射远端 USB |
| 多厂商适配 | 在设备端增加一个适配器即可 | 还要兼容各桌面 OS 驱动 |
| 安全与审计 | 固件、权限、日志集中管理 | 文件与工具散落在客户端 |
| 量产可重复性 | 高 | 受客户电脑和驱动影响大 |
前提是：目标芯片有可用的本地烧录协议和可在 ARM Linux 上运行的工具，或可自行实现对应协议。RK Maskrom/Loader、Allwinner FEL、NXP i.MX SDP/UUU、串口 BootROM、DFU 与 SWD/JTAG 均符合该模式。
3. 产品边界
3.1 首版应提供的能力
- Wi-Fi STA 模式连接现场路由器；AP 模式用于初次配网和无路由器现场。可保留千兆以太网作为产线和救援通道。
- 局域网 mDNS 发现（例如
flasher-xxxx.local）和浏览器 Web UI；支持扫码打开设备地址。 - 上传固件、选择目标 profile、开始/取消任务、实时日志、历史记录、导出结果。
- 通过 USB Host 运行 SoC 的 USB BootROM 烧录；通过 UART 运行 ROM ISP；通过独立调试探针运行 SWD/JTAG。
- 自动切换 RESET、BOOT/STRAP、目标电源和 USB VBUS，并执行写入后的读回/CRC/哈希验证。
- REST/gRPC API 供产线脚本、MES 或 CI 调用。
3.2 明确不属于首版
- 将任意远端 USB 设备无客户端地显示为 Windows/macOS/iOS 的物理 USB 设备。
- 自行仿真或绕开 SEGGER J-Link 授权；需 J-Link 时接入真实 J-Link 或采购合规 OEM 方案。
- 无芯片型号、无协议资料情况下声称支持某一个厂商的所有产品。
- 直接把用户上传的 shell 脚本以 root 身份执行。
4. 芯片与板级硬件选型
4.1 主控推荐
原型和通用量产首选：RK3566/RK3568 SOM + 自研载板。
原因是其 Linux BSP、USB、PCIe/SDIO、eMMC 和网络资源适合运行多种命令行烧录工具、Web 服务及多个并发工位。第一版使用成熟 SOM 降低 DDR、PMIC 与高速信号风险；验证目标芯片覆盖率后再决定是否自研核心板。
备选：NXP i.MX 8M Mini/Plus SOM。
若更重视长期供货、工业温度和文档支持，可选该路线，但成本与开发周期通常更高。
不建议作为本产品唯一主控：ESP32-S3。
它适合低成本 UART/SWD 无线烧录器；但不适合承载通用 Linux 工具、多路 USB Host、固件仓库、网页服务以及 RK/Allwinner/i.MX 的统一烧录框架。
主控最低建议：4 核 ARM、1 GB RAM、8 GB eMMC、至少两个可用 USB 2.0 High-Speed Host 通道或一个 Host 加 HS Hub、千兆以太网、5 GHz Wi-Fi 接口。最终选型必须以具体 SoC 的引脚复用和 USB 端口拓扑为准。
4.2 推荐载板组成
| 模块 | 推荐配置 | 设计目的 |
|---|---|---|
| 核心板 | RK3566/RK3568 SOM，1 GB RAM、16 GB eMMC | 运行 Linux、工具链和镜像缓存 |
| Wi-Fi | 已认证 5 GHz Wi-Fi 5/6 模组，PCIe 或 SDIO 接口，外置天线座 | 上传大镜像与稳定的现场连接；避免首版自研射频 |
| 有线网 | 1 GbE RJ45，可选 PoE PD | 产线稳定连接、Wi-Fi 故障恢复、远程维护 |
| USB 下载口 | 2–4 个 USB 2.0 HS Host；多口使用 USB2514B 等同级 HS Hub | 连接处于 RK Maskrom、FEL、SDP、DFU 等模式的目标 |
| USB-C 口 | Type-C 仅作为 Host/供电源时，配 CC/Rp 配置与可控 VBUS | 正确识别 C-C 线和保护目标供电 |
| 串口下载口 | 2–4 路 UART，3.3 V 默认，可选 1.8/2.5/5 V 电平转换 | BootROM 下载及独立日志通道 |
| SWD/JTAG | 独立实时调试 MCU + 10-pin/20-pin 接口及转接线 | 稳定产生调试时序，覆盖 ARM MCU |
| 目标控制 | 每工位独立 RESET、BOOT/STRAP、PWR_EN、VBUS_EN、检测 GPIO | 自动进下载模式、异常恢复、保护主控 |
| 保护 | USB ESD、TVS、每口限流高边开关、反接/过流保护 | 防止样机短路、反灌电和插拔损坏 |
| 安全 | 安全元件/TPM（可选） | 存放设备证书、密钥、烧录授权 |
4.3 为何 SWD/JTAG 要增加一个实时 MCU
Linux SoC 的 GPIO 可控制 RESET/BOOT，但不应直接承担高频、时序严格的 SWD/JTAG 波形。建议使用 STM32H7 或 LPC55Sxx 级 MCU，实现 CMSIS-DAP v2 或与主控约定私有的调试控制协议；Linux 主控负责调度和日志，调试 MCU 专注于实时接口。
如果首版只要求 USB BootROM/UART，则可以先不放调试 MCU；但“多 MCU 通用”基本都会需要 SWD/JTAG，建议在 PCB 上预留该模块和接口。
4.4 端口设计原则
- 每个烧录工位必须有唯一、稳定的物理路径。Linux 通过 udev 按 USB 路径建立固定名称，不能依赖随机的
/dev/ttyUSB0。 - 每个工位最好可以独立控制目标电源和复位；USB Host 的 VBUS 也需可单独开关，便于强制重新枚举。
- BOOT/STRAP 必须按目标板要求做开漏或隔离，不能直接把 3.3 V GPIO 连到未知电平域。
- USB BootROM、UART BootROM、SWD/JTAG 和调试日志应有明确的物理连接规范；将接线图编码为 profile 的一部分。
5. 软件架构与技术栈
5.1 系统软件
| 层 | 推荐选型 | 职责 |
|---|---|---|
| 嵌入式系统 | 原型：Buildroot；量产：Yocto + Linux LTS | 最小系统、BSP、升级、开源许可证管理 |
| 设备服务 | Go 或 Rust 编写 flasherd | API、任务状态机、并发/端口锁、审计与工具调度 |
| Web UI | Vue/React 编译成静态资源，由 flasherd 或 Nginx 提供 | 无需安装客户端的操作页面 |
| 通信 | HTTPS REST 或 gRPC；WebSocket 推送日志；mDNS 发现 | 浏览器、移动端和产线系统接入 |
| 数据 | SQLite + eMMC 文件仓库 | 任务、设备配置、日志和固件元数据 |
| 外设访问 | libusb、libgpiod、termios、udev | USB、GPIO、串口和稳定设备命名 |
| 运行监控 | systemd、watchdog、journald/结构化日志 | 开机自启、异常复位、诊断 |
浏览器不直接连接 USB/串口。所有硬件访问都在 flasherd 和其受控的烧录适配器内进行，因此 Chrome、Windows、Linux、Android、iOS 的差异不会影响实际烧录。
5.2 烧录适配器层
每种芯片家族提供一个 adapter。adapter 接受经过验证的 profile 和固件，执行固定、可审计的步骤，返回统一结果，而不是把不同厂商工具的原始命令暴露给网页。
| Adapter | 典型工具/协议 | 连接方式 |
|---|---|---|
uart-boot | esptool、STM32 UART bootloader、厂商 ISP | UART + RESET/BOOT |
swd-jtag | OpenOCD、pyOCD、CMSIS-DAP | 调试 MCU + SWD/JTAG |
dfu | dfu-util、厂商 DFU CLI | USB Host |
rockchip | rkdeveloptool/合规厂商 Linux 工具 | USB Host + Maskrom/Loader 控制 |
allwinner | sunxi-fel/sunxi-tools | USB Host + FEL 控制 |
nxp-imx | UUU（按许可和 ARM Linux 支持验证） | USB Host + SDP/fastboot |
每个 adapter 统一支持：连接探测、进入下载模式、擦除、写入、验证、复位启动、超时、失败恢复、版本上报与结构化日志。
5.3 Profile（烧录配置）
多芯片产品的关键不是把工具堆在设备上，而是维护 profile。profile 至少要包含：
id: rk3568-maskrom-emmc-v1
vendor: rockchip
chip: rk3568
adapter: rockchip
port: usb-slot-1
boot_sequence: [power_off, boot_strap_on, power_on, reset_pulse]
images:
- name: loader
artifact: MiniLoaderAll.bin
- name: system
artifact: update.img
verify: tool_readback_or_crc
timeout_seconds: 300
profile 应受版本控制与签名保护。生产环境只允许选择已发布 profile；管理员可以新增 profile，但不能通过普通用户输入任意可执行命令。
5.4 任务状态机
已上传 → 校验通过 → 等待端口 → 切换下载模式 → 探测目标 → 擦除 → 写入 → 校验 → 启动 → 成功/失败。
状态与原始日志实时写入 SQLite/文件系统。浏览器断开、Wi-Fi 重连或页面刷新不会丢失任务；失败时保留适配器版本、profile、目标端口、电源状态和错误码，方便定位产线问题。
6. 网络与 Web 服务方案
6.1 联网方式
- STA 模式：设备加入用户 Wi-Fi，通过 DHCP 获取地址；mDNS 发布设备名称。
- AP 模式：首次配置或脱网现场由烧录器创建热点；用户连接后设置 Wi-Fi 凭据。
- 以太网模式：工厂场景的优先选项，网络稳定、便于固定 IP/PoE 和集中管理。
支持 STA + AP 回退：若指定时间内无法连接已配置网络，开放配置热点，但不应在生产环境无认证地开放烧录权限。
6.2 Web/API
POST /api/v1/artifacts：分块/断点续传固件，并计算 SHA-256。GET /api/v1/profiles：读取被授权的目标配置。POST /api/v1/jobs：创建指定端口的烧录任务。GET /api/v1/jobs/{id}与 WebSocket：读取状态和实时日志。POST /api/v1/devices/wifi：仅管理员可修改 Wi-Fi 配置。
镜像较大时使用分块上传和本地缓存；上传完成后再开始烧录。不要在浏览器上传流未结束时直接将数据转给目标板。
7. 首批兼容矩阵与验证方法
立项时应冻结实际样板，而非只列“RK、全志、NXP”。建议最少覆盖：
| 类别 | 最小验证对象 | 验证内容 |
|---|---|---|
| UART MCU | STM32 或 ESP32 开发板 | 自动 BOOT/RESET、下载、校验、串口日志 |
| SWD MCU | Nordic/STM32/RP2040 任一板 | CMSIS-DAP、擦写、读回、复位 |
| Rockchip | 一个指定 RK 型号开发板 | Maskrom/Loader 枚举、Loader、eMMC/NAND 写入与恢复 |
| Allwinner | 一个指定全志开发板 | FEL 枚举、镜像写入和断电恢复 |
| NXP i.MX | 一个指定 i.MX 开发板 | SDP/UUU、存储烧录、fastboot/启动验证 |
每个样板应连续执行至少数百次烧录并记录成功率、平均时间、异常恢复时间和失效原因。不同 PCB 的 Boot 拉脚、电源时序、USB Type-C 角色和安全启动设置不同，必须分别形成 profile。
8. 安全、可靠性与量产要求
- 采用 HTTPS、管理员/操作员角色、设备唯一证书；生产网络不允许匿名任务提交。
- 固件记录 SHA-256，可选签名验证；安全启动或熔丝操作只能由专用、授权 profile 执行。
- 每工位互斥锁、超时、USB 重新枚举、目标掉电恢复和工具进程看门狗是必需功能。
- 电源设计要防止目标板反向向 USB 口供电；单端口过流后不能影响其他工位。
- 使用 A/B OTA 或可恢复的系统升级机制；保留可通过以太网/串口救援的路径。
- 记录固件哈希、profile 版本、操作者、起止时间、目标识别信息和最终结果，满足追溯需求。
9. 实施顺序
- 硬件 PoC：RK3566/RK3568 SOM、认证 Wi-Fi 模组、一个 USB Host、一个 UART、一个目标控制口；先打通 Web 上传 + STM32/ESP 烧录。
- SoC 适配 PoC：针对已经选定的 RK、Allwinner、NXP 三块目标板，在设备端运行各自工具并固化 profile。
- MVP 载板：增加 USB HS Hub、2–4 工位控制、调试 MCU、千兆网、电源保护和 eMMC 存储。
- 产品化：账号/签名/审计、OTA、产线 API、自动化回归工装和射频/EMC/温升测试。
10. 当前需要决策的项目输入
要冻结原理图和软件 backlog，需要项目方给出：
- 首批必须支持的精确芯片型号与对应开发板，尤其是 RK、全志、NXP 的具体型号。
- 每类目标的固件格式、存储介质、是否已开启安全启动、所需下载接口与 Boot/RESET 时序。
- 需要的并发工位数、单镜像最大大小、期望烧录时间和目标成本。
- 是否允许目标供电由烧录器提供、各板卡的电压/最大电流及连接器要求。
- 是否需要内网远程管理、云端设备管理、MES/CI、固件签名和完整审计。
在这些输入明确之前，RK3566/RK3568 SOM + Linux 本地适配器是风险最低的启动选择；USB 透传可以保留为后续可选功能，而不进入第一版架构关键路径。