SG板移植开发交流

[chyyuu]

预期目标：

1. StarryOS可在SG板上启动；
2. StarryOS可支持SG板上的基本Linux应用；
3. StarryOS适配sg2002的TPU驱动；
4. StarryOS适配sg2002的其它驱动（支持存储、支持摄像头、支持I2C、wifi等），从而支持更多的Linux应用；
5. StarryOS支持YOLOv8，支持驱动299的小车底盘（大概率是用I2C接口）。

开发启动时间：2026.01.13

参考信息：

• 开发板Sipeed LicheeRV Nano SG2002(WiFi)开发板
  • LicheeRV-Nano文档
  • LicheeRV-Nano例程
  • LicheeRV-Nano硬件
  • 交流平台
  • 算能官方资料
• 基于 sg2002的milkv板：详细描述了 怎么使用 sg2002 的 tpu

[yfblock]

目前搜集到的一些信息：https://shimo.im/docs/m4kMM20wzKC9DBkD/ 《CV系列处理器 TPU SDK 开发资料》，可复制链接后用石墨文档 App 打开

还有之前我在 os 比赛时开发的 cv1811h sd 卡驱动，当时时间比较紧，需要改改修复一下应该就能用：https://github.com/Byte-OS/cv1811-sd/tree/main

目前开发板买了一块 licheerv nano wifi 款的，

[yfblock]

2026-01-13 讨论：

1. 目前大家都先搜集一些相关的资料，看看对什么比较感兴趣
2. 板子到手后可以共同做 任务1，2，每个人都对 StarryOS 和 sg2002 都有一些了解
3. 可能有的问题是目前 Starry 中用的是 musl libc，但是 sg2002 linux 中应该用的是 glibc，可能需要换掉 libc
4. 需要明确要跑哪些 linux 应用，也许可以在 Starry 上利用 yolo 在 cpu 上跑已有的图像或视频识别
5. 摄像头可能是难点，可以用一些简单的摄像头先捕捉到画面（使用 spi 协议，比如 ov7670: https://web.mit.edu/6.111/www/f2016/tools/OV7670_2006.pdf ） ，或者使用其他的比较简单的方法，目前找到的推荐用的是基于 MIPI 协议的 GC4653
6. tpu 是比较难的部分，大家先搜集资料，到时候共同学习一下

[elliott10]

算能微信群交流记录：

https://github.com/sophgo/cviruntime/blob/master/doc/cvitek_tpu_sdk_development_manual.md
https://github.com/sophgo/cvikernel
仓库是开源的 文档我没有找到

如果要在其它系统上编译这里有个alios的cvi仓库
https://github.com/sophgo/cvi_alios_open
应该可以借鉴一下

kernel和runtime的开发文档
https://github.com/sophgo/cviruntime/blob/master/doc/cvitek_tpu_sdk_development_manual.md

[yfblock]

• 搜素了一些信息发现 qemu riscv64 有 thead-c906 的支持，可以在遇到问题的时候进行调试
  尝试编写了一个程序发现 riscv64 能运行在上面，只是需要避免使用 c.lbu 指令
• xuantie 的 github 仓库中也有修改的 qemu, https://github.com/XUANTIE-RV/qemu ，这里支持的完善一些
• 尝试为 arceos 添加了新平台（完成）。也尝试了为 Starry 添加新平台（还未跑通）
• 尝试利用一些 AI 工具搜索信息（NotebookLM，Cursor，gemini）
  搜索 gc4653 摄像头的信息，已经都放在了石墨文档中：https://shimo.im/docs/m4kMM20wzKC9DBkD/

[elliott10]

据悉李老师组，目前也在使用厂商配套的的GC4653摄像头。

GC4653摄像头驱动源码，在AliOS和FreeRTOS中找到有完整驱动实现:

• https://github.com/sophgo/freertos/tree/sg200x-dev/cvitek/driver/sensor/src/gcore_gc4653/
• https://github.com/sophgo/cvi_alios_open/tree/master/components/cvi_sensor/gcore_gc4653/

[yfblock]

sg2002 的 pin 会被复用，Uart 或 IIC 可能会在同一个 Pin 上，且同一时刻只能用一个功能，所以需要设置复用来选择用哪一个功能。目前的资料：

