RISC-V虚拟化实战：QEMU上同时跑通Zephyr与Linux

先聊个实际的。RISC-V这两年在嵌入式圈子的热度，已经不需要我再画什么曲线图了，但真正动手跑过系统的人，比围观的人少得多。原因很简单，资料大多数停留在“介绍架构特性”和“跑个hello world”的阶段，一旦想同时接触RTOS和完整Linux，就得自己把工具链、模拟器、编译流程、启动链全部捋一遍。这篇文章把我自己从零搭环境、在QEMU上把Zephyr跑起来、再用同一套RISC-V平台引导Linux的完整过程整理出来了，适合刚接触RISC-V的嵌入式开发者、正在评估Zephyr的企业工程师，以及那些想在虚拟环境里先验证方案、暂时不想买开发板的同学。

我不打算讲理论讲到天上去，全程以QEMU模拟的RISC-V virt平台为基准，先把Zephyr这个实时操作系统的编译和运行打通，再切到Linux内核的编译、initramfs制作和启动流程。整个过程用到的都是免费开源工具链，只要一台Ubuntu机器就能复现。

1. 先搞清楚为什么要让RISC-V同时跑Zephyr和Linux

1.1 RISC-V生态的现实情况

RISC-V的指令集开源这件事，行业里已经讨论得够多了。但从一个做嵌入式的工程师视角看，真正的变化是：以前评估一个芯片要花很长时间和原厂沟通、申请样片、看datasheet，现在RISC-V架构让你可以先在纯软件的模拟环境里把整个软件栈跑通，不用等硬件就位。这种“先软件后硬件”的开发模式，对于项目前期评估来说非常友好。

不过RISC-V也有一个实际问题，就是生态碎片化。ARM那边有成熟的Toolchain、调试器、RTOS支持、Linux发行版适配，一套工具链吃遍所有芯片。RISC-V因为每家SoC的核数、中断控制器、外设地址都可能不一样，导致同样的内核代码在这个板子上能跑、换个板子就要改设备树。解决这个问题的思路，就是先在QEMU的virt平台上跑通一套通用流程，后面再针对具体芯片做BSP适配。

1.2 Zephyr和Linux的定位差异

Zephyr和Linux本来是两种不同定位的东西，但在评估一块新架构的芯片时，它们恰好是“一个管底层、一个管上层”的组合。

Zephyr是一个为资源受限设备设计的RTOS，最小配置下只需要几十KB的RAM，支持多线程、信号量、消息队列、设备驱动模型，还引入了设备树来管理硬件描述。它跟FreeRTOS最大的区别在于：Zephyr更强调“可裁剪+可配置”，而且背后的社区维护了一个非常完整的驱动框架，很多RISC-V SoC的UART、GPIO、SPI驱动都已经在主线里了。

Linux则完全不同，它需要MMU，需要至少几MB的内存，需要完整的启动链，但换来的是强大的进程管理、虚拟内存、文件系统和海量现成驱动。一个典型的RISC-V SoC如果跑在10MHz、只有64KB SRAM，那Zephyr是唯一选择；如果跑在几百MHz、外挂DDR，那Linux就能承担更复杂的业务逻辑。

这篇文章里我把两个系统放在同一个QEMU环境里跑，目的就是让你直观感受这个分工：Zephyr快速启动、低延迟响应；Linux承担复杂调度和文件系统。实际项目中很多SoC是异构多核，小核跑Zephyr做实时控制，大核跑Linux做应用处理，这套组合在工业控制和边缘计算里越来越常见。

2. 起步环境：Ubuntu上的RISC-V交叉工具链与模拟器准备

2.1 安装QEMU模拟器

QEMU是目前支持RISC-V最成熟的模拟器，它不仅能模拟完整的virt开发板，还能模拟SiFive、StarFive等具体板卡。对于大多数学习场景，我建议直接使用QEMU的virt machine，因为它不需要特定板卡的全部外设细节，只要关注CPU核心和基础内存映射就行。

在Ubuntu系统上安装QEMU非常简单：

sudo apt update sudo apt install qemu-system-misc

