cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,323 Views
Registered: ‎09-30-2011

Zynq AXI DMA ERROR: could not get clock s_axi_lite_aclk

Jump to solution

I am running a Zynq design that has both the AXI DMA and AXI CDMA specified in it. I am using the attached device tree. When I boot Linux with this device tree, I get the following error message:

 

ERROR: could not get clock /dma@40800000 : s_axi_lite_aclk(0)

 

and then

 

ERROR: could not get clock /dma@40400000 : s_axi_lite_aclk(0)

 

each corresponding to the DMA and CDMA instances. After some research, it appears that the problem ought to be a missing clocks definition in the device tree, like this:

 

clocks = <clkc, 15>, <clkc, 15>, <clkc, 15>, <clkc, 15>;

 

for the 4 clocks in the AXI DMA device tree specification (after the clock_names) and just 2 entries for the CDMA.

 

When I run that device tree, boot hangs when getting to that part of the boot sequence where it parses the device tree entries for the DMA.

 

So something is wrong, I just don't know what. Can I not have AXI DMA and CDMA simultaneously? If I do have these DMA engines running simultaneously, are there some considerations that need to be applied? Or, am I not specifying the clocks correctly? Am I missing something in the device tree? The confounding thing is that a similar design without the CDMA added worked without issue on the zc706 board.

 

Thanks for your help.

 

 

 

 

0 Kudos
1 Solution

Accepted Solutions
1,354 Views
Registered: ‎09-30-2011

OK. I figured this out and to serve the community I will summarize my findings.

 

First off, the generated device tree MUST HAVE the clocks parameter defined so that needed to be added to the device tree manually. With the device tree entry for the AXI DMA correctly defined, it was correctly loaded which led to the hang in the kernel boot.

 

By adding a series of illuminating printk statement to the sections of the kernel that parsed the AXI DMA device tree entry (I believe it was in xilinx_axidma.c) I was able to identify that hang occurred in parsing the DMA channel entry and specifically when the code turned to the DMA instance and attempted to reset it by writing to the DMA control register. In fact that reset involved a read/modify/write operation and read caused a hang.

 

After trying to address PS addresses with success (like the UART, say) and other PL-based addresses with hangs both from within Linux and using a simple bare metal application, I isolated the problem to something on the PS-PL interface.

 

Working with our FPGA designer who inserted ILA cores to monitor critical signals like clocks and resets, he identified that  his design was holding the PL logic in reset in error so all accesses to the PL would fail.

 

He fixed his design to not hold the PL in reset and then everything worked.

 

As a software person it is easy to fall into the trap that "it must be a software thing" especially when software changes make things look a little better or worse.

 

What is a real software issue is that the device tree for the AXIDMA MUST HAVE the line

 

 clocks = <clkc, 15>, <clkc, 15>, <clkc, 15>, <clkc, 15>;

 

added to it.

 

I hope this helps someone somewhere

View solution in original post

0 Kudos
1 Reply
1,355 Views
Registered: ‎09-30-2011

OK. I figured this out and to serve the community I will summarize my findings.

 

First off, the generated device tree MUST HAVE the clocks parameter defined so that needed to be added to the device tree manually. With the device tree entry for the AXI DMA correctly defined, it was correctly loaded which led to the hang in the kernel boot.

 

By adding a series of illuminating printk statement to the sections of the kernel that parsed the AXI DMA device tree entry (I believe it was in xilinx_axidma.c) I was able to identify that hang occurred in parsing the DMA channel entry and specifically when the code turned to the DMA instance and attempted to reset it by writing to the DMA control register. In fact that reset involved a read/modify/write operation and read caused a hang.

 

After trying to address PS addresses with success (like the UART, say) and other PL-based addresses with hangs both from within Linux and using a simple bare metal application, I isolated the problem to something on the PS-PL interface.

 

Working with our FPGA designer who inserted ILA cores to monitor critical signals like clocks and resets, he identified that  his design was holding the PL logic in reset in error so all accesses to the PL would fail.

 

He fixed his design to not hold the PL in reset and then everything worked.

 

As a software person it is easy to fall into the trap that "it must be a software thing" especially when software changes make things look a little better or worse.

 

What is a real software issue is that the device tree for the AXIDMA MUST HAVE the line

 

 clocks = <clkc, 15>, <clkc, 15>, <clkc, 15>, <clkc, 15>;

 

added to it.

 

I hope this helps someone somewhere

View solution in original post

0 Kudos