sipeed 中的资料：https://wiki.sipeed.com/hardware/zh/lichee/RV_Nano/5_peripheral.html
PINOUT 表（看表中的 1.管脚信息表（QFN））： https://github.com/sophgo/sophgo-hardware/blob/master/SG200X/04_SG2002/04_SG2002_PINOUT.xlsx

今天摄像头到了，开发板还没到（分开运输的）。

[elliott10]

使用Cursor GPT 5.2 Codex对之前比赛的rk3588 npu驱动进行分析：

---

Rk3588 npu 驱动 c 到 rust 迁移仓库分析

---

User

请帮我分析一下这个项目：将rk3588硬件板子的linux npu驱动：kernel/drivers/rknpu 将这个C语言的NPU驱动，改写成了Rust语言的无系统依赖的驱动npu-driver-qcl/drivers， 其中的rknpu文件夹中是NPU驱动npu-driver-qcl/drivers/rknpu

---

Cursor

下面是对你描述的两个项目（C 版 Linux 内核驱动与 Rust 版无系统依赖驱动）的结构与对应关系分析，基于你给的路径与实际代码内容整理。

总体定位与目标

• Rust 版 rknpu 明确定位为“最小化设备层”，通过 OSAL 抽象系统依赖，仅保留硬件操作逻辑与 IOCTL 语义映射；这与 Linux 内核驱动的“完整设备驱动”方向不同。
  参考 README.md：功能范围、模块结构与“最小化设备层”的定位说明。

15:38:rknpu/README.md
# RKNPU Minimal Device Layer
...
## 模块结构
src/
├── lib.rs          # 主入口，对外API
├── osal.rs         # 操作系统抽象层
├── hal.rs          # 硬件抽象层
├── memory.rs       # 内存管理器
├── device.rs       # 设备接口层
├── config/         # 配置管理
├── registers/      # 寄存器定义
└── err.rs          # 错误类型定义

Rust 端核心结构与职责

• 整体入口与动作分发：lib.rs 定义 Rknpu 主结构，提供 action() 等接口，保持与 C 版 rknpu_action 语义相近（但多数动作还未真正实现）。

10:112:rknpu/src/lib.rs
#![no_std]
...
pub struct Rknpu {
    base: Vec<RknpuCore>,
    ...
    iommu_enabled: bool,
    pub(crate) gem: GemPool,
}
...
pub fn action(&mut self, action: RknpuAction) -> Result<u32, RknpuError> {
    match action {
        RknpuAction::GetHwVersion => { ... }
        ...
        RknpuAction::SetBwPriority => { ... Err(RknpuError::InternalError) }
        ...
    }
}

• 寄存器定义与 MMIO 操作：Rust 用 tock-registers 封装寄存器访问，避免硬编码偏移。

1:179:rknpu/src/registers/mod.rs
//! Memory-mapped register definitions for the Rockchip NPU.
...
pub struct RknpuCore {
    base: NonNull<u8>,
}
...
pub fn submit_pc(&mut self, config: &RknpuData, args: &SubmitRef) -> Result<(), RknpuError> {
    ...
    self.pc().operation_enable.set(1);
    mb();
    self.pc().operation_enable.set(0);
    ...
}

• 设备配置参数移植：Rust 的 RknpuData::new_3588() 直接体现了 C 驱动里 rk3588_rknpu_config 的关键字段，如 dma_mask=40、pc_data_amount_scale=2 等。

55:74:rknpu/src/data/mod.rs
fn new_3588() -> Self {
    Self {
        bw_priority_addr: 0x0,
        bw_priority_length: 0x0,
        dma_mask: dma_bit_mask(40),
        pc_data_amount_scale: 2,
        pc_task_number_bits: 12,
        pc_task_number_mask: 0xfff,
        pc_task_status_offset: 0x3c,
        pc_dma_ctrl: 0,
        irqs: RK3588_IRQS,
        nbuf_phyaddr: 0,
        nbuf_size: 0,
        max_submit_number: (1u64 << 12) - 1u64,
        core_mask: 0x7,
        ...
    }
}

