09-13-2012 05:46 AM
I have a ZC702 Zynq evaluation board running Linux from the included SD card.
What I would like to do is create a std_logic signal in a user IP peripheral, and use that signal to trigger an interrupt to the processor, which in turn causes an interrupt-handler function to run. This is all under the Linux environment, not the standalone OS. I'm getting hung up somewhere, but I'm not entirely sure what my error is, or if I'm going about something completely wrong.
Here is what I do in XPS.
-- Create a std_logic signal in user_logicl.vhd (we'll call it "PL_INTERRUPT"). Route it to the top level of the user IP peripheral as an output.
-- Open the user IP peripheral's MPD file and add this port as an interrupt like this:
PORT PL_INTERRUPT = "", DIR = O, SIGIS = INTERRUPT, SENSITIVITY = EDGE_RISING, INTERRUPT_PRIORITY = MEDIUM
-- Click Project -> Rescan User Repositories. In the "Ports" tab PL_INTERRUPT should now appear as an interrupt under its peripheral.
-- Add an AXI Interrupt Controller from the IP Catalog. When prompted, indicate to have XPS automatically make connections to the processor.
-- Click the interrupt's "Connected Port" field in the "Ports" tab, which opens the Interrupt Configuration Dialog.
-- Set "Interrupt Controller" to "axi_intc_0", then double-click the PL_INTERRUPT entry to connect it to the AXI INTC.
-- Set "Interrupt Controller" to "processing_system7_0" and double-click "axi_intc_0_Irq" to connect it to the processor.
-- You can now see the axi_intc's S_AXI_ACLK is connected to one of the processor's FCLKs, and that its "Irq" port is connected to the processor's IRQ_F2P, although its parent "(BUS_IF) INTERRUPT" is indicated as "Not connected to BUS or External Ports". This may or may not be a problem, but it does not seem as though I can actually connect it to anything, other than making it an external port.
-- Generate the netlist. This is successful, but it generates a warning:
INTC_WARNING:: IRQ is not connected to Processor.
Except this is clearly not the case as shown in the "Ports" tab. This may or may not be important.
Here is where I presume my work in XPS is done. My major roadblock occurs when I try to register interrupts in a Linux app in SDK.
I’m trying to get a simple programmable-logic interrupt input working under the Linux environment on the ZC702 eval board, and nearly all references on this mention a Linux function used to register interrupt channels, "request_irq()", including this Xilinx forum, where they mention this function, although the topic of the forum is different from my issue, and it is possible they're building their Linux ARM code under a different compiler, or they might be using a custom kernel. This function is also mentioned in the scope of Microblaze and PowerPC interrupt handling under Linux on Xilinx chips.
Several websites that mention this function indicate a group of header files that need to be brought in to configure interrupts (request_irq() and presumably other interrupt-related functions). These include:
linux/interrupt.h and asm/irq.h don’t seem to exist in 14.2, and so they and their associated functions cannot be called.
linux/signal.h does exist, but throws an error at compile time if <stdlib.h> is also included, due to a conflicting definition of the type "sigset_t". This may not be a problem with the SDK libraries specifically.
linux/sched.h just defines a set of constants and can be included without any issues, but doesn’t contain any function declarations.
I see a lot of references to this function for the Microblaze processor for Linux kernel version 2.6.x, although the ZC702 board is running version “3.0.0-14.1-build3-01350-gffde6d9”. There may be a difference in the header libraries between those versions. There is some mention of modifying DTS device tree files and building separate kernel modules that handle interrupts, but I am not sure what part these might play since mapping and programming interrupts is fairly new to me.
Can anyone help with this? I've found reference designs implementing PL-to-PS interrupts for the standalone OS, but after weeks of searching it seems as if there's no documentation whatsover for doing the same thing in a Linux application for Zynq in 14.2. Some of the information I found (which I forgot to save) seemed to hint that configuring interrupts this way does not work on the cortex-a9 architechture under Linux, so that's a possibility as well. It would be really great to get this working, so if I need to provide more information I can.
09-13-2012 07:38 AM
Have you filed a webcase?
As a customer (you bought the board), you should be able to file a webcase, and get an answer much faster than hoping someone reads your post, and knows what to tell you....
Xilinx San Jose
09-13-2012 07:58 AM
I've had a webcase open for about three weeks with little success. Without going into too much detail, it's apparent that the FAE assigned to my case does not really understand my problem or my goal. My hope is that someone here on the forums will have tried to implement something similar, and therefore have some advice to offer. I'm not looking for a how-to, just a push in the right direction.
09-13-2012 08:08 AM
I agree that is unacceptable: I will follow up for you.
What is the case number?
Please email me directly at: firstname.lastname@example.org
Xilinx San Jose
09-27-2012 07:12 AM
Have you looked at UIO? It is a generic linux driver which allows you to do all the device specific stuff inside the user space. I use it for interrupt handling and it is very convenient. You don't have to recompile the kernel if you change bits on the driver of an IP core.
10-09-2012 07:38 AM
I am having the same problem: after adding an AXI Interrupt Controller (1.02a) to my ZedBoard design in Xilinx XPS 14.2, the Design Rule Check says:
"INTC_WARNING:: IRQ is not connected to Processor.
ERROR:EDK - axi_intc_0 (axi_intc) - can't read "mb_clk": no such variable"
As you said, there's no way to connect the "(BUS_IF) INTERRUPT", except to make it external.
This is the only Google result for this warning. Did you fix it? Is there a workaround, like modifying the MPD?
01-07-2013 03:49 AM
I'd like to know if this problem has been solved. I'm interested in doing something similar to esagr project.
Unfortunately I'm facing another problem: when I try to perform a Design Rule Chek I get " IRQ is not connected to Processor" as an error, not a warning. For this reason I'm not able to synthesize my code and to migrate to SDK. I noticed that is possible to interconnect the interrupt signal coming from the peripheral directly to IRQ_F2P port of the processing system without getting neither error or warning. In this way I'm able to generate bitstream, but I think is not the correct solution especially because I'm planning to use more component able to generate their own interrupts. In brief:
1) I need to instantiate an interrupt controller in PL whithout generating errors (Note: I've already followed esagr steps)
2) I need to manage interrupts from Linux. Assuming that I want to manage them in a bare metal application, what should I do? what libraries/functions do I have to include?
01-11-2013 11:04 AM - edited 01-11-2013 11:31 AM
This isn't a solution to the AXI interrupt controller connection issue, but it may help you get interrupts working in Linux. The PS has 16 IRQ inputs connected to an interrupt controller (GIC) in the APU. As sticken said, interrupt ports from the PL (such as your PL_INTERRUPT port) can be connected directly to the PS using the IRQ_F2P port without the need for an AXI interrupt controller (this can be done by clicking the IRQ section in the Zynq tab and connecting the interrupts in the same manner as an AXI interrupt controller). Xilinx has a standalone example design that uses this method:
You may have more success in Linux by using the PS's IRQ ports and interrupt controller directly instead of trying to handle them in the PL first with an AXI interrupt controller.
05-13-2013 12:46 AM
I did project with zedboard I added my simple own ip who copy the status of ths switch on led when the led is on I want call function handler with the xsdk.