第八周周报（8.31-9.6）

本周工作集中在 ONNX Runtime K3 Execution Provider 推理链路、K3 Runtime 调度器和 USB 串口支持。推理侧先跑通纯 CPU 版本，再通过 Rust ort 库接入带 K3 EP 的 ONNX Runtime，使 YOLOv5n 节点可以进入 K3 Runtime 和自研 K3 backend 执行；Runtime 侧补充零拷贝 tensor、常驻 worker 和条件等待；USB 侧完成 QEMU 真机设备转发验证和通用 CDC ACM 虚拟串口驱动。

本周工作概览

• 使用 Rust ort 库跑通 YOLOv5n 的 CPU 推理、输出解析和检测框绘制，并接入带 K3 EP 的 ONNX Runtime，验证 K3 backend 可以执行模型节点。
• 为用户态 Runtime 加入 ORT tensor 零拷贝视图，修复 graph worker 完成后 kernel alias 未释放的问题；调度器改为每核常驻 worker，通过等待队列睡眠和唤醒。
• 优化连续 tensor 的 transform 和 concat 路径，减少逐元素地址换算和中间数据搬运。
• 在 QEMU 中完成 Linux Host USB 设备转发验证，实现 CH340 与通用 CDC ACM 虚拟串口设备驱动，分别控制机械臂和底盘车轮。

ONNX Runtime K3 EP 与 YOLOv5n

本周先使用纯 CPU Execution Provider 跑通 ort_learn 测试程序，确认图片缩放、NCHW 输入构造、模型加载、输出 tensor 解析、置信度筛选和 class-aware NMS 流程正确。随后通过 OrtSessionOptionsAppendExecutionProvider_K3 将 K3 EP 注册到 Rust ort 创建的 Session 中，使支持的 ONNX 节点通过 K3 Runtime 提交到 K3 backend 执行，并通过已执行节点计数确认 K3 路径实际生效。

当前测试使用 YOLOv5n，输入图片缩放到 640×640，输出按 [1, 25200, 85] 解析，最终生成带检测框的图片：

这次测试打通了 Rust ort -> ONNX Runtime K3 EP -> K3 Runtime -> Scheduler -> K3 backend 的完整调用路径，为后续增加算子覆盖和对比 CPU/K3 性能提供了可复用程序。

Runtime 零拷贝与调度器

ORT 传入的连续 tensor 现在可以建立非拥有的借用视图，直接把原始用户态 buffer 写入 tensor descriptor。graph 提交时由内核固定用户页面并建立 kernel alias，worker 完成计算后释放本次 graph 的全部 alias，再发送 completion，使调用方可以安全复用或释放原 buffer。这一调整减少了输入输出 staging copy，同时修复了 worker 结束后 alias 页面未释放导致的内核内存泄漏。

调度器进一步拆出每核常驻 worker。每个实际 CPU core 拥有独立 scheduler、ready queue 和 worker；提交任务后通过 notify_one 唤醒对应 worker，无任务时 worker 使用 wait_until 进入等待。StarryOS 侧同步完成等待队列适配，把 Runtime 的等待与唤醒接口接到内核调度能力上。

K3 backend 的 transform 路径也增加了连续内存快速处理：连续 tensor 可以直接复制逻辑字节，concat 可以按 axis 两侧的连续 block 搬运，保留非连续 stride tensor 的通用路径。

USB 串口进展

在已有 xHCI Host 枚举和 EP0 控制传输基础上，本周为 QEMU 打开 USB 支持，并通过 usb-host 转发 Linux Host 上的真实 USB 设备，完成 CH340 设备识别和串口通信验证。

CH340 设备的 VID/PID 为 1a86:7523，数据接口为 vendor-specific 0xff/0x01/0x02。当前 usb-serial 已能从 descriptor 中匹配该设备和 Bulk IN/OUT endpoint，并实现 CH341 vendor control IN/OUT、芯片版本读取、SERIAL_INIT、波特率分频和新版本 LCR 配置。StarryOS 目前提供 /dev/ttyUSB0，应用打开节点时匹配设备、claim interface 并初始化串口。该设备对应机械臂控制。

同时完成通用 CDC ACM 串口驱动。驱动解析 communication interface、data interface 及 Bulk IN/OUT endpoint，在打开设备时分别 claim 控制接口和数据接口，通过 SET_LINE_CODING 设置串口参数，再进入统一的串口收发路径。StarryOS 提供 /dev/ttyACM0，该设备对应底盘车轮控制。机械臂和底盘已经可以分别得到控制，并在 QEMU USB 转发环境中完成验证。

目前还缺少通用 UVC 摄像头驱动。待支持设备为 1e45:8022 Suyin HD Camera，Linux 侧由 uvcvideo 驱动处理，设备包含两个 Video interface：Interface 0 和 Interface 1。

本周问题与判断

1. K3 EP 已能通过真实 YOLO 模型进入 backend，后续还需要继续扩大算子覆盖，并对 CPU/K3 的结果和性能做稳定对照。
2. 零拷贝 tensor 的生命周期必须覆盖 graph completion；alias 释放必须发生在 worker 停止访问 tensor 之后、completion 发出之前。
3. CH34x 和 CDC ACM 的识别、接口占用、串口初始化及基础收发已经打通，后续继续完善设备状态处理和机械臂、底盘控制协议。

后续工作

1. 完善 ORT K3 EP 的算子覆盖、错误诊断和 CPU/K3 对照测试。
2. 继续验证多核 worker、等待唤醒和异常完成路径，观察调度开销与内存释放行为。
3. 参照 SG2002 UVC 实现和 Linux uvcvideo 驱动，完成 1e45:8022 Suyin HD Camera 的通用 UVC 驱动，覆盖两个 Video interface、视频格式协商、控制请求和视频流接收。
4. 完善 CH34x 与 CDC ACM 的状态处理和多设备索引，继续测试机械臂和底盘控制命令。