Difference between revisions of "QEMU"
m (Add QEMU OMAP3 and BeagleBoard link) |
(Correct the guide to build the cpio.gz image) |
||
(22 intermediate revisions by 10 users not shown) | |||
Line 3: | Line 3: | ||
QEMU is a generic and open source machine emulator and virtualizer, originally developed by Fabrice Bellard. | QEMU is a generic and open source machine emulator and virtualizer, originally developed by Fabrice Bellard. | ||
− | When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good | + | When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance. |
− | When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. | + | When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. Host KVM support is utilized in this case. The virtualizer mode requires that both the host and guest machine use the same instruction set. |
− | [http://www.qemu.org | + | [http://www.qemu.org QEMU project web site] |
+ | |||
+ | = Use in embedded projects = | ||
+ | QEMU is increasingly used to provide an emulator for embedded processors, for testing embedded Linux without the need for actual hardware. | ||
+ | |||
+ | The [http://free-electrons.com/docs/elfs/ Embedded Linux From Scratch] presentation by Michael Opdenacker has great information about setting up QEMU with embedded Linux. | ||
+ | |||
+ | Also, [http://landley.net/aboriginal/ Aboriginal Linux] uses QEMU as part of a "native" build environment to eliminate cross-compilation problems. | ||
= Supported architectures = | = Supported architectures = | ||
Line 13: | Line 20: | ||
The following architectures are supported as target architectures for system emulation: | The following architectures are supported as target architectures for system emulation: | ||
− | * x86 | + | * [https://wiki.qemu.org/Documentation/Platforms/PC x86] |
− | * | + | * [https://wiki.qemu.org/Documentation/Platforms/ARM ARM and AArch64] ("Virt", ARM Integrator/CP, ARM Versatile, ARM Realview, X-Scale based PDAs, Palm Tungsten, Nokia N800/N810 tablets, Luminary boards, RPI, Zynq, etc.) |
− | * | + | * [https://wiki.qemu.org/Documentation/Platforms/SPARC Sparc32 and Sparc64] |
− | * PowerPC | + | * [https://wiki.qemu.org/Documentation/Platforms/PowerPC PowerPC] |
− | * MIPS | + | * [https://wiki.qemu.org/Documentation/Platforms/MIPS MIPS] |
− | * | + | * [https://wiki.qemu.org/Documentation/Platforms/RISCV RISC-V] |
+ | |||
+ | Support for new boards or new peripherals can added relatively easily in QEMU, the APIs being quite simple to understand and use. | ||
= Resources = | = Resources = | ||
+ | * [https://wiki.qemu.org/Documentation QEMU Emulator User Documentation] | ||
+ | * [https://wiki.qemu.org/Documentation#Technical_Documentation QEMU Internals] | ||
+ | * [http://tuxology.net/2008/12/14/embedded-emulator/ Building an embedded Linux system emulator using QEMU] | ||
+ | * [http://vm-kernel.org/blog/2008/12/15/linux-is-running-on-qemu-omap3/ QEMU for OMAP3] ([[BeagleBoard]]) | ||
+ | * [[QEMUonARM|QEMU on ARM]] | ||
+ | * [http://cronicasredux.blogspot.co.uk/2011/09/installing-and-running-debian-armel-on.html QEMU for the Raspberry Pi] - also see [http://www.raspberrypi.org/forum/projects-and-collaboration-general/emulating-a-raspi-on-windows discussion] | ||
+ | |||
+ | = Some quick useful tips = | ||
+ | == How to populate a minimal sysroot == | ||
+ | Here are the steps to populate a minimal sysroot, assuming you Busybox built on your host, for the target architecture: | ||
+ | cd busybox | ||
+ | mkdir _install/proc _install/sys _install/dev _install/etc _install/etc/init.d | ||
+ | cat > _install/etc/init.d/rcS << EOF | ||
+ | #!/bin/sh | ||
+ | mount -t proc none /proc | ||
+ | mount -t sysfs none /sys | ||
+ | /sbin/mdev -s | ||
+ | [ ! -h /etc/mtab ] && ln -s /proc/mounts /etc/mtab | ||
+ | [ ! -f /etc/resolv.conf ] && cat /proc/net/pnp > /etc/resolv.conf | ||
+ | EOF | ||
+ | chmod +x _install/etc/init.d/rcS | ||
+ | |||
+ | == How to build a cpio.gz ramfs == | ||
+ | Here are the steps for building a cpio.gz ramfs image, assuming you Busybox built on your host, for the target architecture: | ||
+ | mkdir _rootfs | ||
+ | rsync -a _install/ _rootfs | ||
+ | chown -R root:root _rootfs | ||
+ | cd _rootfs | ||
+ | find . | cpio -o --format=newc > ../rootfs.cpio | ||
+ | cd .. | ||
+ | gzip -c rootfs.cpio > rootfs.cpio.gz | ||
+ | |||
+ | Then the image built can be booted with the following command: | ||
+ | qemu-system-aarch64 -nographic -no-reboot -machine virt -cpu cortex-a57 -smp 2 -m 256 -kernel Image -initrd rootfs.cpio.gz -append "panic=5 ro ip=dhcp root=/dev/ram rdinit=/sbin/init" | ||
+ | |||
+ | == How to build a Ext3 rootfs == | ||
+ | Here are the steps for building a Ext3 rootfs image, assuming you Busybox built on your host, for the target architecture: | ||
+ | dd if=/dev/zero of=rootfs.img bs=1M count=10 | ||
+ | mke2fs -j rootfs.img | ||
+ | mkdir /mnt/rootfs | ||
+ | mount -o loop rootfs.img /mnt/rootfs | ||
+ | rsync -a _install/ /mnt/rootfs | ||
+ | chown -R root:root /mnt/rootfs/ | ||
+ | sync | ||
+ | umount /mnt/rootfs/ | ||
+ | |||
+ | Then the image built can be booted with the following command: | ||
+ | qemu-system-aarch64 -nographic -no-reboot -machine virt -cpu cortex-a57 -smp 2 -m 256 -kernel Image -append "panic=5 ro ip=dhcp root=/dev/vda" -drive file=rootfs.img,format=raw,if=none,id=hd0 -device virtio-blk-device,drive=hd0 | ||
+ | |||
+ | == Some sample command lines == | ||
+ | |||
+ | |||
+ | I got these from Rob Landley at OLS 2008: | ||
+ | |||
+ | qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda" -nographic | ||
+ | |||
+ | qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda init=/bin/ash" -nographic | ||
− | + | qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda panic=1" -nographic -no-reboot | |
− | + | ||
− | + | killall qemu-system-x86 | |
− | + | ||
+ | === Interesting options === | ||
+ | * -kernel <file> = specify the kernel image to use for booting | ||
+ | * -hda <file> = specify | ||
+ | * -nographic = don't use graphics, and redirect serial I/O to console | ||
+ | * -no-reboot = exit instead of rebooting | ||
+ | |||
+ | == Resize filesystem image == | ||
+ | Not enough space to install anything after you're up and running? Here's how to resize the image. | ||
+ | |||
+ | Host: qemu-img resize rootfs_debian6_rpi.ext4 +1G | ||
+ | QEMU: sudo resize2fs /dev/sda // Be careful not to run this on your host machine | ||
+ | |||
+ | The online resize2fs may corrupt the filesystem so here's an alternative. | ||
+ | [http://www.cnx-software.com/2012/03/08/instructions-to-run-raspberry-pi-fedora-14-remix-in-qemu/#comment-6900 resize using loopback device] | ||
+ | |||
+ | [[Category:QEMU]] |
Latest revision as of 09:15, 30 November 2020
Contents
Introduction
QEMU is a generic and open source machine emulator and virtualizer, originally developed by Fabrice Bellard.
When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance.
When used as a virtualizer, QEMU achieves near native performances by executing the guest code directly on the host CPU. Host KVM support is utilized in this case. The virtualizer mode requires that both the host and guest machine use the same instruction set.
Use in embedded projects
QEMU is increasingly used to provide an emulator for embedded processors, for testing embedded Linux without the need for actual hardware.
The Embedded Linux From Scratch presentation by Michael Opdenacker has great information about setting up QEMU with embedded Linux.
Also, Aboriginal Linux uses QEMU as part of a "native" build environment to eliminate cross-compilation problems.
Supported architectures
The following architectures are supported as target architectures for system emulation:
- x86
- ARM and AArch64 ("Virt", ARM Integrator/CP, ARM Versatile, ARM Realview, X-Scale based PDAs, Palm Tungsten, Nokia N800/N810 tablets, Luminary boards, RPI, Zynq, etc.)
- Sparc32 and Sparc64
- PowerPC
- MIPS
- RISC-V
Support for new boards or new peripherals can added relatively easily in QEMU, the APIs being quite simple to understand and use.
Resources
- QEMU Emulator User Documentation
- QEMU Internals
- Building an embedded Linux system emulator using QEMU
- QEMU for OMAP3 (BeagleBoard)
- QEMU on ARM
- QEMU for the Raspberry Pi - also see discussion
Some quick useful tips
How to populate a minimal sysroot
Here are the steps to populate a minimal sysroot, assuming you Busybox built on your host, for the target architecture:
cd busybox mkdir _install/proc _install/sys _install/dev _install/etc _install/etc/init.d cat > _install/etc/init.d/rcS << EOF #!/bin/sh mount -t proc none /proc mount -t sysfs none /sys /sbin/mdev -s [ ! -h /etc/mtab ] && ln -s /proc/mounts /etc/mtab [ ! -f /etc/resolv.conf ] && cat /proc/net/pnp > /etc/resolv.conf EOF chmod +x _install/etc/init.d/rcS
How to build a cpio.gz ramfs
Here are the steps for building a cpio.gz ramfs image, assuming you Busybox built on your host, for the target architecture:
mkdir _rootfs rsync -a _install/ _rootfs chown -R root:root _rootfs cd _rootfs find . | cpio -o --format=newc > ../rootfs.cpio cd .. gzip -c rootfs.cpio > rootfs.cpio.gz
Then the image built can be booted with the following command:
qemu-system-aarch64 -nographic -no-reboot -machine virt -cpu cortex-a57 -smp 2 -m 256 -kernel Image -initrd rootfs.cpio.gz -append "panic=5 ro ip=dhcp root=/dev/ram rdinit=/sbin/init"
How to build a Ext3 rootfs
Here are the steps for building a Ext3 rootfs image, assuming you Busybox built on your host, for the target architecture:
dd if=/dev/zero of=rootfs.img bs=1M count=10 mke2fs -j rootfs.img mkdir /mnt/rootfs mount -o loop rootfs.img /mnt/rootfs rsync -a _install/ /mnt/rootfs chown -R root:root /mnt/rootfs/ sync umount /mnt/rootfs/
Then the image built can be booted with the following command:
qemu-system-aarch64 -nographic -no-reboot -machine virt -cpu cortex-a57 -smp 2 -m 256 -kernel Image -append "panic=5 ro ip=dhcp root=/dev/vda" -drive file=rootfs.img,format=raw,if=none,id=hd0 -device virtio-blk-device,drive=hd0
Some sample command lines
I got these from Rob Landley at OLS 2008:
qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda" -nographic
qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda init=/bin/ash" -nographic
qemu-system-x86 -kernel linux-2.6.26/arch/i386/boot/bzImage -hda rootfs.img -append "console=ttyS0 root=/dev/hda panic=1" -nographic -no-reboot
killall qemu-system-x86
Interesting options
- -kernel <file> = specify the kernel image to use for booting
- -hda <file> = specify
- -nographic = don't use graphics, and redirect serial I/O to console
- -no-reboot = exit instead of rebooting
Resize filesystem image
Not enough space to install anything after you're up and running? Here's how to resize the image.
Host: qemu-img resize rootfs_debian6_rpi.ext4 +1G QEMU: sudo resize2fs /dev/sda // Be careful not to run this on your host machine
The online resize2fs may corrupt the filesystem so here's an alternative. resize using loopback device