• 内存/GEM 机制简化：Rust 版用 dma_api::DVec 直接做 DMA buffer 池，替代 Linux DRM GEM / DMA heap 体系。

1:53:rknpu/src/gem.rs
pub struct GemPool {
    pool: BTreeMap<u32, DVec<u8>>,
    handle_counter: u32,
}
...
pub fn create(&mut self, args: &mut RknpuMemCreate) -> Result<(), RknpuError> {
    let data = DVec::zeros(...);
    ...
    args.dma_addr = data.bus_addr();
    args.obj_addr = data.as_ptr() as _;
    self.pool.insert(args.handle, data);
    Ok(())
}

• IOCTL 语义结构映射：Rust ioctrl.rs 与 C 的 rknpu_ioctl.h 是一一对应的数据布局（#[repr(C)]），如 RknpuMemCreate、RknpuSubmit 等。

35:114:rknpu/src/ioctrl.rs
#[repr(C)]
pub struct RknpuSubmit {
    pub flags: u32,
    pub timeout: u32,
    pub task_start: u32,
    pub task_number: u32,
    ...
    pub subcore_task: [RknpuSubcoreTask; 5],
}

51:136:rknpu/include/rknpu_ioctl.h
enum e_rknpu_job_mode { ... };
enum e_rknpu_action { ... };
struct rknpu_mem_create { ... };

• OSAL 现状：README 描述了 OSAL trait，但实际代码里 osal.rs 目前只有类型与错误定义，未看到 trait 定义或实现逻辑（可能还未完成）。

1:23:rknpu/src/osal.rs
//! Operating System Abstraction Layer (OSAL) ...
pub type PhysAddr = u64;
pub type DmaAddr = u64;
pub type TimeStamp = u64;
pub enum OsalError { ... }

C 版 Linux 驱动的主要职责（对照用）

• C 版驱动完整依赖 Linux 内核子系统：IRQ、devfreq、PM、IOMMU、DRM GEM、DMA heap、waitqueue 等。
• rknpu_drv.h 中的 rknpu_device 结构体现了复杂的 Linux 管理逻辑与平台依赖。

114:180:rknpu/include/rknpu_drv.h
struct rknpu_device {
    void __iomem *base[RKNPU_MAX_CORES];
    struct device *dev;
    ...
    struct devfreq *devfreq;
    unsigned long current_freq;
    unsigned long current_volt;
    ...
    struct iommu_domain *iommu_domains[RKNPU_MAX_IOMMU_DOMAIN_NUM];
    ...
};

核心差异与可见的“简化点”

• 设备管理：C 版依赖 Linux 设备模型；Rust 版没有设备生命周期、驱动注册与 sysfs 相关逻辑。
• 内存管理：C 版走 GEM/heap；Rust 版是 GemPool + DVec 的轻量化替代。
• IOMMU/电源/时钟：C 版有完整 IOMMU、PM、clock、devfreq；Rust 版仅保留状态字段与 TODO/日志提示。
• 中断处理：C 版使用 IRQ 子系统注册 handler；Rust 版仅保留 handle_interrupt() 和 new_irq_handler() 的入口，外部需自行集成。
• OSAL：README 宣称 OSAL 抽象接口，但实际代码里只有类型定义（可能后续才补齐）。

大致模块映射关系（Rust -> C）

