cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mergani
Visitor
Visitor
608 Views
Registered: ‎01-07-2020

UIO Interrupt through EMIO under Petalinux

Jump to solution

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

design_capture.PNG
0 Kudos
Reply
1 Solution

Accepted Solutions
patocarr
Teacher
Teacher
480 Views
Registered: ‎01-28-2008

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

View solution in original post

4 Replies
stephenm
Moderator
Moderator
535 Views
Registered: ‎09-12-2007

The EMIO will not be registered as an interrupt here. Why not just use an interrupt?

0 Kudos
Reply
mergani
Visitor
Visitor
514 Views
Registered: ‎01-07-2020

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 drawingsummary drawingvivado designvivado 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 appearuart9-uart10 test axi_intc irq signal does not appearuart9-uart10 test uart IP irq signalsuart9-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 testaxi_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

0 Kudos
Reply
patocarr
Teacher
Teacher
481 Views
Registered: ‎01-28-2008

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

View solution in original post

mergani
Visitor
Visitor
411 Views
Registered: ‎01-07-2020

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

0 Kudos
Reply