4、QEMU系统仿真：模拟ARM、RISC-V等开发板，外设建模与设备树

QEMU 系统仿真（System Emulation）是嵌入式软件开发中不可或缺的基础设施。与用户态仿真（User-Mode Emulation）仅模拟单个进程不同，系统仿真会完整地虚拟化一台计算机：包括 CPU 核心、内存控制器、中断控制器、定时器、UART、GPIO、DMA 以及各类总线。本章将深入剖析 QEMU 如何模拟 ARM 与 RISC-V 开发板，重点讲解外设建模的机制、设备树（Device Tree）在仿真中的角色，以及如何基于 QEMU 构建高效的嵌入式虚拟开发环境。

上图展示了 QEMU 系统仿真的整体架构。从底层看，QEMU 通过 TCG（Tiny Code Generator）或 KVM 加速执行客户机指令；从上层看，它通过一组用 C 语言编写的设备模型（Device Model）来模拟开发板上的外设。设备树（Device Tree）则充当了“硬件描述语言”的角色，将板级细节从内核中剥离出来，使得同一份内核镜像可以运行在 QEMU 模拟的多种开发板上。下面我们将从三个维度展开：开发板模拟方法、外设建模实战、设备树适配与调试。

4.1 开发板模拟：从 vexpress-a9 到 virt 与 sifive_u

QEMU 支持数十种 ARM 和 RISC-V 开发板。选择哪种机器类型（Machine Type）直接决定了后续的调试体验和性能表现。对于 ARM 平台，最经典的是 vexpress-a9（对应 Versatile Express 开发板，Cortex-A9 双核），而 virt 是 QEMU 为虚拟化专门设计的通用平台，它不模拟具体硬件厂商的 SoC，而是提供一套简洁、高效的总线结构（GPEX PCIe 主机桥、PL011 UART、GICv2/v3 中断控制器）。对于 RISC-V，sifive_u 模拟了 SiFive 的 Unleashed 开发板（FE310 或 U54 内核），而 virt 同样提供了 RISC-V 版本。

选择机器类型时，需要关注三个关键点：中断控制器模型（ARM 的 GIC 版本、RISC-V 的 PLIC/CLINT）、内存映射基址（决定内核解压地址和设备树中 reg 属性）、默认固件加载方式（是直接加载内核还是通过 U-Boot）。例如，vexpress-a9 使用 GIC-400，而 virt 默认使用 GICv3，这会影响 Linux 内核中中断驱动的初始化路径。

qemu-system-aarch64 \
  -machine virt,virtualization=on \
  -cpu cortex-a72 \
  -smp 4 \
  -m 4G \
  -kernel Image \
  -dtb virt.dtb \
  -drive file=rootfs.ext4,format=raw,if=virtio \
  -append "root=/dev/vda rw console=ttyAMA0" \
  -netdev user,id=net0 -device virtio-net-pci,netdev=net0 \
  -nographic

上述命令中，-machine virt,virtualization=on 开启了虚拟化扩展（用于 KVM 嵌套或 EL2 调试），-cpu cortex-a72 指定 CPU 型号，-dtb 显式加载设备树二进制文件。如果不指定 -dtb，QEMU 会自动生成一份与机器类型匹配的设备树。

4.2 外设建模：QOM 框架与 MemoryRegion 核心

QEMU 的外设建模基于 QOM（QEMU Object Model）和 MemoryRegion 两大基础设施。QOM 负责设备对象的生命周期管理、属性继承和父子关系；MemoryRegion 则负责地址空间映射和读写回调。一个典型的外设模型（例如 PL011 UART）需要实现以下步骤：

1. 定义 TypeInfo：声明设备名称、实例大小、父类（通常是 SysBusDevice）。
2. 实现 realize 函数：在该函数中创建 MemoryRegion，并将其映射到系统总线（SysBus）的地址空间。
3. 实现读写回调：read 和 write 函数模拟寄存器行为，例如 UART 的 DR（数据寄存器）和 FR（标志寄存器）。
4. 连接中断：通过 qdev_connect_gpio_out 将设备的中断输出连接到 GIC 的输入。

以 PL011 为例，其寄存器偏移量是固定的：DR 位于偏移 0x000，FR 位于偏移 0x018。QEMU 的 pl011.c 中通过一个静态数组 pl011_reg_ops[] 定义了每个寄存器的读写行为。当 Guest 访问 0x09000000（vexpress 平台上 PL011 的基址）时，QEMU 的 MemoryRegion 查找机制会找到对应的设备模型，并调用其回调函数。

4.3 设备树（Device Tree）在仿真中的角色与适配

