Altera PCI Express Development Kit: Linux DMA Driver

BAR[2] is 32 bit.

BAR[0] is 64 bit.

My IRQ pin =0.

What does it meen?

I can't request an IRQ line?

Here is the dmesg.

Enabled MSI interrupting.

Using a 64-bit DMA mask.

IRQ pin# 0 (0=none, 1=INTA#...4=INTD#).

IRQ line# 0.

What can be the reason?

Maybe I have to install Quartus on Linux?

Hi all,

I'm using the PCIe high performance reference design (on the Arria II GX board) on a host that uses legacy mode interrupts. I see the Arria II GX generate an "assert INTA" message followed immediately by a "deassert INTA" message once the descriptor table entry gets processed (I have interrupts only enabled on the last entry in the table). The host sees the interrupt and the ISR is called. However, I don't know what to do to acknowledge the legacy mode interrupt to the reference design, and the FPGA keeps doing the assert/deassert cycle every 39.5uS until the DMA controller is reset.

I didn't see any documentation on acknowledging interrupts. Anyone know what the chaining DMA design wants (in legacy interrupt mode)?

Thanks,

Tony

Arria is on PCIe bus.PCIe has his own interrupt controller,so there are no physical interrupts.They are virtual.In my case I received a IRQ#4538 line using Linux.

To start DMA read/write you have to write the number of descriptors to transfer, to the &read_header->w3 in the altpciechdma driver.

Example:iowrite32(n,&read_header->w3).

Look through the driver source code.

Everything is commented.

ug_pci_express.pdf has the description of the Altera MegaCore function.

Read /Documents/DMA.txt in your Linux documentation to better understand the chaining DMA.

This is what I have learned. I will share in case others run into the same problem.

The Altera reference design can use either MSI interrupts or "Legacy Mode" interrupts on the PCIe bus. In Legacy Mode, physical interrupt lines are emulated throught PCIe messages (Assert INTA, Deassert INTA). The way the reference design works is that in Legacy Mode (when MSI is not enabled), the Assert INTA message is sent by the core instead of an MSI, and then the Deassert INTA message is sent immediately after. This is not the way Legacy Mode interrupts are supposed to work. The FPGA should HOLD INTA (not send the Deassert INTA message) until after the interrupt service routine has verified that the Arria is the source of the interrupt and has acknowledged the interrupt to the Arria through some memory transaction (on the same traffic class as the DMA). In order to properly use Legacy Mode interrupts, this interaction has to be added to the reference design and to the Linux driver (interrupt service routine).

If the design is used "as is", it is possible that the interrupt service routine will never be dispatched as the deassertion of the interrupt can happen before the kernel ever has a chance to call the registered ISR.

The design is easily modified to add the required handshaking from ISR to FPGA by adding a register to BAR2 (I'm using the upper 16 bits of the Error Status Register). The ISR then needs to read/write this register to acknowledge the interrupt.

Hi,

maybe someone can help me here. I use an adapted version of the Linux DMA Driver. I succeeded in reading and writing BAR0, but I do not get the legacy interrupts to work. I work with an SOPC system and a PIO with level interrupts, the interrupt works fine with a NIOS but does not reach my PCIe root board.

How can I check if INTA is asserted or cleared? DariusTDog mentioned he can see that INTA is asserted... how?

Thx

Sorry for the slow response.

I observed the legacy-mode interrupts using a PCIe analyzer. The Assert INTA message was sent, immediately followed by the Deassert INTA message.

If you are running Linux, you can look at /proc/interrupts to see how many interrupts have been seen by the kernel.

DariusTDog

I have seen a problem with the high performance PCIe reference design chaining DMA on an Aria IIGX development board. If you program the upper address for a descriptor table entry (which would be required under a 64 bit OS or 32 bit+PAE kernel), the DMA engine should generate a 4DW read request (for PC -> endpoint transfer), but it does not, it instead only generates a 3DW read request, so in essence it is reading the wrong memory location. I have captured the transactions on a PCIe protocol analyzer.

I am using 32 bit Linux with PAE enabled. You just won't see it under most Windows since only 64 bit Windows or server Windows with PAE enabled would have pages above 4G.

I haven't tried the other direction (endpoint -> PC) yet. I need to protect the system since if the same bug happens, the OS will likely crash and burn once the wrong memory gets trashed.