I want to emulate Raspberry Pi 4 using QEMU, but I am not able to find any image for RPi4. I need a kernel with which QEMU can emulate a Cortex-A72.
QEMU does not have a model of the raspberry pi 4 at this time (only the 0, 1ap, 2b, 3ap and 3b). If some other machine type that QEMU does support would be good enough for you you could build a kernel for that machine type and use that. (For instance, for a lot of people all they really want is "boots a 64-bit Linux userspace" and they don't need it to really exactly match the Raspberry Pi board hardware; for those people the 'virt' board is usually a good choice.)
Whatever you do, you need to make sure that the machine type you ask QEMU to emulate matches the machine type you've built the kernel for -- if you try to boot a kernel on a board that it does not support it will not work.
I just boot raspios bullseye on a x86 ubuntu laptop, it can show the desktop, can be login in. But it's very slow.
qemu-system-aarch64 -M virt,highmem=off -smp 8 -m 2G -cpu cortex-a72 -kernel linux-stable/arch/arm64/boot/Image -append root=PARTUUID=d97f5830-02 rw console=ttyAMA0 -serial telnet:localhost:4321,server,nowait -monitor telnet:localhost:4322,server,nowait -device VGA,id=vga1 -device secondary-vga,id=vga2 -object iothread,id=io1 -device virtio-blk-pci,drive=disk0,iothread=io1 -drive data/images/2022-01-28-raspios-bullseye-arm64.img
I build the kernel image follow this guide.
https://github.com/anholt/linux/wiki/Raspberry-Pi-development-environment#building-the-Kernel
Of course, as the raspios is emulated on the x86 laptop, it's definitely slow. So, if you can virtualize it on an arm64 host, you can use the accelerator like kvm, hvf etc.
qemu-system-aarch64 \
-M virt,highmem=off,accel=hvf \
-cpu host \
-m 1G \
-smp 4 \
-kernel $KERNEL_IMAGE_PATH -append "root=/dev/vda2 rw console=ttyAMA0" \
-netdev user,id=n1,ipv6=off,hostfwd=tcp::5555-:22 -device e1000,netdev=n1 \
-hda data/images/2022-01-28-raspios-bullseye-arm64.img \
-serial telnet:localhost:4321,server,nowait \
-monitor telnet:localhost:4322,server,nowait \
-device VGA,id=vga2 \
-drive file=data/images/2021-10-30-raspios-bullseye-armhf.img,if=virtio
there is a patch here if you want.
You can compile qemu with raspi4b2g
(Patch not from me)
https://github.com/0xMirasio/qemu-patch-raspberry4.git
or try the following branch (2019), which may or maynot be patch equivalent to that already mentioned:
https://gitlab.com/philmd/qemu/-/tree/raspi4_wip
Related
I am emulating an aarch64 platform using qemu. I have successfully installed ubuntu server for arm64 (16.04 LTS). I want to enable machine graphics for the 'virt' machine type. I have followed the instructions here. However, that does not work.
Apart from the graphics, all else works. Also, I have installed mint desktop on the Ubuntu installation. All I require is the graphics display, please.
Here's my code:
qemu-system-aarch64 -cpu cortex-a53 -M virt -m 2048 -device virtio-gpu-pci -device virtio-blk-device,drive=hd0 -drive if=pflash,format=raw,file=QEMU_EFI.img -drive if=pflash,file=varstore.img -drive if=none,file=ubuntu.img,id=hd0
When I run this, I get a virtio-gpu display but once the bios loads, it shows "Guest disabled display". Could you please point me to what's wrong? Thanks.
Same issue on Ubuntu 20.04 host with Ubuntu 20.04 image.
But there is no such issue with CentOS 8 image which can be find here https://cloud.centos.org/centos/8/aarch64/images/
So it can be related to image software or settings.
You can access running VM via virsh console vmName to try change something inside VM.
And also it can be a bug in QEMU :-) - https://bugzilla.redhat.com/show_bug.cgi?id=1661288
you can perhap's try multiple video devices, and after boot select them in the view menu
qemu-system-aarch64 -machine virt -smp 8 -m 4G -cpu cortex-a72 -serial stdio -bios /usr/share/edk2/aarch64/QEMU_EFI.fd -drive if=none,file=./Mageia-8-rpi-aarch64-noDE.img,format=raw,id=hd -device qemu-xhci -device usb-storage,drive=hd -boot menu=on -device qxl -display gtk,gl=on -device virtio-gpu-pci -writeconfig rpi4
I use the openocd script below to dump the flash memory of a STM32 microcontroller.
mkdir -p dump
openocd -f board/stm3241g_eval_stlink.cfg \
\
-c "init" \
-c "reset halt" \
-c "dump_image dump/image.bin 0x08000000 0x100000" \
-c "shutdown" \
FILENAME=dump/image.bin
FILESIZE=$(stat -c%s "$FILENAME")
echo "Size of $FILENAME = $FILESIZE bytes."
The script is supposed to read the whole memory which is 1MB in my case but it does it very rarely. Generally it stops reading the memory before the end.
Why can't I obtain 1MB each time I execute this script? What is the problem here to cause openocd stop dumping the rest of the memory?
You can use dfu-utils to reflash your STM32 micros.
In Ubuntu/Debian distros you can install dfu-utils with apt:
$ sudo apt-get install dfu-util
$ sudo apt-get install fwupd
Boot your board in DFU mode (check datasheet). Once in DFU mode, you should see something similar to this:
$ lsusb | grep DFU
Bus 003 Device 076: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
Once booted in DFU mode, reflash your binary:
$ sudo dfu-util -d 0483:df11 -a 0 -s 0x08000000:leave -D build/$(PROJECT).bin
With -d option you choose product:vendorid such as listed by lsusb in DFU mode.
With the -a 0 option you select alternate mode 0, check the options available as in the following example:
$ sudo dfu-util -l
Found DFU: [0483:df11] ver=2200, devnum=101, cfg=1, intf=0, alt=1, name="#Option Bytes /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=101, cfg=1, intf=0, alt=0, name="#Internal Flash /0x08000000/064*0002Kg", serial="FFFFFFFEFFFF"
As you can see, alt=0 is for internal flash memory.
With the -s option you specify the flash memory address where you save your binary. Check your memory map in datasheet.
Hope this helps! :-)
I am trying to emulate a Raspberry Pi zero W with Qemu based on an image I used on a real Raspberry Pi zero W.
The command I am using is:
sudo qemu-system-arm \
-kernel ./qemu-rpi-kernel/kernel-qemu-4.9.59-stretch \
-append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" \
-hda pi_zero_kinetic_raspbian.qcow \
-cpu arm1176 -m 512 \
-M versatilepb \
-no-reboot \
-serial stdio \
-net nic -net user \
-net tap,ifname=vnet0,script=no,downscript=no
But Qemu complain that Error: unrecognized/unsupported machine ID (r1 = 0x00000183)
So added this option:
-dtb linux/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
But In this case:
qemu-system-arm: Unable to copy device tree in memory
Couldn't open dtb file qemu-rpi-kernel/tools/linux/arch/arm/boot/dts/bcm2835-rpi-zero-w.dts
So I tried to compile the dts in order to get the dtb with:
dtc -O dtb -o bcm2835-rpi-zero-w.dtb bcm2835-rpi-zero-w.dts
But the compilation fail and I get:
Error: bcm2835-rpi-zero-w.dts:13.1-9 syntax error
FATAL ERROR: Unable to parse input tree
I couldn't find any tutorial about Pi zero and all the tutorial about the first Rapsberry Pi seems to be outdated. I am not sure that compiling the dtb on my own is the way to go.
Any input would be appreciated, thanks!
This isn't going to work, because the QEMU option "-M versatilepb" says "emulate a VersatilePB development board", which will not run a kernel that is intended to boot on the Pi Zero. The versatilepb board does not have devices in the places that a Pi Zero DTB file says they are, so if you provide the kernel with a Pi Zero DTB then the kernel is going to crash immediately because it can't find anything where it expects.
In general Arm devboards are not like x86 -- they are all different, and you can't just boot a kernel intended for one on a different one. This is in fact what the "unrecognized machine ID" error is telling you -- it's from the guest kernel, and it's saying "I can't boot on this board".
You need to either:
use -M versatilepb and pass QEMU a kernel and dtb intended for that machine, not some other one
use some other -M option and a kernel and dtb that work with it (for instance we support 'raspi2' now for a RaspberryPi 2 board model, with some notable caveats including "no USB, no networking")
Also, as you seem to have discovered, -dtb wants a DTB file (the compiled binary), not a DTS file (the source).
I want to configure the qemu to attach a specific block device to the VM?
Following is the command I am using now:
qemu-system-x86_64 -enable-kvm -machine type=pc,accel=kvm
-cpu host -nographic -k de -usb -m 2048
-net nic -net user,hostfwd=tcp::3388-:22
ubuntu16.04.qcow2
I know that following is the virsh command to do this:
virsh attach-disk ubuntuVM /dev/vdb
But I want to specify this in the above command line (Don't want to use virsh). Does anyone know how to do this?
Kind Regards
Simply add the following option to your command:
-drive file=/dev/sdd,format=raw,if=virtio
This will add a drive, the file parameter can also point to block devices, be sure to set the format parameter to "raw".
Additionally you can set the if parameter to "virtio" if the guest supports it (via module or driver) for better performance.
I am currently trying to cross-compile Qt 5.7 for my Raspberry Pi 3. This is my first cross-compiling atempt, so please be kind. :)
On the Qt Wiki I found instructions for the Raspberry Pi 2, which I am currently trying to adapt.
The compile line for RasPi 2 is as follows:
./configure -release -opengl es2 -device linux-rasp-pi2-g++ -device-option \
CROSS_COMPILE=~/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- \
-sysroot ~/raspi/sysroot -opensource -confirm-license -make libs \
-prefix /usr/local/qt5pi -extprefix ~/raspi/qt5pi -hostprefix ~/raspi/qt5 -v
I replaced the option
-device linux-rasp-pi2-g++
by
-device linux-rpi3-g++
as I found within the raspi-tools folder.
Now I am stuck at the option
CROSS_COMPILE=~/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-
as in the ~/raspi/tools/ folder I cannot see any obviously raspi3-related entry. There is only the arm-bcm2708/ folder. Shouldn't there be some bcm2837 entry? Does that mean there is no support for RasPi 3 yet or am I missing something?
Thank you for any hints.
After much struggle (the accepted solution does not work for me), I finally got to cross compile qt 5.6 for raspberry pi 3 on ubuntu.
You basically need to follow this well known how to. Just be sure to use the following configure:
./configure -release -opengl es2 -device linux-rpi3-g++
-device-option CROSS_COMPILE=~/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-
-sysroot ~/raspi/sysroot -prefix /usr/local/qt5pi -extprefix ~/raspi/qt5pi -hostprefix ~/raspi/qt5 -v -nomake examples -nomake
tests -no-use-gold-linker
The arm-bcm2708/ folder is just a name. It contains several build tool chains. It's perfectly fine to use system-installed tool chains as well. So I installed the package g++-arm-linux-gnueabihf on my build machine (Debian GNU/Linux) and used this configure call:
./configure -release -opengl es2 -device linux-rpi3-g++ \
-device-option CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- \
-sysroot /home/fs/raspi/sysroot -opensource -confirm-license \
-make libs -prefix /usr/local/qt5pi -extprefix /home/fs/raspi/qt5pi \
-hostprefix /home/fs/raspi/qt5 -v