设备树是连接 QEMU 设备模型与 Guest Linux 内核的桥梁。QEMU 在启动时根据机器类型生成 DTB（Device Tree Blob），其中包含 CPU 节点、内存节点、中断控制器节点以及每个外设的节点。每个节点必须包含 compatible 属性（用于内核驱动匹配）、reg 属性（基址和大小）以及 interrupts 属性（中断号）。

对于自定义外设，我们需要在 QEMU 的机器初始化代码中手动添加设备树节点。例如，在 virt.c 中，通过 qemu_fdt_add_subnode 和 qemu_fdt_setprop_cell 函数创建节点。以下是一个给 virt 平台添加自定义 GPIO 控制器的代码片段：

// 在 virt.c 的 machvirt_init 函数中
if (machine->device_tree) {
    // 假设外设基址为 0x0C000000，中断号为 128
    char *nodename = g_strdup_printf("/gpio@%x", 0x0C000000);
    qemu_fdt_add_subnode(machine->fdt, nodename);
    qemu_fdt_setprop_string(machine->fdt, nodename, "compatible", "myvendor,gpio-ctrl");
    qemu_fdt_setprop_cells(machine->fdt, nodename, "reg", 0x0C000000, 0x1000);
    qemu_fdt_setprop_cells(machine->fdt, nodename, "interrupts", 128);
    qemu_fdt_setprop(machine->fdt, nodename, "gpio-controller", NULL, 0);
    g_free(nodename);
}

在 Guest Linux 内核中，对应的驱动程序通过 of_match_table 匹配 compatible 字符串，然后使用 platform_get_resource 获取寄存器地址，使用 platform_get_irq 获取中断号。这种机制使得内核代码与具体硬件地址解耦，便于在 QEMU 和真实硬件之间无缝切换。

4.4 案例拆解：在 QEMU 上为 RISC-V 开发板添加虚拟传感器外设

下面我们通过一个完整案例，演示如何为 RISC-V virt 机器添加一个温度传感器外设，并让 Linux 内核驱动成功识别。该案例覆盖了 QEMU 设备建模、设备树修改和内核驱动验证三个环节。

背景与目标：假设我们需要在虚拟环境中验证一个温度监控应用。真实硬件上传感器挂接在 I2C 总线上，但为了简化，我们将其建模为内存映射设备，基址为 0x0C001000，中断号为 0x2B（43）。设备提供两个寄存器：0x00 为温度数据寄存器（只读，单位 0.1°C），0x04 为控制寄存器（写 1 启动转换）。

QEMU 设备模型实现（C 语言核心逻辑）：

// virt_sensor.c (简化)
static uint64_t sensor_read(void *opaque, hwaddr offset, unsigned size) {
    VirtSensorState *s = opaque;
    switch (offset) {
    case 0x00: return s->temperature; // 例如 250 表示 25.0°C
    case 0x04: return s->ctrl;
    default: return 0;
    }
}
static void sensor_write(void *opaque, hwaddr offset, uint64_t value, unsigned size) {
    VirtSensorState *s = opaque;
    if (offset == 0x04 && value & 1) {
        s->temperature = 250 + (rand() % 50); // 模拟温度波动
    }
}
static void sensor_realize(DeviceState *dev, Error **errp) {
    VirtSensorState *s = VIRT_SENSOR(dev);
    memory_region_init_io(&s->iomem, OBJECT(dev), &sensor_ops, s, "virt-sensor", 0x1000);
    sysbus_init_mmio(SYS_BUS_DEVICE(dev), &s->iomem);
    sysbus_init_irq(SYS_BUS_DEVICE(dev), &s->irq);
    // 连接中断到 PLIC (RISC-V 中断控制器)
    qdev_connect_gpio_out(dev, 0, plic_irq);
}

设备树修改：在 virt.c 的 RISC-V 机器初始化中，添加如下节点：

qemu_fdt_add_subnode(fdt, "/sensor@0c001000");
qemu_fdt_setprop_string(fdt, "/sensor@0c001000", "compatible", "virt,sensor");
qemu_fdt_setprop_cells(fdt, "/sensor@0c001000", "reg", 0x0c001000, 0x1000);
qemu_fdt_setprop_cells(fdt, "/sensor@0c001000", "interrupts", 43);

内核驱动验证：在 Linux 内核中编写一个简单的字符设备驱动，通过 ioremap 映射寄存器，读取温度值。启动 QEMU 后，在 Guest 中执行 cat /sys/devices/platform/soc/sensor@0c001000/temp，应输出类似 26.3 的温度值。

4.5 常见误区与调试方法

在 QEMU 系统仿真中，开发者常遇到以下问题：

一个高效的调试流程是：首先在 QEMU monitor 中使用 info qtree 查看设备树模型，确认设备是否被实例化；然后使用 xp 命令直接访问 Guest 物理地址，验证读写行为；最后结合 Guest 内核的 dmesg 输出定位驱动问题。