安装完检查一下版本：

qemu-system-riscv32 --version qemu-system-riscv64 --version

我建议两个架构的模拟器都装上。Zephyr虽然有riscv32和riscv64两个目标，但实际使用中riscv32的资源占用更小、启动更快；Linux则必须先跑riscv64，因为主流的发行版和buildroot默认都是针对64位架构做优化。后面你会看到，同一个virt平台，两个架构的核心、内存和外设地址略有差异，编译时要区分开。

2.2 RISC-V GNU工具链：apt安装还是源码编译

交叉编译是嵌入式的日常，RISC-V的工具链通常指gcc、binutils、gdb这一套，它们支持riscv64-unknown-elf这类裸机目标，也支持riscv64-linux-gnu这种带glibc的Linux目标。

最简单的安装方式是用apt：

sudo apt install gcc-riscv64-unknown-elf gdb-multiarch sudo apt install gcc-riscv64-linux-gnu

riscv64-unknown-elf用于编译Zephyr、裸机程序、RTOS固件，它不链接libc，生成的elf可以直接烧到Flash或加载到QEMU。riscv64-linux-gnu则用于编译Linux内核、busybox、用户态程序，它默认链接glibc，生成的程序要跑在Linux环境里。

这里有个常见的坑：apt源里的工具链版本往往不是最新的，而Zephyr SDK的版本更新很快，两者版本差异过大可能导致链接失败。所以如果只做Zephyr开发，我更建议直接使用Zephyr官方SDK，它自带匹配的riscv工具链，省去很多版本对齐的麻烦。SDK的安装会在下一节说。

2.3 west与Zephyr SDK的安装

Zephyr现在使用west作为多仓库管理工具，zephyr主仓库、hal（硬件抽象层）、第三方库都是通过west拉取的。安装west需要Python3和pip：

sudo apt install python3-pip pip3 install west

然后初始化一个Zephyr工作目录：

mkdir zephyr-project && cd zephyr-project west init -m https://github.com/zephyrproject-rtos/zephyr --mr v3.7.0 west update

west update这一步会拉取所有子模块，包括modules/hal下的各种厂商HAL代码，所以耗时较长，网络不好的时候要有心理准备。拉完后目录结构大致是这样：

zephyr-project/ ├── zephyr/ # 主仓库 ├── modules/ # HAL、加密库、文件系统等 ├── tools/ # 辅助工具 └── .west/ # 配置文件

Zephyr SDK则是一个打包好的工具链集合，包含riscv、arm、x86等所有架构的编译器。去Zephyr官网下载对应版本的SDK tar包，然后解压安装：

wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v0.16.8/zephyr-sdk-0.16.8_linux-x86_64.tar.xz tar xvf zephyr-sdk-0.16.8_linux-x86_64.tar.xz cd zephyr-sdk-0.16.8 ./setup.sh

安装时它会把sysroots里的工具链路径加到环境变量里，还会安装一个zephyr-sdk-env.sh脚本。在~/.bashrc里加上这样一行，每次终端打开就自动加载：

source ~/zephyr-sdk-0.16.8/zephyr-env.sh

这样Zephyr的编译环境就算准备好了。如果不想下载完整SDK，也可以用apt装的gcc-riscv64-unknown-elf代替，但要注意在zephyr的CMakeLists.txt里指定工具链前缀，而且某些Zephyr版本对gcc版本有要求，这个后面会讲。

3. Zephyr在RISC-V上跑起来：从构建系统到串口输出

3.1 Zephyr的构建系统到底做了什么

Zephyr用CMake+Kconfig这套组合来管理工程配置。Kconfig负责配置开关，CMake负责生成构建文件和编译。每个board目录下会有一个<board>_defconfig文件，里面存的是这个板子的默认配置项，比如芯片型号、时钟频率、外设使能情况。

当我执行west build -b qemu_riscv32 samples/hello_world时，构建系统会做这几件事：

