QEMU hangs after remote_port connection

[jonmcdonald]

Hello,

I am trying to go through the systemctlm-cosim-demo using the zynq platform. I have gone through the following steps:

1. Built a petalinux project which properly boots linux.
2. Included the zynq-pl-remoteport.dtsi. The instructions referenced at http://www.wiki.xilinx.com/QEMU+SystemC+and+TLM+CoSimulation referenced paths in the project which did not exist. The dtsi was included based on the instructions in http://blog.reds.ch/?p=1180.
3. Built the systemctlm-cosim-demo using g++ 7.3.1. Tried with Systemc versions 2.3.2 and 2.3.3 with the same result.

When I execute petalinux-boot --qemu --kernel --qemu-args "-hw-dtb ./qemu_cosim/qemu_hw_system.dtb -machine-path ./qemu_cosim -icount 1 -sync-quantum 10000" qemu appears to be executed and I get the message qemu-system-aarch64: info: QEMU waiting for connection on: disconnected:unix:./qemu_cosim/qemu-rport-_cosim@0,server

I then start the systemc example with LD_LIBRARY_PATH=/home/tools/systemc/SystemC-2.3.3/lib-linux64 ./zynq_demo unix:/home/jon/work/xilinx/petalinux/test/qemu_cosim/qemu-rport-_cosim@0 10000. I modified the systemc to print out a message each second of simulation time. Simulation time progresses on the systemc side. On the qemu side I get a message which is the first message I see when booting qemu without the remoteport.dtsi included. qemu-system-aarch64: warning: hub 0 is not connected to host network. No messages from qemu after that.

When I kill the systemc simulation I get the following from qemu, qemu-system-aarch64: /cosim@0: Disconnected clk=74225145930 ns. The time varies depending on how long I have let it run, but no other messages.

Any suggestions on what might be causing qemu to hang?

Thanks, Jon

[edgarigl]

Hi,

Could you try without the -icount 1 option and let us know how it goes?

Thanks, Edgar

[jonmcdonald]

Hi Edgar,

Thanks for the reply.
I am passing -icount on the command line as part of the --qemu-args. The command line is repeated below. Is this the right place to pass the argument?

petalinux-boot --qemu --kernel --qemu-args "-hw-dtb ./qemu_cosim/qemu_hw_system.dtb -machine-path ./qemu_cosim -icount 1 -sync-quantum 10000"

I am running with petalinux 2020.1, and GCC 7.3.1 on Centos 7.8.

Thanks, Jon

[jonmcdonald]

Sorry, misread the suggestion. I'm trying now without the -icount 1.

[jonmcdonald]

Removing the -icount 1 did not make any difference.

[jonmcdonald]

Hello Edgar,

Looking at the qemu-system-aarch64 command called by petalinux-boot, I noticed that the .dtb is passed with the -dtb switch in the case without the remote-port included, but the instructions specify passing -hw-dtb through the petalinux-boot --qemu-args switch to point at the .dtb with the remote-port.

If I invoke the qemu-system-aarch64 call directly changing the -hw-dtb switch to -dtb, then qemu boots. I have not tested the communication with the SystemC model yet, so not sure if this is actually working correctly.

The qemu command I am using which boots linux is below. The only change was to replace -hw-dtb with -dtb.

qemu-system-aarch64 \
        -M arm-generic-fdt-7series \
        -machine linux=on   \
        -serial /dev/null \
        -serial mon:stdio \
        -display none \
        -kernel /home/jon/work/xilinx/petalinux/test/images/linux/zImage \
        -initrd /home/jon/work/xilinx/petalinux/test/images/linux/rootfs.cpio.gz.u-boot \
        -gdb tcp::9002 \
        -net nic,netdev=eth0 \
        -netdev user,id=eth0,tftp=/tftpboot \
        -net nic \
        -device loader,addr=0xf8000008,data=0xDF0D,data-len=4 \
        -device loader,addr=0xf8000140,data=0x00500801,data-len=4 \
        -device loader,addr=0xf800012c,data=0x1ed044d,data-len=4 \
        -device loader,addr=0xf8000108,data=0x0001e008,data-len=4 \
        -device loader,addr=0xF8000910,data=0xF,data-len=0x4  \
        -dtb ./qemu_cosim/qemu_hw_system.dtb \
        -machine-path ./qemu_cosim \
        -icount 1 \
        -sync-quantum 10000

Changing the petalinux-boot --qemu-args switch to use -dtb instead of -hw-dtb produces some sed and awk errors then hangs in the same way as invoking with -hw-dtb.

Is this a bug in the way petalinux-boot is calling qemu, or am I doing something else wrong?

Thanks, Jon

[jonmcdonald]

Hi Edgar,

The co-simulation appears to be working between QEMU and SystemC in my environment when I make the qemu-system-aarch64 call above. Can you comment on any issues I might have calling qemu-system-aarch64 directly?

Note that when calling qemu-system-aarch64, I am using a version built locally from git://github.com/Xilinx/qemu.git SHA 235191e77f, which is the current master version.
When calling petalinux-boot, it is Petalinux version 2020.1 calling the qemu-system-aarch64 built into that release.

