04-04-2019 11:24 AM
I am using eval board and trying to use the QDMA in vivado 2018.3 & using standard QDMA drivers from Xilinx. I am using gen3x4 and have the correct device id as 9034 in the configuration. When I try to load the drivers I see the below error.
[ 580.529125] qdma:hw_indirect_ctext_prog: ctxt_cmd reg 0x844, qid 0x0, op 0x0, sel 0x2 -> 0x00000004.
[ 581.029071] qdma:hw_indirect_ctext_prog: qdma03000-p0000:03:00.0, Q 0x0, op 0x0, sel 0x2, timeout.
[ 581.029073] qdma:qdma_device_online: qdma_init failed -16.
Can someone help me whats can be the issue be in the QDMA hardware configuration
04-09-2019 03:39 PM
Has anyone seen this Error before? Is there a QDMA Bloack design I can use? There is an example design but I am not able to port it to the fidus board I am using.
05-13-2019 02:03 AM
First can you ensure the patch for known issues in AR:72013 has been applied. Please see the following link.
What evaluation board are you using and what Linux system? Are you using the drivers provided in the dma_ip_drivers on Github as per AR:70928 - https://www.xilinx.com/support/answers/70928.html
Please refer to the User Guide that is provided with the dependencies for these drivers and the steps to run them. Are you following these and at what stag do you see this failure?
05-13-2019 05:07 AM
I am using an HTG-930 from High Tech global with a VU9P. I managed to get the XDMA working so I'm fairly confident of my provided constraints.
I have applied the patches from AR72013, but it didn't change the original issue.
I explain my setup a little more in detail on the github website
I have a little design that connects a BRAM to both an AXI lite and the AXI MM interface on the QDMA.
I do not have any connections on the `user_irq`, `dsc_crdt_in`, `st_rx_msg`, nort the `tm_dsc_sts` interfaces.
The `soft_reset_n` is left unconnected.
The `sys_rst_n` is connected to `pcie_perst_n`.
The QDMA driver identifies the device, and starts to initialize the contexts, but always freezes at `sel = 2` (`QDMA_CTXT_SEL_HW_C2H`).
Are there any required connections to those 4 interfaces?
relevant output of `dmesg` (let me know if you need any more)
[ 2.265727] qdma_vf:qdma_mod_init: Xilinx QDMA VF Reference Driver v2018.3.97.161. [ 2.286150] qdma:qdma_mod_init: Xilinx QDMA PF Reference Driver v2018.3.97.161. [ 2.303268] qdma:probe_one: 0000:01:00.0: func 0x0/0x4, p/v 0/0,0x (null). [ 2.303269] qdma:probe_one: Configuring '01:00:0' as master pf [ 2.303270] qdma:probe_one: Driver is loaded in auto mode [ 2.303271] qdma:qdma_device_open: qdma_pf, 01:00.00, pdev 0x (ptrval), 0x10ee:0x903f. [ 2.303278] qdma_pf 0000:01:00.0: enabling device (0000 -> 0002) [ 2.303356] qdma:xdev_identify_bars: QDMA Config BAR passed by the user matches with the identifier register value(0x1fd30000) [ 2.303358] qdma:xdev_identify_bars: User BAR 2. [ 2.303363] qdma:qdma_device_attributes_get: qdma01000-p0000:01:00.0: present flr 0, mm 1, st 0. [ 2.303364] qdma:qdma_device_init: qdma01000-p0000:01:00.0 master PF clearing memory. [ 2.802001] qdma:hw_indirect_ctext_prog: qdma01000-p0000:01:00.0, Q 0x0, op 0x0, sel 0x2, timeout. [ 2.802008] qdma:qdma_device_online: qdma_device_init failed -16.
The example design seems to have logic connected to all the interfaces I left untouched. So I'm thinking it has something to do with that. It seems the only example design is Figure 32: Default Example Design. For what it is worth, I was able to load that onto the HTG-930, and get a little further along in the device initialization. It seemed t o do what it needed, and the user utility listed the device as avaiable. I never had the time to test mapping different queues to data transfers from the Host.
I had a hard time creating the other example designs that are described in PG302.
My system is closes to Figure 33: AXI4 Memory Map Example Design
05-13-2019 07:57 AM
Connect st_rx_msg_rdy, tm_dsc_sts_rdy and soft_reset_n to 1'b1. Let us know the result.
05-13-2019 08:01 AM
Great thanks for the tip.
I tried to connect soft_reset_n to 1, but looking at the schematics that were generated by omitting that signal, it seemed that it correctly got the 1 value as default.
I had not connected the ready signals to high, but had identified those as potential sources of issues. I'll try to generate the design and test it today.
05-13-2019 09:32 AM
Great I can confirm that those 3 connections help the driver successfully boot up.
I assume I will have to connect them to something meaningful at a later time, but it helps us move forward.