Ivan's wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# QEMU Machine Types

**Machine type (`-M`) selects the emulated board**, determining CPU architecture, memory map, available peripherals, and which devices are accessible. Different boards have different capabilities.

```bash
qemu-system-arm -M versatilepb -kernel Image      # ARM Versatile PB
qemu-system-arm -M virt -kernel Image             # Generic virtual machine
qemu-system-riscv64 -M virt -kernel Image         # RISC-V virtual machine
qemu-system-arm -M raspi2                         # Raspberry Pi 2 (partial)
```

**Versatile** (`versatilepb`) is the classic choice for ARM cross-compilation testing. Well-supported, stable, and includes UART, timer, and interrupt controller. Good for kernel and bootloader testing.

**Virt** is a generic virtual machine for each architecture (ARM, AARCH64, RISC-V). Defined by QEMU rather than mimicking real hardware. Simplest for testing OS kernels; no need to model real board quirks. Recommended for new projects.

**Raspi2** emulates Raspberry Pi 2 hardware. Partial support means some peripherals work, others don't. Useful for Raspberry Pi-specific testing but slower and less stable than `virt`.

List available machines:

```bash
qemu-system-arm -M help       # all ARM boards
qemu-system-riscv64 -M help   # all RISC-V boards
```

Each machine defines:

- CPU type(s) and count
- RAM size and address space
- Peripherals (UART, timer, interrupt controller, SPI, I2C, etc.)
- Device tree (if applicable)
- Clocks and power domains

For cross-compilation testing, choose based on your target board. If exact hardware isn't available in QEMU, use `virt` instead—it's close enough for driver and kernel testing.

The device tree (`.dtb` file) depends on the machine type. A `versatilepb.dtb` won't work on a `virt` machine and vice versa. Always use the matching `.dtb` for the `-M` board you select.