On 23-12-16 00:38, Eric Wong wrote:
In my AMP configuration with Linux on CPU0 and an RTOS on CPU1, interrupts being routed to CPU1 are specified in the device tree entry for remoteproc:app: app@0 { compatible = "xlnx,zynq_remoteproc"; reg = < 0x1E000000 0x2000000 >; interrupt-parent = <&ps7_scugic_0>; interrupts = < 0 27 4 0 29 4 0 30 4 0 31 4 0 32 4 0 34 4 0 35 4 0 37 4 0 38 4 0 39 4 >; firmware = "app.elf"; vring0 = <15>; vring1 = <14>; } ; The "4" in the interrupts line means the interrupt is active high, and things seem to be working. If I want an interrupt to be rising edge triggered, I change the "4" to "1", but then when that interrupt triggers I get "Unexpected IRQ trap at vector 00" error in Linux and Linux freezes. Does anyone know what that means or how to fix that error? I would think Linux wouldn't/shouldn't even be looking at the interrupt(s) that are routed to CPU1. Thanks in advance.
The devicetree only guards that other drivers won't steal your interrupts away. It does not cause the remoteproc driver to activate or assign them.
Your firmware has to register and activate the interrupt by itself. If Linux complains about your interrupt, you probably routed it to the wrong CPU.
Kind regards, Mike Looijmans System Expert TOPIC Products Materiaalweg 4, NL-5681 RJ Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
