Forum Discussion
Occasional ContributorIssues when testing DMA feature provided by Avalon MM+ IP with S10 GX dev kit card on Ubuntu 18.04
The problem you seen might related to below KBD
Why does the Intel® Stratix® 10 Avalon®-MM Interface for PCIe* with DMA example design fail the link test and the DMA test when using the default selected BAR0?DescriptionWhen the internal DMA Descriptor Controller is enabled, the BAR0 Avalon®-MM master is not available for general-purpose usage. The DMA Descriptor Controller uses this BAR0 interface through which the host CPU programs in the descriptor table.
The intel_fpga_pcie_link_test user application selects BAR0 as default when it's initially executed. If the user forgets to change to BAR2, which is where the onchip memory is attached, then both the link test and the DMA test will fail.
ResolutionThe user must change to BAR2 before executing the link test and the DMA test.
See the execution transcript of the intel_fpga_pcie_link_test user application below for how to change to BAR2.
~$ sudo ./intel_fpga_pcie_link_test
*********************************************************
Intel FPGA PCIe Link Test
Version 2.0
0: Automatically select a device
1: Manually select a device
*********************************************************
> 0
Opened a handle to BAR 0 of a device with BDF 0x1300
*********************************************************
0: Link test - 100 writes and reads
1: Write memory space
2: Read memory space
3: Write configuration space
4: Read configuration space
5: Change BAR
6: Change device
7: Enable SRIOV
8: Do a link test for every enabled virtual function
belonging to the current device
9: Perform DMA
10: Quit program
*********************************************************
> 5
Changing BAR...
Enter BAR number (-1 for none):
> 2
Successfully changed BAR!
Occasional ContributorAlso I have tested a simply read & write operation.
//... result = dev->write32(reinterpret_cast<void *>(addr), write_data); if (result == 1) { cout << "Wrote successfully!" << endl; } else { cout << "Write failed!" << endl; } uint32_t test_read = 0; result = dev->read32(reinterpret_cast<void *>(addr), &test_read); if (result == 1) { cout << "Read successfully!" << endl; } else { cout << "Read failed!" << endl; } cout << "Read number : " << test_read << endl; //...
Get the wrong result again.
> Enter address to write, in hex: 0000f000 > Enter 32-bit data to write, in hex: 12341234 > Writing 0x12341234 at BDF 0x1a00 BAR 0 offset 0xf000.. Wrote successfully! Read successfully! Read number : 0xffffffff
Read number is 0xffffffff, similar with Doing 100 writes and 100 reads test. This time the using address is manually set, not NULL.
ContributorAs I understand it, you are testing the PCIe link-up on Stratix 10 SX SoC Development Kit (DK-SOC-1SSX-L-D) as described below on Ubuntu by modifying some driver code from provided for CentOS.
https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/stratix/10-sx.html
I'm not clear if the issue was caused by the driver code modification itelf.
However in the first place, are you able to check if the PCIe is able to link-up? i.e. using lspci to check.
Do you have any PCIe endpoint card plug-in into this SOC dev kit which act as rootport? or you are using the BTS (Board Test System) to test the loopback?
- He4Forum
Hi skbeh,
I am using Stratix 10 GX FPGA Development Kit (DK-DEV-1SGX-L-A). And I have checked that the FPGA card could be detected via PCIe.
$ lsmod | grep intel_fpga_pcie_drv intel_fpga_pcie_drv 32768 2 $ lspci -d 1172:000 -v 1a:00.0 Unassigned class [ff00]: Altera Corporation Device 0000 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: intel_fpga_pcie_drv Kernel modules: altera_cvp $ lspci -d 1172:000 -v | grep intel_fpga_pcie_drv Kernel driver in use: intel_fpga_pcie_drvThe FPGA card is just plugged into a PCIe port on a host machine with Ubuntu 18.04 OS.
As the README for the driver for FPGA card says,
TESTING ------- The driver was developed and tested on CentOS 7.0, 64-bit with 3.10.514 kernel compiled for x86_64 architecture.and when I installed the card with no modifications, it would meet errors. Seems that the errors are caused by the Linux kernel version, 5.10 on my machine and 3.10 in README introduction. I fixed the bugs manually and got the driver successfully installed.
- skbeh
You run the PCIe link test in manual or automatic mode?
— In automatic mode, the application automatically selects the device. The test selects the Intel Stratix 10 PCIe device with the lowest BDF by matching the Vendor ID. The test also selects the lowest available BAR (which is BAR0).
— In manual mode, the test queries you for the bus, device, and function number and BAR.The other thing you can try is instead of selecting option 0 to automatically select the device, you try option 1 and manually select it.
In manual mode, use below command to determine the BDF.
$ lspci -d 1172Then, enter the BDF and use BAR 2 for manual test, screenshot below show the manual test steps.
- skbeh
The problem you seen might related to below KBD
Why does the Intel® Stratix® 10 Avalon®-MM Interface for PCIe* with DMA example design fail the link test and the DMA test when using the default selected BAR0?DescriptionWhen the internal DMA Descriptor Controller is enabled, the BAR0 Avalon®-MM master is not available for general-purpose usage. The DMA Descriptor Controller uses this BAR0 interface through which the host CPU programs in the descriptor table.
The intel_fpga_pcie_link_test user application selects BAR0 as default when it's initially executed. If the user forgets to change to BAR2, which is where the onchip memory is attached, then both the link test and the DMA test will fail.
ResolutionThe user must change to BAR2 before executing the link test and the DMA test.
See the execution transcript of the intel_fpga_pcie_link_test user application below for how to change to BAR2.
~$ sudo ./intel_fpga_pcie_link_test
*********************************************************
Intel FPGA PCIe Link Test
Version 2.0
0: Automatically select a device
1: Manually select a device
*********************************************************
> 0
Opened a handle to BAR 0 of a device with BDF 0x1300
*********************************************************
0: Link test - 100 writes and reads
1: Write memory space
2: Read memory space
3: Write configuration space
4: Read configuration space
5: Change BAR
6: Change device
7: Enable SRIOV
8: Do a link test for every enabled virtual function
belonging to the current device
9: Perform DMA
10: Quit program
*********************************************************
> 5
Changing BAR...
Enter BAR number (-1 for none):
> 2
Successfully changed BAR!
