用AGENT在QEMU上搭建RISC-V AI实验台

搞芯片的人最缺的往往不是芯片而是一块可以随便折腾的实验台。做了几年 RISC-V 相关开发我的体会很直接想在 RISC-V AI 方向上验证软件栈、编译链、启动链路靠真板子排队、等流片、或者借 FPGA 原型机效率都太低。先用 QEMU 在本地拉起一块虚拟的 RISC-V AI 芯片把环境全部打通再让 AGENT 把这套搭建流程固化下来、随时可重建这才是最稳也最省钱的路径。这篇是系列第一篇标题其实已经说清楚了用 AGENT 做 QEMU 环境搭建拉起一块 RISC-V AI 芯片的实验台。适合谁看想入坑 RISC-V 系统软件、芯片验证、嵌入式 AI 的同学以及已经用开 AI Agent 但不知道怎么把它用进严肃工程任务的工程师。文章不会只丢命令我会把每个关键选择背后的原因、踩过的坑、Agent 交互时的验收思路都讲明白保证你可以照着复现而不是照抄一堆自己都看不懂的参数。1. 为什么非要在 QEMU 上搭一块 RISC-V AI 实验台先解决一个根本问题明明有开发板为什么要用模拟器很多刚接触的人觉得“模拟器跑得慢、不真实”但做系统验证的场景恰恰相反QEMU 在很多地方比真板子更合适。1.1 绕不开的三个理由第一个理由是成本。一块支持向量扩展的 RISC-V 开发板不便宜如果只是做启动流程验证、驱动调试、编译器跑分买回来大部分时间在吃灰。而 QEMU 是纯软件方案一台普通笔记本就能同时虚拟出好几块“开发板”想砸就砸想重来就重来。第二个理由是可控性。真芯片出问题时你只能靠调试器怔怔地看着它但 QEMU 的模拟环境里时钟是确定的中断是可控的内存可以随意改甚至能记录整条执行轨迹再回放。做芯片验证的人特别吃这一套因为回归测试要的就是“同样的输入、同样的结果”真板子反而会因为时序问题给你搞出随机性。第三个理由是工程化。一套能脚本化启动、能进 CI 的虚拟实验台意味着每次代码变更后都可以自动跑一遍完整启动流程和 AI 负载测试。这比“连上板子、手动烧录、看串口输出、截图记录”要靠谱一个数量级。把环境搭建本身交给 AGENT 去维护就更是锦上添花了。1.2 实验台到底要模拟出什么很多人一听“模拟 RISC-V AI 芯片”会以为 QEMU 真能给你模拟出一个完整 NPU。这里我得先把预期说清楚QEMU 默认不会模拟 NPU 或者张量核心它能提供的是 RISC-V CPU 指令级的精确模拟尤其是向量扩展RVV。你可以在模拟器里跑带有向量指令的 AI 算子库验证算法正确性、评估指令调度效果。如果你要更接近真实 AI 芯片的形态做法通常有两种一种是在 QEMU 上启用-cpu max或-cpu rv64,vtrue把向量扩展打开软件栈在这个环境里跑矩阵乘、卷积、量化推理这已经能覆盖大多数算法移植问题另一种是利用 QEMU 的设备模型框架自己写一个 MMIO 加速器设备模拟真正的 NPU 寄存器、中断和 DMA 通路把矩阵运算单元以虚拟外设的方式挂到系统总线上。本文先把第一种方案做扎实。后面有条件了我再写一篇专门讲怎么在 QEMU 里自定义 AI 加速器设备模型。所以这个实验台的核心组成非常清晰RISC-V 64 位 CPU 模拟附带向量扩展一套交叉编译工具链负责把代码变成目标机器码一个最小可启动的裸机固件或 Linux 内核作为运行底座一个 AI 相关的软件负载比如算子测试程序AGENT 工作流负责把以上步骤全部可复现地跑起来。2. 用 AGENT 搭台先把活儿拆明白现在聊 AGENT。很多人以为“用 AGENT 做事”就是把需求丢给它然后等结果。真按这个思路搭 QEMU 环境大概率会收获一堆看着合理、跑起来报错的脚本。我的经验是AGENT 能干活但它需要你把活拆成它能理解和验证的任务块并且每块都有明确的验收条件。2.1 Agent 在环境搭建里到底干什么活先说清楚我这里的 AGENT 指什么。它可以是本地跑的编码智能体也可以是你日常开发中使用的支持工具调用的 Agent 框架总之是一个能自己读文档、生成文件、执行命令并读取输出的自动化程序。在这种环境搭建任务里AGENT 最有价值的四个能力分别是任务拆解它会自动把“搭建 QEMU RISC-V 环境”拆成若干子任务比如装 QEMU、准备工具链、写链接脚本、编译、运行、调试代码与脚本生成它懂 QEMU 命令行参数、懂交叉编译器的用法可以直接产出 Makefile、链接脚本和启动汇编错误日志解读QEMU 报错信息有时候特别绕Agent 能帮你把日志里的关键问题摘出来尝试修复后再跑环境固化一旦环境调通它可以基于这些命令生成一份可直接重建的脚本下次一键恢复。但是要注意AGENT 的短板也很明显它不真正理解你的硬件目标也不了解你手头项目的约束。尤其是链接地址、启动入口、中断控制器编号这类细节它很容易“想当然”。所以人类工程师的职责不是写每一行命令而是定义验收标准然后让 AGENT 在标准内自由发挥。2.2 一张可以直接抄的任务拆解模板我实践下来的做法是在开头给 Agent 一份高度结构化的任务描述直接写清楚里程碑和验收标准。下面这个模板我建议你直接抄走目标搭建一个 QEMU RISC-V 64 位裸机实验环境用于运行 AI 向量计算测试程序。 里程碑 M1安装 QEMU 与 RISC-V 交叉编译工具链输出版本号。 M2编写最小裸机程序编译为 ELF用 QEMU virt 机器启动并输出 Hello。 M3启用向量扩展运行一个 8x8 整数矩阵乘法打印结果并退出。 M4将以上步骤整理成一个 Makefile 一键脚本支持 clean 后重新构建。 约束 - 只用 QEMU 原生 virt 机器不修改 QEMU 源码 - 链接地址必须放在 DRAM 基地址 0x80000000 - 串口使用 virt 平台默认 UART 地址 0x10000000 - 所有构建产物必须生成在当前目录 build/ 下 - 每一步执行完后给出日志摘要和下一步建议。这个模板的好处是AGENT 每完成一个里程碑你都可以独立验证。M1 跑一下命令就有输出M2 看串口有没有 HelloM3 看矩阵乘结果对不对M4 检查脚本能不能 clean rebuild。每段都像一个小的验收门任何一个环节挂了你都能准确知道是工具链的问题、链接脚本的问题、还是向量指令的问题而不是一团乱麻。我这几次实操下来最费时间的其实是 M2 到 M3 这中间的调试。Agent 生成的代码往往能一次编译通过但跑起来打印乱码或者直接无输出这时候就要靠下面的链路知识来定位了。3. QEMU 基础设施部署从安装到机器选型聊完思路开始动真格。这一部分先把 QEMU 本身准备好并且搞清楚 virt 机器的选型和参数。3.1 安装 QEMU 和工具链版本别太老QEMU 对 RISC-V 的支持已经很成熟但还是建议用相对新的版本。老版本里virt机器支持的设备种类少设备树生成逻辑也差一些干扰排查。在 Ubuntu / Debian 系系统上直接装就好sudo apt update sudo apt install qemu-system-misc gcc-riscv64-unknown-elf如果不放心版本可以用官方源码编译。源码编译时记住只编需要的 target能省不少时间git clone https://gitlab.com/qemu-project/qemu.git cd qemu mkdir build cd build ../configure --target-listriscv64-softmmu --prefix/opt/qemu-riscv make -j$(nproc) sudo make install我个人的偏好是用源码编译不是因为发行版自带的 qemu-system-misc 不好用而是因为后续如果你要加自定义 AI 加速器设备模型就得自己编译 QEMU。到那一步这套源码构建的流程你已经走熟了踩坑概率会小很多。安装完验证一下qemu-system-riscv64 --version riscv64-unknown-elf-gcc --version如果输出正常基础工具链就绪。3.2 virt 机器与 CPU 扩展别一上来选错型RISC-V 的 QEMU 支持好几种机器常见的包括virt、sifive_u、sifive_e。我的建议是主线开发一律用virt。原因很简单virt是 QEMU 专门为了模拟验证设计的通用平台外设齐全设备树自动生成支持的启动方式也干净。如果你的目标是仿真某款具体芯片比如 SiFive 家的 SoC再切到对应型号否则别把时间花在和具体板子的兼容性纠缠上。CPU 的选择更关键。默认情况下QEMU 的virt机器可能不会自动启用向量扩展。这里有两个稳妥做法一个是用-cpu max让 QEMU 把支持的全部扩展都打开另一个是手动指定-cpu rv64,vtrue。我倾向后者因为更可控你明确知道自己开了什么。检查支持的 CPU 类型和扩展qemu-system-riscv64 -cpu help qemu-system-riscv64 -M virt -cpu rv64,vtrue --nographic如果 CPU 支持列表里能看到 rv64那基本就够了。实际操作里我建议先用max快速跑通整体流程再收敛到一个固定的 CPU 配置。每次换 CPU 配置后必须重新跑一遍完整测试因为不同 CPU 配置可能会影响指令集兼容性。3.3 启动一块“裸金属”的冒烟验证在写完完整启动程序之前可以先做一次最简单的冒烟验证确认真机和命令行参数没有低级错误。可以把任意一个 RISC-V 64 位 ELF 文件作为 BIOS 传进去。比如用下面这段最小汇编编译出一个能写入死循环的固件.section .text.init .globl _start _start: li t0, 0x10000000 1: li t1, 0x41 # A sb t1, 0(t0) j 1b这段代码的意思是往地址 0x10000000 不断写入字符A。0x10000000 是 QEMU virt 机器默认的 UART 寄存器地址往数据寄存器里写一个字节串口就会输出一个字符。编译它不是用普通 GCC 直接编一般先用汇编器生成目标文件再用裸机工具链链接。命令大致如下riscv64-unknown-elf-as -marchrv64gc start.s -o start.o riscv64-unknown-elf-ld -Ttext0x80000000 start.o -o start.elf qemu-system-riscv64 -M virt -cpu rv64 -nographic -bios start.elf如果你在串口上看到一个不断滚动的A说明 QEMU、机器选型、串口地址全部没有问题。这一步虽然简单但它把问题空间直接缩小到了“从 0x80000000 开始运行往串口写数据”这个最小闭环非常值得先做一遍。这里有个细节很多人会忽略为什么链接地址要放在 0x80000000因为 QEMU virt 机器的 DRAM 基地址就是 0x80000000复位后 CPU 从-bios指定的入口开始执行而入口地址和链接地址必须精确匹配。如果链接脚本把代码放到了 0x80001000CPU 一上来必然跑飞。4. 最小可运行系统的关键link.ld、启动代码和设备树冒烟验证通过之后就该搭建一个真正可扩展的“最小系统骨架”了。这个阶段有三样东西是绕不开的交叉编译工具链、链接脚本link.ld、以及启动代码。对 RISC-V 来说理解了这三样基本就掌握了整个平台开发的钥匙。4.1 交叉编译工具链与裸机编程的基础认知所谓交叉编译简单说就是“在一个架构上编译出另一个架构能跑的机器码”。我们在 x86 电脑上用riscv64-unknown-elf-gcc编译出 RISC-V 的 ELF 文件。riscv64-unknown-elf这套工具链不带 Linux 头文件和库适合裸机程序如果后面要跑 Linux 内核则需要riscv64-linux-gnu-gcc。新手经常会在这里犯迷糊把两套工具链混着用。裸机情况下错误地用 Linux 工具链可能会带入 glibc 的动态库依赖而 QEMU 里根本没有操作系统帮你加载动态库最终程序必然跑不起来。还有一套东西是必须和裸机配套使用的链接脚本。链接脚本的作用是告诉链接器“把代码放在哪个地址、数据放在哪个地址、栈顶放在哪里”。对于裸机程序你没有操作系统分配内存所有布局全靠链接脚本来定。4.2 link.ld 的坑与设计从 0x80000000 说起我见过很多 RISC-V 裸机程序跑不起来的案例排查到最后一半以上问题出在链接脚本。它不是随便写写就能用的地址稍微偏差一点点连串口都点不亮。以一个最简可用的link.ld为例OUTPUT_ARCH(riscv) ENTRY(_start) MEMORY { RAM (rwx) : ORIGIN 0x80000000, LENGTH 256M } SECTIONS { .text : { *(.text.init) *(.text) } RAM .rodata : { *(.rodata) } RAM .data : { *(.data) } RAM .bss : { *(.bss) } RAM /DISCARD/ : { *(.comment) *(.riscv.attributes) } }文件里最核心的就是这一句ORIGIN 0x80000000。这就是前面说的 DRAM 基地址。整个代码段的起始地址必须卡在这里。实际项目里还需要额外定义栈指针的位置。比较好的做法是在链接脚本末尾留出栈空间__stack_top ORIGIN(RAM) LENGTH(RAM);然后把栈顶地址暴露给启动汇编。注意栈是向下生长的所以栈顶要放在 RAM 的最高地址处。这个细节看着简单但一旦忘掉C 函数第一次调用时栈溢出整个程序立刻行为诡异。还要提醒一个坑为了兼容大范围跳转编译时建议加上位置相关代码模型参数-mcmodelmedany。RISC-V 默认的代码模型有时候链接器生成的跳转指令覆盖不了整个地址空间结果就是程序启动后跳到一个完全错误的地方。这是我被坑过最惨的一次甚至一度怀疑是 QEMU 的问题。4.3 启动汇编_R_start 之后首先要做两件事任何裸机程序的起点都是一个入口函数在 RISC-V 里约定俗成叫_start而且要在链接脚本里通过ENTRY(_start)显式声明。_start的第一个动作就是设置栈指针。下面是我常用的最小启动汇编.section .text.init .globl _start _start: la sp, __stack_top # 设置栈顶 csrr t0, mhartid # 读取当前核心编号 bnez t0, _hang # 非 0 号核心暂时挂住简单场景只用一个核 # 清零 BSS 段 la t0, __bss_start la t1, __bss_end 1: bge t0, t1, 2f sw zero, 0(t0) addi t0, t0, 4 j 1b 2: call main # 进入 C 主函数 _hang: j _hang这里__bss_start和__bss_end需要在链接脚本里定义否则汇编器会报未定义符号。BSS 段清零是必须做的因为 C 语言默认未初始化全局变量为零如果你不清零变量初始值就是随机的。mhartid是硬件线程 ID多核时候会用到。这套汇编里暂时只让 0 号核进入主程序其它核死循环挂住避免多核同时跑同一份代码踩踏共享资源。我见过有一些教程把启动汇编写得很漂亮支持多核加核间唤醒但对一个实验台来说先单核跑通是最高优先级。全功能的多核启动可以等 AI 算子框架需要跑多核再上。4.4 设备树QEMU 自动给还是手动传设备树Device Tree是描述整块板子上有哪些设备、地址在哪、中断号是多少的数据结构。QEMU virt 机器默认会生成一份设备树你可以用下面命令导出qemu-system-riscv64 -M virt -nographic -machine dumpdtbriscv-virt.dtb导出的 DTB 文件是二进制格式可以用dtc工具反编译成可读的 dtsdtc -I dtb -O dts riscv-virt.dtb -o riscv-virt.dts打开这个 dts 文件你会看到 UART 的地址在 0x10000000中断控制器的属性、内存大小等信息都在里面。裸机程序不一定非要解析设备树直接在代码里硬编码 UART 地址就行但如果要适配多种平台或者把实验台扩展成“能启动 Linux 内核”就必须和设备树打交道了。我记得有一次把同样一份裸机镜像从 virt 换到 sifive_u 上跑串口完全没输出。查了半天发现两个平台的 UART 地址根本不一样。这类问题用设备树一对照就明白了。5. Agent 实操工作流别让它替你乱踩坑让它帮你跑通流程环境基础设施都准备好了接下来就是重头戏怎么把 AGENT 真正用起来。这节我不讲抽象概念直接模拟一次真实的任务交互过程。5.1 一个能落地的最小任务会话假设我现在有一个干净目录想用 Agent 生成完整的裸机骨架。我给它的提示词是这样请在当前目录生成一个 RISC-V 64 位裸机项目满足以下要求 - 使用经典分段布局链接地址 0x80000000 - 启动汇编设置栈指针、清零 BSS、调用 main - main.c 实现一个 4x4 整数矩阵乘法并把结果通过 UART 打印UART 地址 0x10000000; - 提供一个 Makefile包含 build、run、clean 三个目标 - run 目标调用 qemu-system-riscv64 -M virt -cpu rv64,vtrue -nographic。Agent 一般会生成start.S、main.c、link.ld、Makefile四个文件并把编译命令写全。但这个时候千万别直接执行make run你先把四个文件读一遍。我至少要检查三件事link.ld里ORIGIN是不是真的写了0x80000000start.S里串口写数据用的地址是不是0x10000000Makefile里的-cpu rv64,vtrue是不是会报错——不同 QEMU 版本对 CPU 扩展的写法有差异。“人的验收”永远是 Agent 工作流的中心。Agent 的价值在于快速生成一个 80 分的骨架你的价值在于用 20 分钟检查它并把那 20 分钟沉淀成后续可以复用的验收清单。5.2 Agent 跑出错时如何把日志喂回去现实世界没有这么顺利。十次运行里总有一两次 Agent 生成的代码启动后无输出。这时候我就会把 QEMU 的日志和 Agent 的源文件一起丢回去告诉它运行 make run 之后串口没有任何输出进程直接退出。 请分析下面这段日志并检查 start.S、link.ld、main.c 是否有错误 [在这里粘贴日志]然后 Agent 会自己盯着链接地址、串口地址、入口符号查。多数情况下它自己能修出一个新版本。如果你只是让它看报错不给日志那就变成了“盲猜”效率极低。这里要特别提一句Agent 试错次数是有限的如果同一类错误它连续修不好别再让它继续猜你先手动看一下链接地址和 UART 地址有没有和约定不一致。我自己遇到的九成问题都出在这些“约定俗成”的地址上机器不会提醒你Agent 也不知道只有你心里有数。5.3 把一套成功流程固化成可重复的“任务书”当整个流程跑通我能看到矩阵乘法结果打印出来之后最后一件事是把这次任务的完整描述升级成一份可以重复使用的“任务书”。以后想重建环境直接把任务书丢给 Agent按 taskbook.md 中的说明在当前环境创建一个相同结构的 QEMU RISC-V AI 实验台。这份 taskbook 我会写成 Markdown 文档里面记录着所有关键约束、验收命令、常见问题链接。这样好处非常明显环境配置漂移了可以一键重建别人接手项目也有了一份真实可行的文档。Agent 在这里充当的不是一次性代码生成器而是环境状态的管理器。5.4 Agent 输出的“未经验证等于零”最后强调一点Agent 说“已经完成”不等于真的完成。哪怕它已经写完了 Makefile 并声称测试过你也要亲自跑一遍make clean make run。因为 Agent 运行环境和你本地环境可能不一致它以为“测试过”很可能只是“语法上看起来没问题”。我的习惯流程是先生成、再人工审阅、再执行、再把执行结果反馈回去。这四步缺一不可。6. 常见问题与排查实录现在是干货时间。把我在搭建过程中真正遇到过的问题整理成了一份速查表这些问题里面有一半是新手必踩另一半是我觉得平时文档里根本不会写的细节。6.1 启动失败与串口异常问题速查症状可能原因快速定位与修复QEMU 启动后立刻退出无任何输出链接地址不是 0x80000000入口和链接地址不匹配检查 link.ld 的 ORIGIN确认_start在.text.init段启动后串口狂刷乱码UART 地址用错或平台不是 virt确认串口地址为 0x10000000换sifive_u时地址会变程序能编译但运行后无输出没设置栈指针或 main 没被调用检查_start里是否有la sp, __stack_top超出内存范围的非法访问栈顶地址超出 RAM 范围或 BSS 段过大检查 link.ld 中的LENGTH给栈留足空间向量指令执行时报非法指令CPU 配置没开向量扩展使用-cpu rv64,vtrue或-cpu max编译报 relocation 错误代码模型没设对编译参数加-mcmodelmedanyQEMU 找不到内核或 BIOS路径错误或没指定-bios明确-bios指向 ELF 文件不要和-kernel混用gdb 连不上 QEMU没开远程调试端口加-s -S参数然后gdb里target remote :1234很多人在 QEMU 无输出时第一反应是看代码逻辑但实际上 80% 的情况是地址错了或者入口错了。先对照这张表再深入代码效率最高。6.2 关于设备树、内核和 AI 负载的几个实战心得如果你想在这个实验台上跑 Linux 而不是裸机流程会多出几步需要一个 OpenSBI 固件充当监督模式入口一个 RISC-V Linux 内核镜像以及一份 busybox 根文件系统。QEMU 启动命令会变成qemu-system-riscv64 -M virt -cpu rv64,vtrue -m 2G \ -nographic \ -bios fw_jump.bin \ -kernel Image \ -drive filerootfs.img,formatraw,ifvirtio \ -append root/dev/vda rw到这一步你会发现设备树的作用开始显现。virt机器会自动生成适配当前内存和设备的 DTB 传给内核不需要你手动传前提是你别用-dtb硬塞一份不匹配的文件。我以前踩过这个坑导出了 DTB 传给内核但 QEMU 后来改了内存大小设备树里还写的是旧值内核启动后内存管理直接混乱。AI 负载方面如果你想在裸机实验台上验证基础算子最简单的不是接一个完整框架而是手写一个带向量扩展的矩阵乘。RISC-V 向量扩展的指令很多先从一个最简单的浮点向量加法或者 8x8 整数矩阵乘法开始编译时加-marchrv64gcv链接时链接脚本不用变化。跑通了再考虑移植 TFLite Micro 或者 RVV 优化的推理库。6.3 调试习惯让 QEMU 替你“开口说话”最后分享几个非常实用的调试习惯。QEMU 自身提供了很多诊断手段别等到程序跑挂了才拍脑袋。第一个是打开 QEMU 指令日志。在命令行里加-d in_asm,cpu它会打印出当前执行的指令和 CPU 寄存器状态。配合-D log.txt日志会输出到文件不会刷爆终端。程序“莫名”跑飞的时候看最后几条日志你就能知道它到底跳到了哪里。第二个是善用-d guest_errors。Guest 访问非法地址、尝试非法操作QEMU 会给出明确提示。很多 UART 问题其实就是 guest_errors 里一句“Invalid write at addr 0x...”直接点破的。第三个是回归意识。每次改完链接脚本或者 CPU 配置后都重新跑一次完整流程不要只跑单个测试。我曾连续两天因为“改了一点小配置以为影响不大”导致 AI 算子测试出来结果全错最后发现是最开始那次把 CPU 扩展关了。环境搭建好后把所有验证步骤收敛成一个make test目标每次改完直接跑它。最后再分享一个小技巧这套流程跑通以后我觉得最值得沉淀的是 Agent 任务书。每次收到新任务不是直接让它开工而是先花五分钟把验收标准写清楚。有一次我甚至把 link.ld 的地址写错成了 0x80010000Agent 照单全收最后检查时一眼看穿省了一整轮调试。这件事给我的启发是Agent 可以写出漂亮的代码但关于硬件地址和平台约束这类信息永远要由你来做最终确认。下一阶段我打算在 QEMU 的 virt 平台上搞一个自定义的 AI 加速器设备模型把真正的矩阵运算单元挂到总线上到时候再继续更新。