1. 根据-b qemu_riscv32找到zephyr/boards/riscv/qemu_riscv32/目录下的qemu_riscv32_defconfig和qemu_riscv32.dts。
2. 解析设备树，生成zephyr.dts和generated_dts_board.h，这个头文件里是每个外设的基地址、中断号等宏定义。
3. 根据Kconfig的配置选项，裁剪需要编译的源文件。
4. 调用riscv工具链编译所有源文件，最终链接出zephyr.elf。

这里面设备树的作用值得多说一句。Zephyr从2.x版本开始全面引入设备树，驱动不再通过硬编码的地址宏来访问硬件，而是通过DT_NODE_LABEL这类API从设备树节点获取硬件信息。这跟Linux的设备树思路是一样的，只是Zephyr在编译阶段就把设备树的信息编译进了固件，运行时不解析dtb文件。

3.2 编译hello_world并跑在QEMU上

先用默认的qemu_riscv32板子编译一个最简单的hello_world：

cd zephyr-project west build -b qemu_riscv32 -p always samples/hello_world

-p always表示每次构建前都先clean，避免旧配置残留导致莫名其妙的问题。编译完的产品在build/zephyr/zephyr.elf和build/zephyr/zephyr.bin。

直接用west运行：

west build -t run

这个命令会自动调用QEMU，并且我们能在终端上看到输出：

*** Booting Zephyr OS build v3.7.0 *** Hello World! qemu_riscv32

第一次看到这个输出，意味着你的RISC-V交叉工具链、Zephyr构建系统、QEMU模拟器三者已经打通了。

这里要强调一个点：Zephyr的最小系统是跑在bare metal上的，没有bootloader，没有操作系统，zephyr.elf被QEMU直接加载到内存后从_start开始执行。所以Zephyr的启动速度极快，在QEMU上几乎是瞬间就完成了初始化并进入应用代码。

3.3 切换riscv64和更多示例

如果之前装了riscv64的QEMU，可以试一下64位目标：

west build -b qemu_riscv64 -p always samples/hello_world west build -t run

riscv64的板子启动时会进入64位模式，寄存器宽度、地址空间都不同，但对用户应用来说差别不大，底层代码由Zephyr的arch目录封装好了。

建议多试几个Zephyr自带的sample，特别是samples/shell/shell_module：

west build -b qemu_riscv32 -p always samples/shell/shell_module west build -t run

这个sample会启动一个串口shell，能在里面执行kernel threads、device list、help等命令，对于了解Zephyr的设备模型和线程调度非常有帮助。我在调自己写的驱动时经常开着这个shell，直接在运行时查看设备树注册状态和线程栈使用率。

3.4 基于实际板卡移植Zephyr的几个关键点

QEMU跑通只是第一步，很多人最终是要把Zephyr移植到真实的RISC-V芯片上。根据我的经验，移植的核心工作集中在三块：

第一，确认SoC的CLINT和PLIC地址。Zephyr RISC-V架构依赖CLINT提供定时器和软件中断，依赖PLIC管理外部中断。不同厂家的SoC外设地址都不一样，比如一些国产MCU会把CLINT放在0x2000000附近，和SiFive的标准布局一致；但也有芯片会调整基址。这些信息必须从datasheet的内存映射图里查清楚。

第二，编写或修改设备树文件。在zephyr/boards/riscv/<board>/目录下新建<board>.dts，然后把UART、GPIO、SPI等设备节点按实际地址写进去。设备树写得好不好，直接决定了你能不能用现成的驱动。

第三，配置时钟树。Zephyr的设备树里会定义一个clocks属性，里面包括时钟源、分频系数等。RISC-V芯片的时钟配置比ARM简单，但如果你用的是PLL倍频出来的core clock，必须在.dtsi里把频率关系写对，否则延时和波特率都会出错。

对于不想从零开始的朋友，可以先找一块和你的目标芯片相似的板卡，比如把SiFive的HiFive1 Rev B作为模板，改芯片名、地址、外设，比完全凭空写要快很多。

4. Linux on RISC-V：OpenSBI、内核Image与initramfs的完整启动链

4.1 Linux on RISC-V的启动流程和ARM有什么不同

