qemu version is 7.1.0
I use qemu to simulate xlnx-zcu102. my qemu command is below, it can run OK:
./qemu-system-aarch64 -M xlnx-zcu102 -smp 4 -m 4G ......
but, when I add -device virtio-gpu or -device virtio-gpu-device,
(I added only one device: virtio-gpu)
qemu tell me ERROR like this:
qemu-system-aarch64: -device virtio-gpu: No 'PCI' bus found for device 'virtio-gpu-pci'
I don't know how to add a virtio-gpu device to xlnx-zcu102 in qemu command.
You can't add that device to that machine type. The xlnx-zcu102 machine type simulates a piece of real hardware that does not have a PCI bus, and so you cannot plug PCI devices into it. You need to either use a different machine type, or else not use virtio devices.
Related
I am trying to mount a drive image emulated as an SD card with qemu-system-x86_64.
qemu tells me that it is not supported by the machine type, can this really be true?
My command looks like this
sudo qemu-system-x86_64 -smp cores=4 -m 1024 -sd sdcard.qcow2 boot.img
WARNING: Image format was not specified for 'boot.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-x86_64: -sd sdcard.qcow2: machine type does not support if=sd,bus=0,unit=0
You need to add an SD controller:
qemu-system-x86_64 -smp cores=4 -m 1024 -device sdhci-pci -device sd-card,drive=mydrive -drive id=mydrive,if=none,format=raw,file=image.bin
Source
I tried:
git clone git://git.buildroot.net/buildroot
cd buildroot
git checkout 2019.08
make qemu_aarch64_virt_defconfig
make menuconfig
In menuconfig, I set:
Bootloaders
U-Boot configuration (Using an in-tree board defconfig file)
qemu_arm64
Kernel
Install kernel image to /boot in target
and finally:
make BR2_JLEVEL="$nproc"
Now, I can boot fine without U-Boot with the command line mentioned at: How to download the Torvalds Linux Kernel master, (re)compile it, and boot it with QEMU?
./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a57 -nographic -smp 1 -kernel output/images/Image -append "root=/dev/vda console=ttyAMA0" -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 -drive file=output/images/rootfs.ext4,if=none,format=raw,id=hd0 -device virtio-blk-device,drive=hd0
but that is not using U-Boot.
When I do:
ls -l output/images/
it contains:
-rw-r--r-- 1 ciro ciro 6.5M 2019-09-20_13:36:23 Image
-rw-r--r-- 1 ciro ciro 60M 2019-09-20_13:39:02 rootfs.ext2
lrwxrwxrwx 1 ciro ciro 11 2019-09-20_13:36:25 rootfs.ext4 -> rootfs.ext2
-rw-r--r-- 1 ciro ciro 583K 2019-09-20_13:34:15 u-boot.bin
so there is a U-Boot binary there: u-boot.bin, but how do I use that with QEMU?
I tried as mentioned at: Can ARM qemu system emulator boot from card image without kernel param? to remove -kernel and -append and add -bios u-boot.bin:
./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a57 -nographic -smp 1 -bios output/images/u-boot.bin -netdev user,id=eth0 -device virtio-net-device,netdev=eth0 -drive file=output/images/rootfs.ext4,if=none,format=raw,id=hd0 -device virtio-blk-device,drive=hd0
Now I do get the U-Boot shell, but boot fails and leaves me no the U-Boot prompt:
U-Boot 2019.07 (Sep 20 2019 - 13:34:10 +0100)
DRAM: 128 MiB
Flash: 128 MiB
*** Warning - bad CRC, using default environment
In: pl011#9000000
Out: pl011#9000000
Err: pl011#9000000
Net:
Warning: virtio-net#31 using MAC address from ROM
eth0: virtio-net#31
Hit any key to stop autoboot: 0
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...
Device 0: unknown device
Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 60.0 MB = 0.0 GB (122880 x 512)
... is now current device
** No partition table - virtio 0 **
starting USB...
No working controllers found
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#31 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40200000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (0 ms)
Using virtio-net#31 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x40400000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=>
so it appears that U-Boot cannot handle the VirtIO device? Or according to Peter, I have to create a partition table. I couldn't find that automatically in Buildroot, but I could do it manually, here is one approach: https://unix.stackexchange.com/questions/209566/how-to-format-a-partition-inside-of-an-img-file/527132#527132
Another approach would be to keep -kernel -append and let QEMU put the kernel into memory as done without U-Boot, and then use the booti U-Boot command I've found on help:
booti - boot Linux kernel 'Image' format from memory
so I just need to find out its address. But that is kind of cheating since I want U-boot to do the hard work rather than cheat with QEMU.
My goal is to reach a good setup to develop U-Boot and QEMU's early boot stuff.
Given that u-boot correctly detects the virtio block device, I think it is unlikely that it cannot handle it. The error printed is "** No partition table - virtio 0 **", which is correct, because you've set up the block device to contain just rootfs.ext4, which will be a filesystem image. That suggests that you'll have more luck if you create a disk image with a partition table and write the rootfs to a partition within the disk image.
I followed Peter's advice and put it into a partitioned image with the sfdisk-fs-to-img command from https://unix.stackexchange.com/questions/209566/how-to-format-a-partition-inside-of-an-img-file/527132#527132
I am now able to read the root filesystem with:
ls virtio 0 /boot
and that contains Image file.
Now I think there are only some U-Boot specifics to resolve, which I'm not very familiar with:
load /boot/Image into memory with something like load virtio 0 0x100000 /boot/Image. TODO which address is valid? This arbitrary choice gave ** Reading file would overwrite reserved memory **
find out how to load the DTB and kernel CLI arguments. The DTB would need to be auto-generated with QEMU with qemu-system-aarch64 -machine dumpdtb=dtb.dtb
boot it with something like: booti 0x100000
I was hoping Buildroot would have automated things a bit more for me sadface.
Now I make low level bare-metal tool for RPi.
And I need to get Secure Configuration Register value.
I wrote the following instruction mrc p15, 0, r0, c1, c1, 0 to get it.
But CPU goes into Undefined Exception Mode and CPSR value is 0x600001DB.
Instruction of reading SCR value is the first instruction being executed by CPU.
I'd read ARM1176JZF-S TRM r0p7 several times but I've not found any restriction on using SCR reading instruction except being CPU in the Secure Privileged Mode but according to TRM this CPU starts from Secure Privileged Mode. If to be more concrete the initial mode is Secure Supervisor Mode.
I use the following command to execute code with QEMU
qemu-system-arm -cpu arm1176 -M versatilepb -m 256 -nographic -kernel start.elf -s -S -monitor stdio
I can't understand what I overlooked?
QEMU's versatilepb board does not support TrustZone: it creates a CPU with that feature disabled.
Other QEMU board models do support TZ, if you want to play with it: for instance vexpress-a9, vexpress-a15 and raspi2; also "virt", if you pass -machine secure=on on the QEMU command line.
i am using qemu-system-arm to execute a bare-metal cortex-m3 binary using a custom machine populated with emulations of memory mapped devices.
To exchange data between host and the m3 binary running in qemu, I start qemu with
-chardev udp, id=ch0, port=x, localport=y -serial chardev:ch0
Then in qemu I bind a device to serial_hds[0]. Writing to the serial device, then results in udp packets sent to the host.
My question is: do I have to make the connection to -serial ? Can I in some way access the created chardevs without using the way via the -serial?
I want to setup qemu to listen on 10 udp ports, but what I understand, the -serial option is limited to max 4 devices.
QEMU's chardev abstraction has "front ends" and "back ends".
The "back end" is whatever you connect to on the host side (which might be a UDP port, stdin/stdout, a UNIX domain socket, etc). The -chardev option is what creates and configures this back end.
The "front end" is the part on the QEMU side of this. The most common use is a UART (serial port), but you can also use chardevs to specify how to talk to the QEMU monitor, or to a guest parallel port.
In this case your problem is "what are the N things that the guest sees", ie what are the front ends? There has to be something here, which means your board needs to actually create multiple UARTs or something. -serial is a limit of 4 (you can probably raise that with a local hack changing MAX_SERIAL_PORTS), but if your device model is written to take a QEMU chardev rather than to look directly at serial_hds[] it should be possible to configure it other than via -serial (either with -device ... or -global ... to set the chardev as the device property).
I am using qemu emulator for aarch64 and want to create an outside checkpoint (or fast forwarding) to save all I need to restart the system just from the point when I create checkpoint. (In fact, I want to skip the booting step) I only found something on qemu VM snapshot and fast forwarding, but it does not work for the emulator. Is there any checkpoint function for qemu emulator?
A savevm snapshot should do what you want. The short answer is that you need to set up a QCOW2 disk for the snapshots to be saved to, and then in the monitor you can use the 'savevm' command to take the snapshot. Then the command line '-loadvm' option will let you resume from there. This all works fine in emulation of AArch64.
https://translatedcode.wordpress.com/2015/07/06/tricks-for-debugging-qemu-savevm-snapshots/ has a more detailed tutorial.
Minimal example
Peter's answer just worked for me, but let me provide a fully reproducible example.
I have fully automated everything at: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/1e0f0b492855219351b0bfa2eec4d3a6811fcaaa#snapshot
The key step is to convert the image to qcow2 as explained at: https://docs.openstack.org/image-guide/convert-images.html
cd buildroot/output.x86_64~/images
qemu-img convert -f raw -O qcow2 rootfs.ext2 rootfs.ext2.qcow2
And the final QEMU command used was:
./buildroot/output.x86_64~/host/usr/bin/qemu-system-x86_64 -m 128M -monitor telnet::45454,server,nowait -netdev user,hostfwd=tcp::45455-:45455,id=net0 -smp 1 -M pc -append 'root=/dev/vda nopat nokaslr norandmaps printk.devkmsg=on printk.time=y console=ttyS0' -device edu -device virtio-net-pci,netdev=net0 -drive file=./buildroot/output.x86_64~/images/rootfs.ext2.qcow2,if=virtio,format=qcow2 -kernel ./buildroot/output.x86_64~/images/bzImage -nographic
To test it out, login into the VM, and run:
i=0; while true; do echo $i; i=$(($i + 1)); sleep 1; done
Then on another shell, open the monitor:
telnet localhost 45454
savevm my_snap_id
The counting continues. Then, if we load the vm:
loadvm my_snap_id
the counting goes back to where we saved. This shows that CPU and memory states were reverted.
We can also verify that the disk state is also reversed. Guest:
echo 0 >f
Monitor:
savevm my_snap_id
Guest:
echo 1 >f
Monitor:
loadvm my_snap_id
Guest:
cat f
And the output is 0.