Forum Discussion
Altera_Forum
Honored Contributor
12 years agoOk fixed half of this issue ...
The Linux device driver I have written ( based on other examples ), enables the PCIe endpoint from the probe function and that leaves the device command register at 0x00000142 . I was not getting any requester traffic either where NIOS or DMA initiates the read or write. Anyway I needed to add the system call pci_set_master(dev) to enable the device for mastering ( requester in addition to completer ). I am now able to have the system as the "producer" and the NIOS as the "consumer" where the producer sets the data complete flag in system memory and the "consumer" polls that flag then reads the data from NIOS memory, sets a status in NIOS memory that indicates the data is consumed and the "producer" polls that flag and the cycle repeats. The second issue I have relates to setting up the PCIe core Avalon MM -> PCIe address translation .. this is at a table with 2 entries of 4k bytes each. I am trying to track it down . This Cra register space is accessed via BAR1 and contains the physical address of the system DMA memory address. For some reason , that BAR1 write is ending up at a different location in IMEM that is just below the Cra space . I have an idea it could be something to do with the BAR address matching scheme and reference to NIOS address map. The IMEM is at 0x00010000 - 0x0001ffff and the CRA slave is at 0x00020000 - 0x00023fff ... the write to the translation tables at offest 0x00021000 in the CRA space seems to end up at 0x00011000 in the IMEM. Thanks, Bob.