ARM64的Linux启动通常经过ROM->u-boot(SPL)->ATF->u-boot->kernel这个过程，RISC-V的启动链则更简明：ROM加载OpenSBI，OpenSBI跳转到Linux内核。OpenSBI的角色类似ARM的ATF，运行在M模式，提供SBI（Supervisor Binary Interface）调用给内核使用。

QEMU的virt machine默认自带OpenSBI固件，所以如果只是跑默认配置，不需要额外编译RISC-V的bootloader。QEMU在启动时会把OpenSBI放到内存起始地址，然后跳转到内核入口。QEMU的完整启动链路是：

QEMU固件(OpenSBI) -> Linux内核Image -> initramfs -> /init

理解这条链对排查启动问题很重要。比如内核打印第一行日志之前如果卡住，通常是OpenSBI没起来或者内核入口地址不对；如果内核日志出现但挂载不了根文件系统，那就是initramfs或者root参数的问题。

4.2 编译RISC-V 64位Linux内核

先下载内核源码：

git clone https://github.com/torvalds/linux.git cd linux git checkout v6.6

配置的时候直接使用RISC-V的默认配置：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig

defconfig对riscv架构会生成一份包含基础驱动、串口、块设备、网络支持的配置。如果后续要在真实板卡上跑，通常还要用menuconfig勾选对应的网卡驱动和存储控制器驱动。

编译：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc)

编译产物在arch/riscv/boot/Image。这个Image是未经压缩的内核镜像，QEMU可以直接加载。如果你看到还有一个Image.gz，那是压缩版，一般给u-boot用，QEMU加载Image就行。

整个编译过程大概三五分钟，取决于机器性能。如果中间报错找不到libelf、openssl头文件之类的，执行：

sudo apt install libelf-dev libssl-dev

再重新编译即可。

4.3 用busybox制作最小rootfs和initramfs

Linux内核起来后，必须挂载一个根文件系统，里面至少要有/init这个程序。对于QEMU快速验证场景，initramfs是最简单的选择，它会被内核直接解压到内存中作为临时的根文件系统，不需要模拟块设备，也不需要SD卡镜像。

用busybox来生成用户态工具：

git clone https://github.com/mirror/busybox.git cd busybox make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- defconfig make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- menuconfig

在menuconfig里一定要做一件事：进入Settings，把Build static binary (no shared libs)勾上。这一步非常关键，busybox默认是动态链接的，生成的二进制需要glibc的动态库；如果把它放到initramfs里，但initramfs里没有glibc的.so文件，内核启动后就会报/init: not found。

编译安装：

make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- -j$(nproc) make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- install

所有的binaries会装到_install目录下。现在给它补一个init脚本：

cd _install cat > init << 'EOF' #!/bin/sh mount -t proc proc /proc mount -t sysfs sysfs /sys echo "Welcome to RISC-V Linux!" exec /bin/sh EOF chmod +x init

最后打包成cpio格式的initramfs：

find . | cpio -o -H newc | gzip > ../rootfs.cpio.gz

4.4 在QEMU上启动Linux

现在内核和initramfs都准备好了，用下列命令启动：

qemu-system-riscv64 \ -machine virt \ -nographic \ -m 1G \ -bios default \ -kernel Image \ -initrd rootfs.cpio.gz \ -append "console=ttyS0 rdinit=/sbin/init"

参数解释一下：

• -machine virt：选择QEMU内置的riscv virt板卡。
• -nographic：把串口重定向到当前终端，不需要额外开终端窗口。
• -bios default：使用QEMU默认的OpenSBI固件。
• -kernel Image：指定Linux内核镜像。
• -initrd rootfs.cpio.gz：指定initramfs。
• -append "console=ttyS0 rdinit=/sbin/init"：内核命令行参数，console指定控制台串口设备，rdinit指定initramfs中的init程序路径。

启动后你会看到OpenSBI的启动信息，然后是一大段Linux内核日志，最后进入busybox的shell：

OpenSBI v1.2 ... Linux version 6.6.0 ... ... Welcome to RISC-V Linux! / #

到了/ #提示符，说明RISC-V上的Linux已经完全跑起来了。在这里你可以执行uname -a查看内核版本、cat /proc/cpuinfo查看RISC-V硬件信息、free查看内存使用。

如果想要完整的磁盘文件系统，可以用buildroot一键生成根文件系统镜像，或者用debootstrap制作Debian的rootfs，但那是后话。这篇文章里的initramfs方案，足够你在几分钟内验证内核能不能跑，以及后续做驱动开发测试了。

5. 双系统协作：同一块RISC-V芯片上Zephyr和Linux怎么分工

5.1 为什么实际产品需要同时存在两个系统

很多人会有疑问：Zephyr能跑实时任务，Linux能跑复杂应用，为什么不能只用一个？答案在于二者的资源消耗和实时性差距太大。

Zephyr的中断响应延迟可以做到微秒级，而且整个内核镜像只有几十KB。但它没有进程隔离，一个驱动的野指针就能把整个系统打挂；文件系统、网络协议栈虽然也有，但性能和功能都比Linux差得远。

Linux的优势在于生态，各种中间件、容器、调试工具、远程管理框架全都现成。但Linux的调度延迟受内核抢占、缓存命中、DMA竞争等因素影响，很难保证硬实时。

实际产品里最常见的设计是：一颗带多个RISC-V核的SoC，核0跑Linux负责业务逻辑、网络通信、用户界面，核1跑Zephyr负责电机控制、传感器采集、高速IO。两个核之间通过共享内存或者Mailbox通信，各干各的活，互不干扰。这种设计在工业控制器、机器人、边缘网关里越来越多，也被称为AMP（非对称多处理）架构。

5.2 在QEMU里搭建AMP环境的思路

QEMU目前对AMP的模拟是通过-smp参数来指定CPU核心数的，比如：

qemu-system-riscv64 -machine virt -smp 4 -m 2G ...

但QEMU默认情况下每个核跑的都是同一个固件，要实现Zephyr跑核0、Linux跑核1，还需要在软件层面做区分，通常做法是：

1. 用一个最小的bootloader在核0上启动Zephyr。
2. 在Zephyr的启动代码里判断当前核ID，如果是核0则进入RTOS调度，如果是核1则跳转到Linux内核入口。
3. 两个系统通过共享一块物理内存区域进行通信。

这个方案在真实芯片上已经很成熟了，比如Xilinx的Zynq UltraScale+里常见的“Linux+FreeRTOS”AMP方案就是这个套路。RISC-V的Hart（硬件线程，相当于CPU核）调度机制天然支持这种模式，每个核独立执行不同程序。

不过在QEMU上做完整AMP比较折腾，因为QEMU对核间中断的模拟和真实芯片有差异。如果你想快速验证，一个变通方案是在同一台主机上开两个QEMU进程，一个跑Linux、一个跑Zephyr，然后用宿主机的socket或者共享文件夹模拟核间通信。这种方式虽然不是严格的AMP，但用来验证通信协议和业务逻辑已经足够。

5.3 Zephyr引导Linux的过渡方案

有些团队会考虑：同一个核上，先让Zephyr起来做快速硬件初始化，再跳转到Linux，实现快速启动。这个思路在消费电子里很常见，先用RTOS起一个极简界面，让用户看到屏幕亮了，后台再慢慢引导完整的Linux系统。

实现原理不复杂。Zephyr在M模式运行，Linux在S模式运行。Zephyr初始化完DDR、PMIC、显示等外设后，调用SBI的hart_start接口唤醒Linux核，然后把控制权交给OpenSBI，OpenSBI再跳转到Linux。这里面的关键是：

1. Zephyr在跳转前要把当前模式从M模式切换到S模式，通常用mret指令结合medeleg/mideleg委派配置完成。
2. 跳转地址必须是Linux内核入口，也就是Image的启动地址。
3. 要给Linux预留足够的干净内存空间，Zephyr使用的内存区域要报告给Linux，避免内核把它当普通内存使用。

