cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
499 Views
Registered: ‎09-06-2019

VTC probe causing kernel panic

Jump to solution

i I have a design with a VTC in the PL and instantiated in the generated device tree as follows (using 2019.1 tools)

	analog_out_0_v_tc_0: v_tc@a0020000 {
		clock-names = "clk", "s_axi_aclk";
		clocks = <&misc_clk_1>, <&zynqmp_clk 71>;
		compatible = "xlnx,v-tc-6.1";
		interrupt-names = "irq";
		interrupt-parent = <&gic>;
		interrupts = <0 106 4>;
		reg = <0x0 0xa0020000 0x0 0x10000>;
		xlnx,generator;
	};

During booting of the kernel, the probe of xvtc causes a kernel panic:

[    2.085759] xilinx-video vcap_rx: /vcap_rx/ports/port@0 initialization failed
[    2.092762] xilinx-video vcap_rx: DMA initialization failed
[    2.099658] Internal error: synchronous external abort: 96000210 [#1] SMP
[    2.105040] Modules linked in:
[    2.108070] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.0 #1
[    2.113949] Hardware name: xlnx,zynqmp (DT)
[    2.118103] pstate: 60000005 (nZCv daif -PAN -UAO)
[    2.122867] pc : xvtc_probe+0x94/0x120
[    2.126581] lr : xvtc_probe+0x84/0x120
[    2.130299] sp : ffffff800803bbc0
[    2.133586] x29: ffffff800803bbc0 x28: 0000000000000007
[    2.138863] x27: ffffff8008dd3068 x26: ffffff8008d65c90
[    2.144140] x25: 0000000000000000 x24: ffffff8008e53498
[    2.149417] x23: ffffff8008e77000 x22: 0000000000000000
[    2.154694] x21: ffffffc87fff2b60 x20: ffffffc87b034010
[    2.159971] x19: ffffffc87bb49c18 x18: ffffffffffffffff
[    2.165248] x17: 00000000bc06f11c x16: 000000001806bcfa
[    2.170525] x15: ffffff8008df8648 x14: ffffffc87ad9fa0a
[    2.175803] x13: ffffffc87ad9fa09 x12: 0000000000000000
[    2.181080] x11: 0000000000000020 x10: 0101010101010101
[    2.186357] x9 : 0000000000000000 x8 : ffffffc87ad9f880
[    2.191634] x7 : 0000000000000000 x6 : 0000000000000003
[    2.196911] x5 : 0000000000000000 x4 : 0000000000000000
[    2.202188] x3 : ffffff8008ee0f08 x2 : ffffff800b440010
[    2.207465] x1 : ffffff8008ee0f20 x0 : 0000000000000000
[    2.212743] Process swapper/0 (pid: 1, stack limit = 0x(____ptrval____))
[    2.219403] Call trace:
[    2.221827]  xvtc_probe+0x94/0x120
[    2.225203]  platform_drv_probe+0x50/0xa0
[    2.229181]  really_probe+0x220/0x3d0
[    2.232814]  driver_probe_device+0x68/0x150
[    2.236966]  __driver_attach+0x11c/0x140
[    2.240859]  bus_for_each_dev+0x74/0xd0
[    2.244665]  driver_attach+0x20/0x30
[    2.248212]  bus_add_driver+0x1f4/0x280
[    2.252019]  driver_register+0x60/0x110
[    2.255825]  __platform_driver_register+0x40/0x50
[    2.260498]  xvtc_driver_init+0x1c/0x24
[    2.264304]  do_one_initcall+0x5c/0x180
[    2.268110]  kernel_init_freeable+0x148/0x1f0
[    2.272436]  kernel_init+0x10/0x100
[    2.275896]  ret_from_fork+0x10/0x24
[    2.279443] Code: 37f803e0 f940a662 f9004e93 91004042 (b9400042)
[    2.285500] ---[ end trace 638f5d346635590a ]---
[    2.290097] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.290097]
[    2.299167] SMP: stopping secondary CPUs
[    2.303059] Kernel Offset: disabled
[    2.306519] CPU features: 0x0,20802004
[    2.310237] Memory Limit: none
[    2.313268] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.313268]  ]---

I've verified that I can successfully boot when I removed the node from my tree. Can someone help to explain why this driver causes a kernel panic and how I can fix this? Thanks!

 

1 Solution

Accepted Solutions
Highlighted
Explorer
Explorer
262 Views
Registered: ‎09-06-2019

Hi @pfuhrman,

Yes we did eventually resolve it. Our issue was that our FSBL was built using an HDF generated from a slightly different PS configuration.

The PS generated clock frequencies were changed but we never went back and updated the FSBL in our bootloader therefore the clocks generated by the PS did not match the expected frequencies by the driver/device tree eventually causing the panic. Fixing the FSBL fixed the issue.

 

View solution in original post

3 Replies
Highlighted
Visitor
Visitor
277 Views
Registered: ‎02-20-2014

Heh badFITimage, I've got exactly same panic signature with xvtc, in the design example for https://projects.digilentinc.com/adam-taylor/high-performance-imaging-ac156d, building for Linux instead of baremetal. Same 2019.1 tools. 

Did you ever figure out the root cause, or come up with another way around the issue? 

 

0 Kudos
Highlighted
Explorer
Explorer
263 Views
Registered: ‎09-06-2019

Hi @pfuhrman,

Yes we did eventually resolve it. Our issue was that our FSBL was built using an HDF generated from a slightly different PS configuration.

The PS generated clock frequencies were changed but we never went back and updated the FSBL in our bootloader therefore the clocks generated by the PS did not match the expected frequencies by the driver/device tree eventually causing the panic. Fixing the FSBL fixed the issue.

 

View solution in original post

Highlighted
Visitor
Visitor
260 Views
Registered: ‎02-20-2014
Thanks much! That gives me a direction to look.
0 Kudos