11-26-2020 05:38 AM
Hi,
I have a design on zynqmp SoC on a custom board. I am trying to catch interrupt signal from hardware that connected to zynqmp through EMIO pin. I also added VIO to simulate that signal without hardware. This design can be seen on design_capture attached.
I modified system-user.dtsi file for UIO usage as attached. I changed bootargs arguments(from system-conf.dtsi) and gpio compatible(from zynqmp.dtsi, gpio@ff0a0000). Before that modification I could see gpiochip273(seen below) that is labelled “zynqmp-gpio”. After device tree modifications gpiochip273 dissappered. That modification enabled uio0 under /sys/class/uio/ that is named “gpio” and under /proc/interrupts. But nothing changed under proc/interrupts gpio count when I applied VIO signal.
-------
root@P0036_EMC:~# ls /sys/class/gpio/
export gpiochip273 gpiochip447 gpiochip452 gpiochip453 gpiochip483 gpiochip487 gpiochip503 unexport
-------
root@P0036_HW:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
3: 63087 17827 26149 18785 GICv2 30 Level arch_timer
6: 0 0 0 0 GICv2 67 Level zynqmp_ipi
7: 0 0 0 0 GICv2 175 Level arm-pmu
8: 0 0 0 0 GICv2 176 Level arm-pmu
9: 0 0 0 0 GICv2 177 Level arm-pmu
10: 0 0 0 0 GICv2 178 Level arm-pmu
13: 0 0 0 0 GICv2 156 Level zynqmp-dma
14: 0 0 0 0 GICv2 157 Level zynqmp-dma
15: 0 0 0 0 GICv2 158 Level zynqmp-dma
16: 0 0 0 0 GICv2 159 Level zynqmp-dma
17: 0 0 0 0 GICv2 160 Level zynqmp-dma
18: 0 0 0 0 GICv2 161 Level zynqmp-dma
19: 0 0 0 0 GICv2 162 Level zynqmp-dma
20: 0 0 0 0 GICv2 163 Level zynqmp-dma
22: 0 0 0 0 GICv2 109 Level zynqmp-dma
23: 0 0 0 0 GICv2 110 Level zynqmp-dma
24: 0 0 0 0 GICv2 111 Level zynqmp-dma
25: 0 0 0 0 GICv2 112 Level zynqmp-dma
26: 0 0 0 0 GICv2 113 Level zynqmp-dma
27: 0 0 0 0 GICv2 114 Level zynqmp-dma
28: 0 0 0 0 GICv2 115 Level zynqmp-dma
29: 0 0 0 0 GICv2 116 Level zynqmp-dma
31: 3962 0 0 0 GICv2 91 Level eth0, eth0
32: 0 0 0 0 GICv2 95 Level eth1, eth1
33: 0 0 0 0 GICv2 48 Level gpio
34: 0 0 0 0 GICv2 49 Level cdns-i2c
35: 0 0 0 0 GICv2 50 Level cdns-i2c
36: 0 0 0 0 GICv2 42 Level ff960000.memory-controller
37: 0 0 0 0 GICv2 57 Level axi-pmon, axi-pmon
38: 0 0 0 0 GICv2 155 Level axi-pmon, axi-pmon
39: 36 0 0 0 GICv2 47 Level ff0f0000.spi
40: 0 0 0 0 GICv2 58 Level ffa60000.rtc
41: 0 0 0 0 GICv2 59 Level ffa60000.rtc
42: 311 0 0 0 GICv2 80 Level mmc0
43: 255 0 0 0 GICv2 53 Level xuartps
44: 0 0 0 0 GICv2 88 Level ams-irq
61: 0 0 0 0 GICv2 97 Level xhci-hcd:usb1
IPI0: 2483 2386 3410 2294 Rescheduling interrupts
IPI1: 1675 1697 8 1674 Function call interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts
IPI4: 0 0 0 0 Timer broadcast interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up interrupts
Err: 0
-------
Tools I used:
Vivado : 2019.2
Vitis: 2019.2
Petalinux: 2019
-------
Thanks,
Mergani
11-27-2020 01:03 PM
Hi @mergani
In your axi_gpio and axi_intc instances, were you "arming" them through software to accept and process the change in inputs and thus generate an interrupt? You make no mention of this in your post.
For axi_gpio, the registers GIER and IP IER should be set properly to trigger an interrupt on input change. And axi_intc, the MER, IER and SIE should be set, among others. In Linux, these low level registers would be enabled by their driver, but you should still enable them through other methods, i.e. through sysfs for example.
Thanks,
-Pat
Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog
11-27-2020 03:09 AM
The EMIO will not be registered as an interrupt here. Why not just use an interrupt?
11-27-2020 07:00 AM
Hi,
Actually I would like to mention about my early version of vivado design. There are 16 uart channels on hw design, for those I used custom uart IP (Xilinx uartlite compatible). On initial stage of my design I used 2 concat block (8 uart + 8 uart) connected to zynqmp irq pins. So all irq pins were used for uart channels, I was able to communicate on these 16 uart channels.
After a while, it is required to connect a hw interrupt pin to design. I added axi interrupt controller for uart channels (see vivado_design.png and drawing.png for design summary). I tired both axi_gpio interrupt pin connected directly to zynqmp and (axi_intc + zynqmp). For both designs, any of uart channels could not able to communicate.
summary drawing
vivado design
I made logic analysis for uart channels and axi_gpio block. First I tested for UART channels. As an example, UART9 and UART10 loopbacked and their interrupt and axi signals are observed (see uart9_uart10.png) (M15 is axi channel of UART9 and M16 is axi channel of UART10). Both UARTs generated interrupt signals, but axi_intc does not generate interrupt signal. So communication is failed.
uart9-uart10 test axi_intc irq signal does not appear
uart9-uart10 test uart IP irq signals
Secondly, I tested for axi_gpio. When I applied VIO signal, axi_gpio does not generate interrupt signal. I came across AR#73645 xilinx article, but I have 2 input pins for axi_gpio.
axi_gpio irq signal in VIO test
After all that, I changed my vivado design to EMIO pins. Maybe, it is possible to success with my earlier design.
--------
Tools I used:
Vivado : 2019.2
Vitis: 2019.2
Petalinux: 2019
OS: Centos 7.4
VirtualBox 6.1 on Wisdows10 Host
---------
Thanks,
Mehmet
11-27-2020 01:03 PM
Hi @mergani
In your axi_gpio and axi_intc instances, were you "arming" them through software to accept and process the change in inputs and thus generate an interrupt? You make no mention of this in your post.
For axi_gpio, the registers GIER and IP IER should be set properly to trigger an interrupt on input change. And axi_intc, the MER, IER and SIE should be set, among others. In Linux, these low level registers would be enabled by their driver, but you should still enable them through other methods, i.e. through sysfs for example.
Thanks,
-Pat
Give kudos if helpful. Accept as solution if it solves your problem.
https://tuxengineering.com/blog
11-28-2020 04:55 AM
Hi,
I think you mean by “arming”, to make it wait for trigger. Yes, I armed. As you see in picture, they are still waiting for trigger. On other picture, VIO signal is caught, but axi_gpio irq isn’t. I tested it a couple of times indeed.
I also designed as 2 axi_intc instances as 2*(8 uart + concat + axi_intc) and tested this design. All channels worked successfully. When I added hw interrupt signal and axi_gpio, none of them worked. Deploying an axi_gpio changed manner of driver. Can axi_gpio cause this issue?
--------
Thanks,
Mehmet