这个方案我在实验板上验证过，Zephyr从上电到点亮LCD大约300毫秒，比Linux从bootloader开始启动快了将近3秒，用户体验提升非常明显。如果你做的是带屏的产品，这个思路值得认真研究。

6. 实操中绕不开的坑：问题排查与调试技巧

6.1 编译期的常见错误

问题：Zephyr编译时提示找不到riscv工具链

这通常是因为Zephyr SDK没有正确配置环境变量。处理方式很简单，确认~/.bashrc里的source路径写对了，然后重新开一个终端窗口让配置生效。如果用的是apt的交叉编译器，需要在构建时显式指定：

west build -b qemu_riscv32 -p always samples/hello_world \ --sysroot /usr/riscv64-linux-gnu \ -DCROSS_COMPILE=riscv64-linux-gnu-

不过我个人还是建议直接用Zephyr SDK，省心很多。

问题：编译Linux内核时报fatal error: openssl/bio.h: No such file

RISC-V内核的x509证书管理和MODULE_SIG功能依赖OpenSSL头文件。直接安装：

sudo apt install libssl-dev

然后清理再编译。

6.2 运行期的排查速查表

现象	可能原因	处理办法
QEMU启动后没有任何输出	QEMU命令缺少-nographic，或console参数不对	加上-nographic，确认console=ttyS0
Zephyr在west build -t run后卡死	板子选择错误，或内存配置过大	换qemu_riscv32/qemu_riscv64，检查board config
Linux启动后停在Starting kernel ...	OpenSBI跳转地址错误，或Image格式不匹配	确认使用-kernel Image而非-kernel vmlinux
内核报/init: not found	busybox不是静态编译，或init路径不对	检查Busybox Settings -> Build static binary，确认init脚本可执行
initramfs解压失败	cpio格式不对	确保用-H newc格式打包，内核支持CONFIG_BLK_DEV_INITRD
QEMU运行很卡	内存不足或未启用KVM	RISC-V的QEMU在x86上无法用KVM，只能靠TCG模拟，可降低-smp核数

6.3 用GDB单步调试Zephyr和Linux

QEMU内置了GDB Server支持，这使得在模拟器里做指令级调试非常顺手，比在真板上调方便太多。

调试Zephyr时，先让QEMU等待GDB连接：

qemu-system-riscv32 -machine virt -nographic -kernel build/zephyr/zephyr.elf -s -S

-s表示在本地1234端口开放GDB Server，-S表示启动后暂停CPU，等待调试器连接。然后开另一个终端：

riscv64-unknown-elf-gdb build/zephyr/zephyr.elf (gdb) target remote localhost:1234 (gdb) continue

这时Zephyr开始运行，你随时可以用Ctrl+C停下来，单步执行，查看寄存器状态。调试Linux内核也一样，只是加载的镜像换成了vmlinux这个未压缩的内核文件，并用riscv64-linux-gnu-gdb来调试。

这个调试手段的价值在于：当你的驱动在真板上跑死机时，用QEMU可以轻松打断点看现场，快速定位是寄存器配置错了还是中断处理流程有bug，然后带着结论去真板验证，效率会高很多。

6.4 开发流程的终极建议

最后分享一点个人经验。很多初学者喜欢一上来就买开发板，然后被交叉工具链、烧录器、调试器一堆问题劝退。我的建议是：先用QEMU把Zephyr和Linux的构建、烧录、调试这条完整链路跑通，对RISC-V的启动过程、内存映射、设备树有了体感之后，再入手硬件板卡。到那时你会发现，真板上遇到的问题大多是电源时序、时钟配置、引脚复用这些硬件层面的差异，软件流程早就了然于胸了。

RISC-V的魅力就在于指令集简单、开源透明，从RTOS到完整Linux都能在这一套架构上学习和实践。这篇文章里的所有操作，我已经用最新的Zephyr 3.7和Linux 6.6在Ubuntu 22.04上完整跑了一遍，你可以放心照着做。真遇到这里没覆盖到的问题，多看看docs.zephyrproject.org和内核的Documentation/riscv目录，官方文档永远是最好的老师。