Is this a bug in petalinux-boot or something else?

Thanks, Jon

[KRolander]

Hi Jon and Edgar,

The solution of Jon works also fine for me, the communication between the QEMU and SystemC works fine too. However, I used a standard Linux Image instead of PetaLinux Image, and I also created a device tree source (DTS) with the Xilinx SDK, obviously I also included the zynq-pl-remoteport.dtsi to obtain a DTB allowing the remote port communication.

I've tried to reproduce the same work with the ZynqMP (so using a standard Linux Image, and the SDK built DTS). For the hw-dtb I used zcu102-arm.cosim.dtb and for the dtb I use the SDK built DTB. Unfortunately, no messages from qemu after that even if the SystemC zynqmp-demo has been connected to the QEMU side.

At Xilinx Page Zynq+UltraScale+MPSoC we can read : NOTE that the QEMU hardware device trees are only supplied with PetaLinux 2016.1 and later BSPs.

Do you think that there is a special way to use a standard Linux Image to be able to emulate a zynqMP or it woudn't be possible at all ?

Thanks, Roland

[edgarigl]

Hi Roland,

Yes, it should be possible to use a "standard" Linux kernel Image from upstream I'm guessing. You may need to tweak the device-tree though.

It's easier if you start by booting the ZynqMP kernel without co-sim first and then we can add the co-sim flow. ZynqMP uses a PMU Firmware (Platform Manager Unit Firmware) that Linux generally requires. You'll need to run the PMU QEMU models aswell.

Have you installed PetaLinux or are you rolling your own tools/Linux/rootfs? Can you post the full QEMU command-line that you tried?

Best regards

[KRolander]

Hi Edgar,

Thank you for your advice, ok I will try to run the qemu without the co-sim tools, I think I could use zcu102-arm.dtb as the hw-dtb.

Actually, I found a rootfs in a prebuilt Xilinx project 2016.4-zed-release.tar.xz , so it is a PetaLinux rootfs, and I preferred to use this rootfs because in the case of Zynq-7000 it has worked quite well. But I have not installed PetaLinux tools to build a rootfs.

My QEMU command-line with the co-sim commands:

qemu-system-aarch64 \
        -M arm-generic-fdt \
        -machine linux=on \
        -serial /dev/null \
        -serial mon:stdio \
        -display none \
        -kernel ./uImage \
        --initrd ./umy_ramdisk.image.gz \
        -hw-dtb ./zcu102-arm.cosim.dtb \
        -dtb ./system-top.dtb \
        -device loader,addr=0xfd1a0104,data=0x8000000e,data-len=4 \
        -machine-path /tmp/machine-aarch64 \
        -icount 1 \
        -sync-quantum 10000

Thanks, Roland

[edgarigl]

Hi Roland,

Note that the ARM cores on the Zynq 7K are quite different from the ones on the ZynqMP. The ZynqMP is a 64bit ARMv8 core and although it can run 32-bit kernels and 32-bit user-space (rootfs), using 32-bit kernels will likely not work out of the box. Perhaps you could download a recent Petalinux with a zcu102 BSP and run petalinux-boot targeting QEMU to get a base for a working command-line and working set of images. Then you can try to replace them one by one with your own stuff.

Best regards, Edgar

[KRolander]

Thank you Edgar,

I would try to do in this way, and I would let you know how it worked.

Best Regards Roland

[mksaksms]

Hi edgar, I faced the same problem mentioned in the first comment. Any solution ? I tried to change the icount and also tried excluding from the command line. But nothing works. I couldnot generate the zcu102-arm.dtb as directed in your example. I create a another issue in that qemu-device-tree github project to get an example of setting dtc = env command. So I approached with the http://blog.reds.ch/?p=1180 tutorial.

[mksaksms]

In my case when I cancel the system c window by pressing ctrl + c it shows qemu-system-aarch64: /cosim@0: Disconnected clk=0 ns Here clock is 0 ns . Is it the main reason that clock is not connected ? @edgarigl

[mksaksms]

hi @edgarigl Could you please help with this issue ?

[edgarigl]

Hi,

The documentation for Zynq 7K including device-tree generation has been updated. Have a look at the following and see if you can get Zynq 7K co-simulation working.

https://github.com/Xilinx/systemctlm-cosim-demo/blob/master/docs/zynq-7000-getting-started-guide.md

Best regards, Edgar

[mksaksms]

@edgarigl that is also creating problem while installing .

[mksaksms]

@edgarigl Hello edgarigl I tried to implement that tutorial the demo is working now. I tried to read the devmem in position 0x40000000 and I think the hex value was increasing by time. How can I replace it with my own custom soc ? It become more complex now ? I tried to replace the files of buildroot/output/images with my petalinux output. It runs well with my petalinux image. But when I tried to read from my custom IP it was not showing proper value.

And in the systemc shell(seperate shell) it was showing DECODE ERROR! 43c30000

when I write value in devmem this was log :

TRACE: 1 35303791417 ns diff=35303791417 ns