Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QEMU hangs after remote_port connection #9

Open
jonmcdonald opened this issue Jul 14, 2020 · 17 comments
Open

QEMU hangs after remote_port connection #9

jonmcdonald opened this issue Jul 14, 2020 · 17 comments

Comments

@jonmcdonald
Copy link

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
Copy link
Collaborator

Hi,

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

Thanks,
Edgar

@jonmcdonald
Copy link
Author

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
Copy link
Author

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

@jonmcdonald
Copy link
Author

Removing the -icount 1 did not make any difference.

@jonmcdonald
Copy link
Author

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
Copy link
Author

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:/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
Copy link

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
Copy link
Collaborator

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
Copy link

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
Copy link
Collaborator

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
Copy link

Thank you Edgar,

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

Best Regards
Roland

@mksaksms
Copy link

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
Copy link

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
Copy link

hi @edgarigl Could you please help with this issue ?

@edgarigl
Copy link
Collaborator

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:/Xilinx/systemctlm-cosim-demo/blob/master/docs/zynq-7000-getting-started-guide.md

Best regards,
Edgar

@mksaksms
Copy link

@edgarigl that is also creating problem while installing .

@mksaksms
Copy link

mksaksms commented Nov 2, 2021

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants