cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sberner66
Observer
Observer
827 Views
Registered: ‎10-06-2018

ZCU104 -- aurora module does not lock when Petalinux kernel is running

Jump to solution

The aurora module instantiated in the PL area works fine when loading the FPGA bit file and the r5_0 firmware via JTAG while the a53 is shut down. When loading the FPGA bitfile and the r5_0 firmware from Petalinux with FPGA manager and remotproc, the PLL in the aurora module does not lock. The reference clock is synthesized by the 8T49N241 and has not changed. Cause ?

0 Kudos
1 Solution

Accepted Solutions
sberner66
Observer
Observer
818 Views
Registered: ‎10-06-2018

Further investigation revealed that the reset input is not forwarded to sys_reset_out. The next step was to look closer at the init_clk frequency. It turned out that the init_clk frequency changed from 7.109 MHz in standalone operation to 7.258 MHz with linux. init_clk is taken from a PLL in the PS area and dmesg indicates that linux messes around with the PLL(s) during boot. Therefore, I changed the design and derived init_clk differently, using the 125 MHz reference and adding a PLL in the PL area which solves the problem.

I am aware that the ref_clk frequency has to match exactly what's stated in the configuration GUI, but I am surprised that the frequency of init_clk is so critical.

Conclusion is that the ref_clk frequency as well as the init_clk frequency have to match EXACTLY what's stated in the aurora config GUI.

View solution in original post

0 Kudos
1 Reply
sberner66
Observer
Observer
819 Views
Registered: ‎10-06-2018

Further investigation revealed that the reset input is not forwarded to sys_reset_out. The next step was to look closer at the init_clk frequency. It turned out that the init_clk frequency changed from 7.109 MHz in standalone operation to 7.258 MHz with linux. init_clk is taken from a PLL in the PS area and dmesg indicates that linux messes around with the PLL(s) during boot. Therefore, I changed the design and derived init_clk differently, using the 125 MHz reference and adding a PLL in the PL area which solves the problem.

I am aware that the ref_clk frequency has to match exactly what's stated in the configuration GUI, but I am surprised that the frequency of init_clk is so critical.

Conclusion is that the ref_clk frequency as well as the init_clk frequency have to match EXACTLY what's stated in the aurora config GUI.

View solution in original post

0 Kudos