• src/lib.rs ↔ rknpu_drv.c（设备主入口/动作分发）
• src/data/mod.rs ↔ rknpu_drv.c 中的 rknpu_config
• src/registers/* ↔ rknpu_ioctl.h 的寄存器偏移 + C 侧硬编码操作
• src/ioctrl.rs ↔ rknpu_ioctl.h
• src/gem.rs ↔ rknpu_gem.c / rknpu_mem.c
• src/job.rs / src/task/* ↔ rknpu_job.c（任务提交与调度）

---

[pengzechen]

sg2002 的应该是tpu。
sg2002 的tpu应该重点就两部分 tdma 和 tiu，比3588的简单。

[Ticonderoga2017]

1. 板子刚到，上电之后电脑没识别到任何信息，经请教发现缺少usb转换模块，连夜购买转接线
2. 借助AI分析移植到SG2002板卡可供参考的平台包：
   • [Ticonderoga2017/axplat-riscv64-visionfive2 (github.com)](https://github.com/Ticonderoga2017/axplat-riscv64-visionfive2)
   • [axplat_crates/platforms/axplat-riscv64-qemu-virt at main · Ticonderoga2017/axplat_crates (github.com)](https://github.com/Ticonderoga2017/axplat_crates/tree/main/platforms/axplat-riscv64-qemu-virt)
3. 开始尝试编译Starry OS

[elliott10]

C906虚拟内存

sg2002开发板使用了平头哥的C906的CPU。

根据Linux源码中的riscv架构相关代码部分，在构建虚拟内存页表项时，需要分别为内核镜像内存地址空间和设备地址空间进行额外的页表flags属性。具体如下：

• 为内核镜像内存地址空间PAGE_KERNEL添加相比普通页表的额外的flags属性位：bit[62] CACHE,bit[61] BUF，bit[60] SHARE；

• 为设备地址空间PAGE_IOREMAP添加额外的属性：bit[63] SO，bit[60] SHARE;

这些页表项的额外的flags属性位，可以通过查询C906芯片手册获知其定义信息，如下图，C906额外页面属性位于63:59位，包括了SO, CACHE, BUF, SHARE, SEC

根据其他CPU芯片手册，可知道这些平头哥CPU的拓展属性，不单在C906中存在，在C910 CPU中也同样存在。

平头哥CPU自定义的页表的额外的flags属性位，通过查找芯片手册，可以在拓展状态寄存器MXSTATUS中找到了相应的设置位MAEE。C906 CPU的MAEE拓展位可以设置是否打开拓展的MMU地址属性，即是否使能拓展MMU中PTE的地址属性SO, CACHE, BUF, SHARE, SEC

默认在打开maee的状态时，可以在页表项PTE中设置对应位，这里需要注意内核镜像和设备地址空间所设置的PTE额外属性值不同。

更多的请见： 平头哥C910的页表项拓展属性位

[yfblock]

搜索了一下之前参加比赛的时候对 C906 的支持，想起来 C906 在读写内存之后需要进行 dcache 的刷新，否则会产生异常。可能在 Starry 的移植过程中遇到这个问题，https://gitlab.eduxiji.net/202310464101015/oskernel2023-byteos/-/blob/on-site-qemu/arch/src/riscv64/addr.rs#L195

[pengzechen]

我梳理了一下linux tpu驱动，主要重写下 cvi_tpu_interface.c 和 tpu_platform.c 就行。

[elliott10]

在sg2002物理板子上，调通Cursor生成的BSP代码，发现还是有不少错误需要根据实际运行情况作修改。如地址，中断设置等
sg2002 BSP仓库放在：https://github.com/elliott10/axplat-riscv64-sg2002.git
在StarryOS上编译参数：

make ARCH=riscv64 APP_FEATURES=sg2002 MYPLAT=axplat-riscv64-sg2002 LOG=debug BUS=mmio UIMAGE=y build

[yfblock]

尝试做了 sg2002 上的辅助核心支持，SG2002 一共有四个核心 (1GHz C906 和 1GHz A53 二选一) + 700MHz C906 辅助核心 + 8051。尝试启动了 700MHz 的辅助核心，但是和大核之间无硬件缓存一致性的支持，所以直接作为 AP 核心比较麻烦，也许可以在大小核上分别启动一个 Linux 和一个 ArceOS。

[Ticonderoga2017]

尝试实现WiFi驱动模块，但目前还存在诸多问题，如：CMD53扩展IO指令超时，SDIO错误等，正在调试
https://github.com/Ticonderoga2017/sg2002-wifi-driver.git

[Ticonderoga2017]

目前WiFi驱动初始化已完成，开始调试信号扫描和接收处理

[Ticonderoga2017]

AIC8801芯片WiFi驱动开发日志：

1. 包含以下模块：
   1. 主驱动接口，配置管理，GPIO控制，网络设备接口
   2. SDIO协议栈
   3. AIC8800芯片驱动
   4. IEEE 802.11协议栈
2. 当前已完成的功能：
   1. 驱动初始化，包括：
      1. GPIO初始化
      2. SDIO设备初始化
      3. AIC8801芯片初始化
      4. 固件加载
   2. 扫描局域网
      1. 驱动发送扫描请求
      2. 固件响应请求
      3. 固件返回响应结果并交给驱动处理
3. TODO：
   1. 将驱动的几个模块分成独立的crate
   2. 解决目前固件加载问题
   3. 调试网络连接和数据传输
   4. 优化响应延迟
   5. 人机交互
      项目地址：https://github.com/Ticonderoga2017/sg2002-wifi-driver.git

[Ticonderoga2017]

关于固件加载问题：

1. 第一种方案是直接从LicheeRV-Nano-Build里面提取固件，但是在加载过程中发现缺少fmacfw_patch.bin，原因可能是LicheeRV-Nano-Build默认从文件系统加载固件，而不是使用内嵌数组，因为有些芯片版本可能不需要这个补丁？
2. clone了固件仓库（https://github.com/lxowalle/aic8800-sdio-firmware.git）来获取固件和补丁
   基于以上工作，完善了系统配置，固件和补丁版本验证，完整性验证和固件启动逻辑，从日志输出中可以看到系统配置正确，固件匹配且完整，固件启动，但启动后没有收到确认消息，进一步的调试和验证正在进行中

[pengzechen]

将捡网球的模型加载到starry上，可以正常运行。检测图片和linux输出一致

[pengzechen]

https://github.com/milkv-duo/duo-buildroot-sdk-v2/tree/main/cvi_mpi/sample/sensor_test 调用摄像头的例子在这里。摄像头驱动完成后跑通这个例子应该就算成功了。

[elliott10]

为了试验自用模型小球识别模型能在sg2002上能使用，研究模型转换的的过程，，包括 前处理-模型推理-后处理 三个环节。
与算能技术支持关于模型转换与部署的交流记录：

1. 模型转换时注意添加--fuse_prefpocess;
2. 包括 --keep_aspect_ratio --pixel_format --mean --scale 这些参数一般情况不会有问题，不过需要再确认一下是否与[.onnx模型训练时]保持了一致; 保证前处理（cut）的正确;
3. 试验一个在对.onnx模型转换之前能正常识别的应用（可以选python程序）

[elliott10]

合并当前在sg2002平台上的bsp和驱动代码：
首先基于各自写的抽象好的独立的驱动crate，将调用的结构和函数接口部分暴露出来，若有需要OS层提供的功能，如alloc内存分配，做成trait接口。这样能便捷地把驱动和OS耦合起来

对sg2002平台支持的代码，通过feature条件控制，页表项有拓展flag，拥有专有的刷cache指令，以及cvsd存储等，（tpu相关的部分还有待进一步沟通整理独立出来，）使得一个平台的改动量，尽量做到独立精简；
合并的代码分支sg2002-dev： https://github.com/elliott10/StarryOS/tree/sg2002-dev

遇到的问题：

• 上物理板试验时，遇到间歇性弹乱码的问题，后来板子出现问题，串口无任何输出了，板子坏掉了。
• arceos -> axhal -> axcpu -> page_table_entry ，其他地方也在引用如axmm，starry-signal等组件，若需要page_table修改生效，需要对多颗依赖树及版本都更新修改，给合并带来不少难度。故有必要梳理依赖库，分类分层下。
  当前使用临时方案，[patch.crates-io]的方式也能全局覆盖基础库。

[Ticonderoga2017]

WiFi功能模块基本都开发完成，但是还是有问题没有解决：

1. 扫描结果为空
2. 连接超时

以上两个问题尝试了以下方法：

1. 检查数据传输过程中，CCCR寄存器的状态是否正常
2. 调试IPC消息流程，验证IPC消息内容，消息格式是否正确，修复小块数据使用BYTEMODE传输失败的问题
3. 分析扫描和连接功能完整执行过程，验证和修复数据对齐，修复数据传输宽度不匹配问题
4. 验证驱动发消息和解析流程是否正确
5. 对比LicheeRV，补全phy_cfg
6. 通过官方镜像，验证硬件工作正常
7. 补全SDIO错误恢复
8. 补全和验证扫描生命周期，验证扫描参数
9. 实现定向连接功能，硬编码数据包提供给驱动，测试连接
10. 实现软中断 + 多线程机制来处理固件异步响应问题
    （硬中断性能可能更好，需要修改架构配置，页表项，地址映射等内容，目前尚未实现）

项目地址：https://github.com/Ticonderoga2017/sg2002-wifi-driver.git
已添加了详细的README.md和项目架构介绍文档https://github.com/Ticonderoga2017/sg2002-wifi-driver/tree/main/dev_docs

[Ticonderoga2017]

大概找到扫描不到数据包的原因了：推测设备可能依赖SDIO中断，才能往FIFO里面写数据，尝试验证这个猜测

[elliott10]

sg2002平台FreeRTOS的代码仓库，并且看到也具备基本的驱动功能。

相关资料整理：

• GC4653摄像头FreeRTOS驱动源码:
  https://github.com/sophgo/freertos/tree/sg200x-dev/cvitek/driver/sensor/src/gcore_gc4653/

• 图像传感器Sensor驱动介绍：https://doc.sophgo.com/cvitek-develop-docs/master/docs_latest_release/CV180x_CV181x/zh/01.software/MPI/Sensor_Debugging_Guide/build/html/2_Introduction_to_Sensor_Drivers.html

• LicheeRV Nano (sg2002) 硬件板子的芯片资料：http://cn.dl.sipeed.com/shareURL/LICHEE/LicheeRV_Nano/07_Datasheet

• USB、UART、SD卡、烧录器等方法对单板进行烧录的介绍：https://doc.sophgo.com/cvitek-develop-docs/master/docs_latest_release/CV180x_CV181x/zh/01.software/BSP/Production_Burning_User_Guide/build/html/2_Overview.html

• 安全启动流程：https://doc.sophgo.com/cvitek-develop-docs/master/docs_latest_release/CV180x_CV181x/zh/01.software/BSP/Secure_Boot_User_Guide/build/html/2_Secure_Boot_Introduction.html

[elliott10]

FreeRTOS正常运行于小核, 如下图：
注: alios在当前板子的sdcard，发现并不能正常启动。原因应该在于该alios仓库只为特定EVB板型试验。

[elliott10]

编译选项打开’CONFIG_ENABLE_FREERTOS’

[Ticonderoga2017]

WiFi模块当前开发进展：已验证开放网络连接，加密网络四次握手AP拒绝M2帧问题暂时未解决
为sg2002平台实现PLIC支持：https://github.com/Ticonderoga2017/StarryOS/tree/sg2002/axplat-riscv64-sg2002；
WiFi模块完整实现：https://github.com/Ticonderoga2017/StarryOS/tree/sg2002/wireless，WiFi功能实现在fdrv crate下，并提供sdio驱动以支持WiFi功能

[elliott10]

2026-04-01 有关sg2002机器人手臂的交流纪要

@李明  @xiaoxiao  @御风  @泽辰  @stone-san 和@chyyuu 对2002机器人的工作进行了探讨，形成的初步分工。请@xiaoxiao@御风@泽辰@stone-san 在github discussion上进行工作进展的记录和技术方案的讨论。
我们争取能在这个月内完成如下目标：

1. 基于linux的机器人能够移动并捡起网球
2. 基于Starry的机器人能移动并捡起网球
3. 基于Starry的机器人比基于Linux的机器人在同样操作的流程中有某些方面的优势

• 目标概述：
  1. 完成 SG2002 平台上Starry的基本驱动；
  2. 实现视觉识别， 完成小球图像识别能力；
  3. TPU驱动的AI推理加速；
  4. 最终实现小车机械臂在Starry上的自动捡球应用；
  5. 在打通sg2002平台的识别并运动控制，到稳定性验证， 含异常重启等条件，尝试AI编程工具进行迭代；

---

初步分工

YJB

• 负责摄像头识别, 实现小球图像的识别；
• 尝试继电器实现板子重启方案；
• 对 UART、PWM等接口进行硬件验证。

SZH

• 负责与 PZC 对接需求与接口；在 Linux 系统上先行把“自动捡球”应用跑起来，形成可执行的Linux基线版本。

XLY

• 尝试在小核上运行 RTOS，并实现整机重启功能；
• 逐步整合现有驱动到统一仓库，降低后续协作成本。
  sg2002平台的支持及整合驱动的仓库放在：
  https://github.com/elliott10/StarryOS/tree/sg2002-dev
  并写了一个指导文档供参考：
  https://github.com/elliott10/axplat-riscv64-sg2002/blob/main/get-started.md

[pengzechen]

PZC

• 将原有tpu代码整理成单独crate，供萧老师集成
• 将原有ion也尝试整理为单独crate
• 协助志航跑通用户态机械臂程序

[pengzechen]

@yfblock 我看了你的aka0仓库，我觉得是不是可以添加抽象保留原来的摄像头的逻辑，兼容uart传输？

[pengzechen]

wifi传输的抽象可以放弃了，这个我已经验证过了。2002开热点性能不太行

[yfblock]

目前已经完成了 StarryOS 在 sg2002 上实现图像采集、识别到控制机器抓取的全流程，相关仓库如下：

https://github.com/yfblock/StarryOS/tree/sg2002
https://github.com/yfblock/axplat-riscv64-sg2002-1/tree/sg2002
https://github.com/yfblock/aka0
https://github.com/yfblock/arceos/tree/sg2002

esp32 固件如下：

https://github.com/yfblock/esp32-cam-firmware

esp32-cam 的 uart0 连接到 sg2002 的 uart3 上，电机连接 pwm 4 5 6 7 芯片上，舵机控制连接在 uart2 上。

由于 sg2002 的 uart0 被复用为 pwm 4 5，所以在使用的时候如果需要调试，需要将 https://github.com/yfblock/StarryOS/blob/646f5ba6e874a63138ba1238e593f116d4cbcd34/api/src/vfs/dev/robo_ctl.rs#L265-L272 注释掉。

esp32 firmware 中含有测试的 python 文件，如果有usb 转串口可以在电脑上尝试，但是经过 usbipd 或者虚拟化后在 1.5Mbps 下可能会有问题（Linux x86_64 也是如此）。

如果 Starry 的调试信息输出过多可能会导致接收数据异常（由于 log 的时候会关闭中断，而串口信息通过中断接收，如果串口大量快速发送消息那么超过缓冲区后就会丢失数据，在整合 dma 后会恢复正常）

[yfblock]

yfblock/sg200x-bsp@e31bd95 已经加入了 dma 控制器代码并且在 Starry 上测试了 uart 的 dma 操作，在目前小数据量的时候可以正常发送。大数据量和接收正在尝试。

[pengzechen]

esp32-cam wifi 固件：https://github.com/[pengzechen/esp32_camera_mjpeg_multiclient](https://github.com/pengzechen/esp32_camera_mjpeg_multiclient)
目前WiFi版本的固件经过测试，可以连续正常工作4个小时。要使用稳定的电源

[pengzechen]

小车 “摄像头捕获 推理 控制” Loop 效率最值得优化的点是模型量化。 200ms -> 50ms 大概能快四倍

[elliott10]

对系列的sg2002硬件平台支持的组件库，进行了修改整合提交，方便其他大库进行同步过去。 涉及到的StarryOS 适配 SG2002 的所有组件修改的说明：https://github.com/elliott10/axplat-riscv64-sg2002/blob/main/doc/sg2002-porting-components.md

[elliott10]

具体的组件修改如下：
arceos axdriver的添加存储的mbr分区表支持：arceos-org/arceos#364
axdriver_block存储设备驱动，基于yjb驱动库：arceos-org/axdriver_crates#27
axcpu更新了对sstatus寄存器拓展属性的设置； 并在进入用户空间前刷新所有指令cache：arceos-org/axcpu#36
对页表项的拓展的修改pr：arceos-org/page_table_multiarch#46
发布了串口驱动：https://crates.io/crates/dw_uart_rs
发布了sg2002硬件平台支持包： https://crates.io/crates/axplat-riscv64-sg2002
发布独立的sg2002 tpu加速驱动库 https://crates.io/crates/tpu-sg2002