Re: QEMU 6.2.0: Segfault while calling address_space_init from emulated device
Hi Peter, I am building it from git but not directly but via Yocto Kirkstone (it was originally designed to build via downloaded tarball archive). I will add the --enable-werror to the build recipe. May I ask why address_space_init should be called from device realize and not init ? On Tue, May 17, 2022 at 12:40 AM Peter Maydell wrote: > > On Tue, 17 May 2022 at 04:39, Karthik Poduval > wrote: > > Ok digging deeper, there was a compiler warning about a missing > > prototype of get_system_memory but I never thought it would lead to > > this sort of an issue. > > If you're building QEMU from git it should default to > "warnings are errors". If you're not, then pass configure > --enable-werror to do that. > > PS: not related to your problem, but you should really do > the address_space_init() in device realize, not init. > > thanks > -- PMM -- Regards, Karthik Poduval
Re: QEMU 6.2.0: Segfault while calling address_space_init from emulated device
Ok digging deeper, there was a compiler warning about a missing prototype of get_system_memory but I never thought it would lead to this sort of an issue. The fix now is pretty simple to include the header where get_system_memory is defined. https://github.com/qemu/qemu/commit/620dba22bf389c6f9b9f039ad01fc5e1365d8216 I always thought that compilers figured things out about function prototypes but in this case it caused a very serious issue that almost seemed like memory corruption. Lesson learned, never miss function prototypes. On Mon, May 16, 2022 at 8:31 PM Karthik Poduval wrote: > > I was able to get it to work with a workaround. After doing some gdb > debugging it shows that the system_memory global was being populated > before the m2m_scaler device was being initialized. Printing > system_meory vs mr (argumet) to the crashing function shows the > pointer value to be truncated. > > (gdb) p system_memory > > $1 = (MemoryRegion *) 0x56ae16e0 > > (gdb) p mr > > $2 = (MemoryRegion *) 0x56ae16e0 > > (gdb) > > The following workaround resolves the issue for now. It accesses the > system_memory global variable directly instead of getting it from the > function get_system_memory. > https://github.com/karthikpoduval/qemu/commit/00580c9f3c60a7d9c3bb43bc9589f76e663197e4 > > On Mon, May 16, 2022 at 7:13 PM Karthik Poduval > wrote: > > > > Hi All, > > > > I still need help, any help would be greatly appreciated. Turned on > > address sanitizers (config option --enable-sanitizers). > > It pointed to a heap overflow in xilinx code. > > SUMMARY: AddressSanitizer: heap-buffer-overflow > > ../git/hw/dma/xlnx_csu_dma.c:722 in xlnx_csu_dma_class_init > > > > So disabled xilinx from the config. > > diff --git a/configs/devices/aarch64-softmmu/default.mak > > b/configs/devices/aarch64-softmmu/default.mak > > index cf43ac8da1..cf8b98070e 100644 > > --- a/configs/devices/aarch64-softmmu/default.mak > > +++ b/configs/devices/aarch64-softmmu/default.mak > > @@ -3,6 +3,6 @@ > > # We support all the 32 bit boards so need all their config > > include ../arm-softmmu/default.mak > > > > -CONFIG_XLNX_ZYNQMP_ARM=y > > -CONFIG_XLNX_VERSAL=y > > +CONFIG_XLNX_ZYNQMP_ARM=n > > +CONFIG_XLNX_VERSAL=n > > CONFIG_SBSA_REF=y > > > > Even after doing that the code still crashes at the same point. It > > seems to be a memory curruption issue or else how can > > get_system_address() function provide an incorrect pointer. > > build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/image/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 > > -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 -netdev > > user,id=net0,hostfwd=tcp::-:22,hostfwd=tcp::2323-:23,tftp=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64 > > -object rng-random,filename=/dev/urandom,id=rng0 -device > > virtio-rng-pci,rng=rng0 -drive > > id=disk0,file=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/yoe-simple-image-qemuarm64-20220515002944.rootfs.ext4,if=none,format=raw > > -device virtio-blk-device,drive=disk0 -device qemu-xhci -device > > usb-tablet -device usb-kbd -machine virt -cpu cortex-a57 -smp 4 -m > > 1024 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci > > -kernel > > /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/Image--5.15.22+git0+2d38a472b2_7f685244af-r0.0-qemuarm64-20220306152158.bin > > -append 'root=/dev/vda rw mem=1024M ip=dhcp console=ttyAMA0 > > console=hvc0 ' > > ==2004211==WARNING: ASan doesn't fully support makecontext/swapcontext > > functions and may produce false positives in some cases! > > AddressSanitizer:DEADLYSIGNAL > > = > > ==2004211==ERROR: AddressSanitizer: SEGV on unknown address > > 0x5300 (pc 0x55dfdc2b47fc bp 0x61a028e8 sp 0x7ffcf813edc0 > > T0) > > ==2004211==The signal is caused by a READ memory access. > > #0 0x55dfdc2b47fb in memory_region_ref ../git/softmmu/memory.c:1790 > > #1 0x55dfdc2b47fb in address_space_init ../git/softmmu/memory.c:3005 > > #2 0x55dfdacba208 in m2m_scaler_realize ../git/hw/misc/m2m_scaler.c:288 > > #3 0x55dfdc7fb1eb in device_set_realized ../git/hw/core/qdev.c:531 > > #4 0x55dfdc807c50 in property_set_bool ../git/qom/object.c:2268 > > #5 0x55dfdc80f5ff in object_property_set ../git/qom/object.c:1403 > > #6 0x55dfdc819253 in object_property_set_qobject > > ../git/qo
Re: QEMU 6.2.0: Segfault while calling address_space_init from emulated device
I was able to get it to work with a workaround. After doing some gdb debugging it shows that the system_memory global was being populated before the m2m_scaler device was being initialized. Printing system_meory vs mr (argumet) to the crashing function shows the pointer value to be truncated. (gdb) p system_memory $1 = (MemoryRegion *) 0x56ae16e0 (gdb) p mr $2 = (MemoryRegion *) 0x56ae16e0 (gdb) The following workaround resolves the issue for now. It accesses the system_memory global variable directly instead of getting it from the function get_system_memory. https://github.com/karthikpoduval/qemu/commit/00580c9f3c60a7d9c3bb43bc9589f76e663197e4 On Mon, May 16, 2022 at 7:13 PM Karthik Poduval wrote: > > Hi All, > > I still need help, any help would be greatly appreciated. Turned on > address sanitizers (config option --enable-sanitizers). > It pointed to a heap overflow in xilinx code. > SUMMARY: AddressSanitizer: heap-buffer-overflow > ../git/hw/dma/xlnx_csu_dma.c:722 in xlnx_csu_dma_class_init > > So disabled xilinx from the config. > diff --git a/configs/devices/aarch64-softmmu/default.mak > b/configs/devices/aarch64-softmmu/default.mak > index cf43ac8da1..cf8b98070e 100644 > --- a/configs/devices/aarch64-softmmu/default.mak > +++ b/configs/devices/aarch64-softmmu/default.mak > @@ -3,6 +3,6 @@ > # We support all the 32 bit boards so need all their config > include ../arm-softmmu/default.mak > > -CONFIG_XLNX_ZYNQMP_ARM=y > -CONFIG_XLNX_VERSAL=y > +CONFIG_XLNX_ZYNQMP_ARM=n > +CONFIG_XLNX_VERSAL=n > CONFIG_SBSA_REF=y > > Even after doing that the code still crashes at the same point. It > seems to be a memory curruption issue or else how can > get_system_address() function provide an incorrect pointer. > build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/image/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 > -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 -netdev > user,id=net0,hostfwd=tcp::-:22,hostfwd=tcp::2323-:23,tftp=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64 > -object rng-random,filename=/dev/urandom,id=rng0 -device > virtio-rng-pci,rng=rng0 -drive > id=disk0,file=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/yoe-simple-image-qemuarm64-20220515002944.rootfs.ext4,if=none,format=raw > -device virtio-blk-device,drive=disk0 -device qemu-xhci -device > usb-tablet -device usb-kbd -machine virt -cpu cortex-a57 -smp 4 -m > 1024 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci > -kernel > /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/Image--5.15.22+git0+2d38a472b2_7f685244af-r0.0-qemuarm64-20220306152158.bin > -append 'root=/dev/vda rw mem=1024M ip=dhcp console=ttyAMA0 > console=hvc0 ' > ==2004211==WARNING: ASan doesn't fully support makecontext/swapcontext > functions and may produce false positives in some cases! > AddressSanitizer:DEADLYSIGNAL > = > ==2004211==ERROR: AddressSanitizer: SEGV on unknown address > 0x5300 (pc 0x55dfdc2b47fc bp 0x61a028e8 sp 0x7ffcf813edc0 > T0) > ==2004211==The signal is caused by a READ memory access. > #0 0x55dfdc2b47fb in memory_region_ref ../git/softmmu/memory.c:1790 > #1 0x55dfdc2b47fb in address_space_init ../git/softmmu/memory.c:3005 > #2 0x55dfdacba208 in m2m_scaler_realize ../git/hw/misc/m2m_scaler.c:288 > #3 0x55dfdc7fb1eb in device_set_realized ../git/hw/core/qdev.c:531 > #4 0x55dfdc807c50 in property_set_bool ../git/qom/object.c:2268 > #5 0x55dfdc80f5ff in object_property_set ../git/qom/object.c:1403 > #6 0x55dfdc819253 in object_property_set_qobject > ../git/qom/qom-qobject.c:28 > #7 0x55dfdc80feb5 in object_property_set_bool ../git/qom/object.c:1472 > #8 0x55dfdc7f9452 in qdev_realize_and_unref ../git/hw/core/qdev.c:340 > #9 0x55dfda8c9adc in sysbus_create_varargs ../git/hw/core/sysbus.c:236 > #10 0x55dfdb24d87e in sysbus_create_simple > /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/git/include/hw/sysbus.h:104 > #11 0x55dfdb24d87e in create_m2m_scaler ../git/hw/arm/virt.c:1316 > #12 0x55dfdb24d87e in machvirt_init ../git/hw/arm/virt.c:2223 > #13 0x55dfda8bd006 in machine_run_board_init ../git/hw/core/machine.c:1187 > #14 0x55dfdc2c9f51 in qemu_init_board ../git/softmmu/vl.c:2656 > #15 0x55dfdc2c9f51 in qmp_x_exit_preconfig ../git/softmmu/vl.c:2746 > #16 0x55dfdc2d1425 in qemu_init ../git/softmmu/vl.c:3777 > #17 0x55dfda49c1fc in main ../git/softmmu/main.c:49 > #18 0x7f53e39ce57a > (/home/kpo
Re: QEMU 6.2.0: Segfault while calling address_space_init from emulated device
Hi All, I still need help, any help would be greatly appreciated. Turned on address sanitizers (config option --enable-sanitizers). It pointed to a heap overflow in xilinx code. SUMMARY: AddressSanitizer: heap-buffer-overflow ../git/hw/dma/xlnx_csu_dma.c:722 in xlnx_csu_dma_class_init So disabled xilinx from the config. diff --git a/configs/devices/aarch64-softmmu/default.mak b/configs/devices/aarch64-softmmu/default.mak index cf43ac8da1..cf8b98070e 100644 --- a/configs/devices/aarch64-softmmu/default.mak +++ b/configs/devices/aarch64-softmmu/default.mak @@ -3,6 +3,6 @@ # We support all the 32 bit boards so need all their config include ../arm-softmmu/default.mak -CONFIG_XLNX_ZYNQMP_ARM=y -CONFIG_XLNX_VERSAL=y +CONFIG_XLNX_ZYNQMP_ARM=n +CONFIG_XLNX_VERSAL=n CONFIG_SBSA_REF=y Even after doing that the code still crashes at the same point. It seems to be a memory curruption issue or else how can get_system_address() function provide an incorrect pointer. build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/image/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64 -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::-:22,hostfwd=tcp::2323-:23,tftp=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -drive id=disk0,file=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/yoe-simple-image-qemuarm64-20220515002944.rootfs.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -device qemu-xhci -device usb-tablet -device usb-kbd -machine virt -cpu cortex-a57 -smp 4 -m 1024 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci -kernel /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/Image--5.15.22+git0+2d38a472b2_7f685244af-r0.0-qemuarm64-20220306152158.bin -append 'root=/dev/vda rw mem=1024M ip=dhcp console=ttyAMA0 console=hvc0 ' ==2004211==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! AddressSanitizer:DEADLYSIGNAL = ==2004211==ERROR: AddressSanitizer: SEGV on unknown address 0x5300 (pc 0x55dfdc2b47fc bp 0x61a028e8 sp 0x7ffcf813edc0 T0) ==2004211==The signal is caused by a READ memory access. #0 0x55dfdc2b47fb in memory_region_ref ../git/softmmu/memory.c:1790 #1 0x55dfdc2b47fb in address_space_init ../git/softmmu/memory.c:3005 #2 0x55dfdacba208 in m2m_scaler_realize ../git/hw/misc/m2m_scaler.c:288 #3 0x55dfdc7fb1eb in device_set_realized ../git/hw/core/qdev.c:531 #4 0x55dfdc807c50 in property_set_bool ../git/qom/object.c:2268 #5 0x55dfdc80f5ff in object_property_set ../git/qom/object.c:1403 #6 0x55dfdc819253 in object_property_set_qobject ../git/qom/qom-qobject.c:28 #7 0x55dfdc80feb5 in object_property_set_bool ../git/qom/object.c:1472 #8 0x55dfdc7f9452 in qdev_realize_and_unref ../git/hw/core/qdev.c:340 #9 0x55dfda8c9adc in sysbus_create_varargs ../git/hw/core/sysbus.c:236 #10 0x55dfdb24d87e in sysbus_create_simple /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/git/include/hw/sysbus.h:104 #11 0x55dfdb24d87e in create_m2m_scaler ../git/hw/arm/virt.c:1316 #12 0x55dfdb24d87e in machvirt_init ../git/hw/arm/virt.c:2223 #13 0x55dfda8bd006 in machine_run_board_init ../git/hw/core/machine.c:1187 #14 0x55dfdc2c9f51 in qemu_init_board ../git/softmmu/vl.c:2656 #15 0x55dfdc2c9f51 in qmp_x_exit_preconfig ../git/softmmu/vl.c:2746 #16 0x55dfdc2d1425 in qemu_init ../git/softmmu/vl.c:3777 #17 0x55dfda49c1fc in main ../git/softmmu/main.c:49 #18 0x7f53e39ce57a (/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6+0x2d57a) #19 0x7f53e39ce62f in __libc_start_main (/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/sysroots-uninative/x86_64-linux/lib/libc.so.6+0x2d62f) #20 0x55dfda4d6f5d in _start (/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/image/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/recipe-sysroot-native/usr/bin/qemu-system-aarch64+0x3b58f5d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV ../git/softmmu/memory.c:1790 in memory_region_ref ==2004211==ABORTING Any help would be greatly appreciated. Here is the link to the latest code. https://github.com/karthikpoduval/qemu/tree/scaler-bringup On Sun, May 15, 2022 at 12:26 AM Karthik Poduval wrote: > > Hi All, > > I am trying to create a virtual mem2mem scaler device in QEMU (for the > purposes of writing a mem2mem driver tutorial). I created the m
QEMU 6.2.0: Segfault while calling address_space_init from emulated device
Hi All, I am trying to create a virtual mem2mem scaler device in QEMU (for the purposes of writing a mem2mem driver tutorial). I created the mem2mem device as shown here. https://github.com/karthikpoduval/qemu/blob/scaler-bringup/hw/misc/m2m_scaler.c I added this MMIO device to the arm virt.c (as shown here). https://github.com/karthikpoduval/qemu/blob/scaler-bringup/hw/arm/virt.c#L1306 However while the device is getting created, there is a crash while launching QEMU. qemu-system-aarch64 -device virtio-net-device,netdev=net0,mac=52:54:00:12:35:02 -netdev user,id=net0,hostfwd=tcp::-:22,hostfwd=tcp::2323-:23,tftp=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -drive id=disk0,file=/home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/yoe-simple-image-qemuarm64-20220515002944.rootfs.ext4,if=none,format=raw -device virtio-blk-device,drive=disk0 -device qemu-xhci -device usb-tablet -device usb-kbd -machine virt -cpu cortex-a57 -smp 4 -m 1024 -serial mon:stdio -serial null -nographic -device virtio-gpu-pci -kernel /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/deploy/images/qemuarm64/Image--5.15.22+git0+2d38a472b2_7f685244af-r0.0-qemua rm64-20220306152158.bin -append 'root=/dev/vda rw mem=256M ip=dhcp console=ttyAMA0 console=hvc0 ' Upon running gdb, the stack trace looks like. Thread 1 "qemu-system-aar" received signal SIGSEGV, Segmentation fault. 0x55d2f6d6 in memory_region_ref (mr=0x56becae0) at ../git/softmmu/memory.c:3005 3005memory_region_ref(root); (gdb) bt #0 0x55d2f6d6 in memory_region_ref (mr=0x56becae0) at ../git/softmmu/memory.c:3005 #1 address_space_init (as=0x570f8bb8, root=0x56becae0, name=0x560a9620 "m2m-scaler-dma") at ../git/softmmu/memory.c:3005 #2 0x55e0d5c8 in object_initialize_with_type (obj=obj@entry=0x570f8750, size=size@entry=1360, type=type@entry=0x56a117d0) at ../git/qom/object.c:518 #3 0x55e0d719 in object_new_with_type (type=0x56a117d0) at ../git/qom/object.c:733 #4 0x55e08e3a in qdev_new (name=name@entry=0x560a95eb "m2m_scaler") at ../git/hw/core/qdev.c:153 #5 0x5595cafa in sysbus_create_varargs (name=name@entry=0x560a95eb "m2m_scaler", addr=addr@entry=0) at ../git/hw/core/sysbus.c:234 #6 0x55adf1a1 in sysbus_create_simple (irq=, addr=0, name=0x560a95eb "m2m_scaler") at /home/kpoduval/workspace/yoe-master-kpoduval/build/tmp/work/x86_64-linux/qemu-system-native/6.2.0-r0/git/include/hw/sysbus.h:104 #7 create_m2m_scaler (vms=0x56c31400) at ../git/hw/arm/virt.c:1317 #8 machvirt_init (machine=0x56c31400) at ../git/hw/arm/virt.c:2239 #9 0x55959929 in machine_run_board_init (machine=0x56c31400) at ../git/hw/core/machine.c:1187 #10 0x55d3576f in qemu_init_board () at ../git/softmmu/vl.c:2656 #11 qmp_x_exit_preconfig (errp=) at ../git/softmmu/vl.c:2746 #12 qmp_x_exit_preconfig (errp=) at ../git/softmmu/vl.c:2739 #13 0x55d38f3b in qemu_init (argc=, argv=, envp=) at ../git/softmmu/vl.c:3777 #14 0x5588e1bd in main (argc=, argv=, envp=) at ../git/softmmu/main.c:49 I was able to do the same thing in QEMU 5.1.0 do not know why this does not work in QEMU 6.2.0. Kindly help me resolve this issue. I want my device to have access to the entire system RAM (as thi emulated device can read input image from DDR scale it and write back the input image to DDR so it needs to have access to the entire DDR memory). -- Regards, Karthik Poduval
Re: Heterogeneous/AMP example in mainline?
Thanks Peter, I will go through the Xilinx example. -- Regards, Karthik Poduval On Fri, Sep 18, 2020 at 8:08 AM Peter Maydell wrote: > On Fri, 18 Sep 2020 at 14:15, karthik poduval > wrote: > > Was sifting through the heterogeneous QEMU effort in archives here > > https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06256.html > > > > Did this effort make it to the mainline ? Are there any examples of > > AMP SoC's in the mainline ? > > In upstream we can handle having asymmetric configurations > as long as all the CPUs are the same basic architecture: > so you can have for instance an Arm Cortex-M and a Cortex-A > in the same board model (there's a xilinx board model > with a mix of cortex-a53 and cortex-r5 cores in the tree). > But we can't handle having multiple different architectures (eg > Arm and x86) in the same board at once. It would be nice to be > able to do that, but it would require a lot of untangling of > things which currently assume various parameters that are > guest-architecture-specific are compile-time fixed things. > So far nobody has been sufficiently interested in having > asymmetric configs to put in that work. > > thanks > -- PMM > -- Regards, Karthik Poduval
Heterogeneous/AMP example in mainline?
Hi All, Was sifting through the heterogeneous QEMU effort in archives here https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06256.html Did this effort make it to the mainline ? Are there any examples of AMP SoC's in the mainline ? -- Regards, Karthik Poduval
Re: [Qemu-devel] GUI for peripherals
Thank you. I will check that out. Best regards, Karthik On Wed, Jun 1, 2016 at 5:59 PM, Liviu Ionescu <i...@livius.net> wrote: > > > On 01 Jun 2016, at 12:28, KONRAD Frederic <fred.kon...@greensocs.com> > wrote: > > > > ... I think Liviu did something about this: ... > > I confirm that GNU ARM Eclipse QEMU implements animated LEDs. In other > words, toggling a GPIO pin connected to a led toggles the content of a > rectangular area on the board image, looking like a blinking LED. > > > http://gnuarmeclipse.github.io/tutorials/blinky-arm/#run-the-test-with-qemu > > > Regards, > > Liviu > >
[Qemu-devel] GUI for peripherals
Hello, What would be the best way to provide GUI for peripheral control? This is not for linux rather than embedded system running home brew rtos. For example an GPIO module, I would need an UI to toggle an GPIO and see the output, like press an button and simulate it turning on an LED. Would it be possible to write the GUI separately and use QMP to communicate with my custom driver to control peripherals? or is there an better way to do this? Best regards, Karthik
Re: [Qemu-devel] ARM IRQ Generation
Okay. Thank you. Best regards, Karthik On Wed, May 25, 2016 at 6:18 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 25 May 2016 at 13:42, Karthik <karthikshanmu...@gmail.com> wrote: > > Okay, understood. I`ll hold the IRQ line until CPU acknowledges the > > interrupt. > > > > By the way, is there a distinction between edge and level triggered > > interrupt in the qemu or it is up to the emulation implementation? > > In QEMU, if you call qemu_set_irq(irq, 1) this is equivalent to > the hardware taking the IRQ wire to logical 1. Calling > qemu_set_irq(irq, 0) is taking the wire to logical 0. > (qemu_irq_pulse() takes the wire very briefly to logical 1, and > is a bit of an odd thing to do.) You need to do what the hardware > does to the hardware irq wire in the same situations when the > hardware changes the irq wire state. > > Edge vs level is about what a device does when it sees a change > in state on an an incoming interrupt wire. "Edge triggered" means > it cares about the 0->1 change, and implies that it has an > internal latch which is set when the edge is detected, so that > it doesn't matter if the incoming wire drops to 0 again. "Level > triggered" means that it is the level state of the incoming wire > that matters. This is again all about "how do you behave when > you see the wire state changing", and you need to do what the > hardware does. If the hardware is strictly edge-triggered then > your model should be also; if it is always level-triggered then > your model must do the same; if it is configurable then again > you need to model the configurability. > > thanks > -- PMM >
Re: [Qemu-devel] ARM IRQ Generation
Okay, understood. I`ll hold the IRQ line until CPU acknowledges the interrupt. By the way, is there a distinction between edge and level triggered interrupt in the qemu or it is up to the emulation implementation? Best regards, Karthik On Wed, May 25, 2016 at 6:04 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 25 May 2016 at 11:47, Karthik <karthikshanmu...@gmail.com> wrote: > > Hi, > > > > I am working on emulating an Spansion micro with ARM Cortex R5F Core. > > > > It has got an Interrupt Controller which accepts multiple interrupts and > > generates the IRQ to the CPU based on register settings. > > > > Now an timer module calls the qemu_irq_pulse() to signal the Interrupt > > Controller (IC). The interrupt handler in the IC is called with the > correct > > irq number with level 1 and immediately followed by level 0. The IC in > turn > > signals the CPU using qemu_set_irq with level 1 and 0. > > > > In this case the ARM CPU is not interrupted at all and there is no > > exception generated, because the irq is lowered before the CPU is > > interrupted. > > This sounds like your interrupt controller model is buggy. The > IRQ and FIQ lines into the ARM CPU are level-triggered, so typically > for an edge-triggered interrupt the interrupt controller will > latch the fact that an interrupt has come in, and hold the IRQ > line to the CPU high until the CPU acknowledges the interrupt > in some way. Alternatively, your guest might be misconfiguring > the interrupt controller to say that this timer module's interrupt > is level-triggered when it's actually edge triggered. Or your > timer device model might be buggy and using edge-triggered > behaviour when it is supposed to be level-triggered. > > You need to check the hardware specs for how these various > pieces are supposed to behave and see which one is out of > line with its spec. > > thanks > -- PMM >
Re: [Qemu-devel] ARM invalid co-processor register
Understood. Thank you for the clarifications. Best regards, Karthik On Wed, May 25, 2016 at 6:05 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 25 May 2016 at 13:33, Karthik <karthikshanmu...@gmail.com> wrote: > > Does the qemu implements cache emulation? > > I did see some comments saying otherwise. > > No, we don't emulate functional caches. This means that all > the operations for "flush cache" etc can be no-ops. They > do still have to actually exist and not UNDEF, though. > > thanks > -- PMM >
Re: [Qemu-devel] ARM invalid co-processor register
Does the qemu implements cache emulation?
I did see some comments saying otherwise.
Best regards,
Karthik
On Wed, May 25, 2016 at 5:57 PM, Peter Maydell <peter.mayd...@linaro.org>
wrote:
> On 25 May 2016 at 06:44, Karthik <karthikshanmu...@gmail.com> wrote:
> > Hi,
> >
> > CPU: Cortex R5F
> >
> > I have this instruction that invalidates the entire data cache
> >
> > MCR p15, 0, r0, c15, c5, 0
> >
> >
> >
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460c/Chdhgibd.html
> >
> > This instruction generates undefined exception, and further debugging
> > showed it is because the co-processor register was not implemented.
> >
> > To get around, I have added the below entry in the cortexr5_cp_reginfo[]
> > (target-arm/cpu.c)
> >
> > {
> > {.name = "INVALLDC", .cp=15, .opc1 = 0, .crn = 5, .opc2 = 0.
> > .access = PL1_W, .type = ARM_CP_NOP | ARM_CP_OVERRIDE},
> > }
> >
> > or
> >
> > I have to add
> > set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
> >
> > So, which option is recommended?
>
> Better to implement exactly the registers that are required;
> the DUMMY_C15_REGS feature is mostly there for our older CPU
> emulation because it's what we've always done, and it's a bit
> tricky to move to being more specific without potentially breaking
> guest code that used to work. We shouldn't be adding it to more
> CPUs.
>
> You should check against the ARM ARM whether these cache
> invalidation registers are really R5-specific, or if they're
> a part of the generic PMSA architecture. If they're generic
> PMSA then they should be implemented in the generic code,
> enabled by a new feature flag, not in the R5-only reginfo
> array.
>
> thanks
> -- PMM
>
[Qemu-devel] ARM IRQ Generation
Hi, I am working on emulating an Spansion micro with ARM Cortex R5F Core. It has got an Interrupt Controller which accepts multiple interrupts and generates the IRQ to the CPU based on register settings. Now an timer module calls the qemu_irq_pulse() to signal the Interrupt Controller (IC). The interrupt handler in the IC is called with the correct irq number with level 1 and immediately followed by level 0. The IC in turn signals the CPU using qemu_set_irq with level 1 and 0. In this case the ARM CPU is not interrupted at all and there is no exception generated, because the irq is lowered before the CPU is interrupted. There is a delay between qemu_set_irq() and the ARM CPU getting interrupted. I don't see any delay between timer and interrupt controller. Any help will be much appreciated. Thank you. Best regards, Karthik
[Qemu-devel] ARM invalid co-processor register
Hi,
CPU: Cortex R5F
I have this instruction that invalidates the entire data cache
MCR p15, 0, r0, c15, c5, 0
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0460c/Chdhgibd.html
This instruction generates undefined exception, and further debugging
showed it is because the co-processor register was not implemented.
To get around, I have added the below entry in the cortexr5_cp_reginfo[]
(target-arm/cpu.c)
{
{.name = "INVALLDC", .cp=15, .opc1 = 0, .crn = 5, .opc2 = 0.
.access = PL1_W, .type = ARM_CP_NOP | ARM_CP_OVERRIDE},
}
or
I have to add
set_feature(>env, ARM_FEATURE_DUMMY_C15_REGS);
So, which option is recommended?
Best regards,
Karthik
Re: [Qemu-devel] ARM Cortex R5 + VFP3
Hi, Added enabling VFP co-processor in the bootrom emulation code. Works like a charm. Many thanks. Best regards, Karthik On Tue, May 24, 2016 at 7:52 PM, Karthik <karthikshanmu...@gmail.com> wrote: > Yeah, the micro had a secure boot ROM which we don't have access to. > Probably it is enabled there. I'll check in the target hardware. > > The code generated by the compiler doesn't specifically check for > non-existent registers, so we should be good using VFP3 in place for > VFP3-D16. > > Best regards, > Karthik > On May 24, 2016 7:31 PM, "Peter Maydell" <peter.mayd...@linaro.org> wrote: > >> On 24 May 2016 at 14:49, Karthik <karthikshanmu...@gmail.com> wrote: >> > ahh okay. The code I don't think writes to CPACR_EL1 register, but it >> runs >> > on the hardware anywary. >> >> If it does then there's probably some firmware somewhere >> which is doing the setup for you somehow. >> >> As you can see in the Cortex-R5 technical reference manual entry >> for CPACR: >> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html >> >> the hardware reset value for bits 21..23 is 0, meaning access denied, >> and for FPEXC the EN bit is clear on reset: >> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html >> >> By the way, QEMU doesn't implement VFPv3-D16, which is what the R5 >> ought to have -- setting the ARM_FEATURE_VFP3 bit will give you >> 32 double-precision registers. This is probably close enough that >> guest code will work, though obviously if the guest specifically >> tests that registers 16..31 don't exist it will not behave as >> the hardware does. >> >> thanks >> -- PMM >> >
Re: [Qemu-devel] ARM Cortex R5 + VFP3
Yeah, the micro had a secure boot ROM which we don't have access to. Probably it is enabled there. I'll check in the target hardware. The code generated by the compiler doesn't specifically check for non-existent registers, so we should be good using VFP3 in place for VFP3-D16. Best regards, Karthik On May 24, 2016 7:31 PM, "Peter Maydell" <peter.mayd...@linaro.org> wrote: > On 24 May 2016 at 14:49, Karthik <karthikshanmu...@gmail.com> wrote: > > ahh okay. The code I don't think writes to CPACR_EL1 register, but it > runs > > on the hardware anywary. > > If it does then there's probably some firmware somewhere > which is doing the setup for you somehow. > > As you can see in the Cortex-R5 technical reference manual entry > for CPACR: > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html > > the hardware reset value for bits 21..23 is 0, meaning access denied, > and for FPEXC the EN bit is clear on reset: > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0205g/Bgbjhiea.html > > By the way, QEMU doesn't implement VFPv3-D16, which is what the R5 > ought to have -- setting the ARM_FEATURE_VFP3 bit will give you > 32 double-precision registers. This is probably close enough that > guest code will work, though obviously if the guest specifically > tests that registers 16..31 don't exist it will not behave as > the hardware does. > > thanks > -- PMM >
Re: [Qemu-devel] ARM Cortex R5 + VFP3
ahh okay. The code I don't think writes to CPACR_EL1 register, but it runs on the hardware anywary. I`ll double check. Thanks for the tip. Best regards, Karthik On Tue, May 24, 2016 at 7:07 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 24 May 2016 at 14:07, Karthik <karthikshanmu...@gmail.com> wrote: > > I am working on adding support for a Spansion microcontroller which has > an > > Cortex R5 core + VFP3 co processor. > > > > I have added the below line > > set_feature(>env, ARM_FEATURE_VFP3) > > to cortex_r5_initfn at /target-arm/cpu.c > > > > But, still I got undefined exception when the processor encountered any > VFP > > instructions. > > Has your guest code actually enabled the floating point? > It needs to write to CPACR_EL1 itself to set the FPEXC bit. Otherwise > we will correctly generate an exception, just as the real hardware > will. The code you mention is in CONFIG_USER_ONLY because if we > are only emulating a user process then we simulate the behaviour that > a Linux kernel has of setting the CPACR correctly. For system > emulation setting the bit is the guest code's responsibility. > > thanks > -- PMM >
[Qemu-devel] ARM Cortex R5 + VFP3
Hi, I am working on adding support for a Spansion microcontroller which has an Cortex R5 core + VFP3 co processor. I have added the below line set_feature(>env, ARM_FEATURE_VFP3) to cortex_r5_initfn at /target-arm/cpu.c But, still I got undefined exception when the processor encountered any VFP instructions. To get around the error, I had to enable code protected by CONFIG_USER_ONLY. Specifically in arm_cpu_reset, where the bits 20 to 24 are set in env->cp15.cpacr_el1 and env->vfp.xregs[ARM_VFP_FPEXC] = 1 << 30. I am sure there is correct way to do things. I'm new to qemu. Any help will be much appreciated. Thank you. Best regards, Karthik
[Qemu-devel] Newbie to Q
Dear All I am trying Q emulator on Mac OS X 10.4.8. It works fine and well. I am also downloaded the source code. I couldn't connect the network through this emulator. I am running Linux from this. But I couldn't connect to internet while I am inside the emulation. How can I increase the emulation speed? I am using MacBook with 512MB RAM, I set this emulation for 256MB. Is there any other way to increase the speed of working?Please guide me to do this.Best Regards,Karthik.R,
