# Altera Cyclone V - Linux & FPGA interrupt handling

I need to propagate an interrupt from my custom FPGA IP core to the HPS system of a DE0_nano_SoC (Cyclone V HPS-FPGA architecture) and handle in Linux. I have googled quite a lot to confidently say that this topic is not well covered.

Required functionality

The custom FPGA IP core sets an interrupt signal. The HPS registers this signal (possibly writes to the custom FPGA IP core to de-assert the interrupt signal) and copies a few bytes from registers in the FPGA to a program running in Linux.

The choice of Linux is arbitrary, preferably Angstrom/Yocto, which I have running right now, but if the FreeRTOS would offer simpler implementation I would go for it.

My assumptions (please correct me if wrong)

1) The Interrupt Controller in the HPS recognices the FPGA generated interrupts, starting at the number 73 (there is some shifting, but in principle they are mapped with constant values).

2) Linux for ARM Cortex A9, is able to recognize vendor specific interrupts (for different peripherals like I2C0/1/2, UART0/1, etc).

Question

1) Does Linux recognize the interrupts from the FPGA, mapped by HPS Interrupt Controller?

2) Do I need to develop a driver, so that the Linux can recognize the FPGA interrupts ?

3) This seems to be quite important feature of the whole Cyclone V architecture. Hasnt Altera developed such drivers already, to handle simple FPGA-to-HPS interrupts in Linux ?

• This is device specific. Better post this in altera form. – Mitu Raj Dec 16 '17 at 11:43
• @MITURAJ It's not actually device specific. It's OS specific. – Tom Carpenter Dec 16 '17 at 11:59

The HPS bridge is designed to take FPGA interrupts and feed them in to the general interrupt controller (GIC) within the ARM processor. As far as the processor is concerned, interrupts from the FPGA are no different from interrupts from any other source. Just like the I2C or UART peripherals, FPGA interrupts invoke the same response in the GIC.

The Linux kernel has already been customised for the specific processor and interrupt controller. The kernel already knows how to react to an interrupt - it simply executes whatever interrupt handler (ISR) that has been set up by the kernel to handle a specific interrupt. In the event of an interrupt source that doesn't have a handler set up, it will likely have a default handler that silently disposes of the interrupt (likely by just ignoring it).

So how do you handle it? The same way any other interrupt is handled - a driver. You have to provide some code, driver software, that registers an interrupt handler for the specific interrupt source. For example there are already drivers provided for the I2C and UART peripherals, these will have interrupt handlers.

There are many useful documents on the internet for driver handling, a quick Google search found this which seems quite good. From there we can see that interrupts all have a number, the handlers for which can be seen by running the command cat /proc/interrupts. In your case you won't see anything for interrupt number 73 (the first FPGA interrupt) as there is no driver set up to handle it.

TL;DR; You need to write a Linux driver. There is nothing special that needs to be done to account for the fact that the interrupt comes from the FPGA, that is already taken care of in hardware by the HPS bridge.

• I suspect you're glossing over the hardest part of all of this -- the devicetree updates that will have to be done to let the kernel know what is hooked up to which interrupt, which memory ranges are used or the general bus configuration so you can access the FPGA side hardware. – akohlsmith Dec 16 '17 at 16:24
• @akohlsmith quite possibly, but my answer is not intended to be a complete instruction manual, as the "how" bit of writing a driver will depend on a lot of information that is not given in the question. The take away point is that going from FPGA to HPS is already taken care of in hardware, so writing a driver for a peripheral in the FPGA becomes no different from any memory mapped peripheral (e.g. a PCIe device). – Tom Carpenter Dec 16 '17 at 16:51
• Exactly -- my point was that the device driver is the easy part. Devicetree has driven many a kernel hacker insane. – akohlsmith Dec 17 '17 at 6:20