Dear community,
We meet the hung problem when booting custom board .
[Background]
When the iMX6DL boots up from uboot, the iMX6DL may freeze.
The outbreak frequency is one of several thousand times.
Then, the JTAG debugger connection is not possible,
it is in a condition that the iMX6 is hung up ,it is not an infinite loop .
We made 50 pieces of custom board. A problem occurs with one or two pieces.
We are investigating the uboot code.We find the hung up point as follows.
u-boot-2009.08/drivers/video/ipu_common.c
ipu_pixel_clk_set_parent (struct clk *clk, struct clk *parent)
{ u32 di_gen = __raw_readl(DI_GENERAL(clk->id)); <= Here it is !
The uboot version is u-boot-2009.08 (L3.0.35_4.1.0_130816_source.tar.gz)
We attached the function call diagram, as follows.
[Question]
Could you advise a check point to us for solving this issue ?
Best Regards,
Koichi Sakagami
Hi,
After this line u32 di_gen = __raw_readl(DI_GENERAL(clk->id)
does the device go to an exception? Have you tried to attach the debugger when the processor hangs and check the status of the cortex?
Best Regards,
Alejandro
Dear Alejandro san,
Having investigated it, we got an additional information.
When the processor hangs the "ipu1_hsp_clk_root" stops.
( We confirmed it with outputting the "ipu1_hsp_clk_root" signal to CCM_CLKO2 pin.)
We think that this is the cause of hung-up.
What is the reason why a ipu1_hsp_clk_root ( pll3 pfd1) stops ?
Could you advise a check point to us for solving this issue ?
Best Regards,
Koichi Sakagami
Hi Koichi Sakagami,
Just to double check, you have only 1-2 boards failing with a rate failure of 1/1000 correct?
Can you share the changes you have performed in U-Boot?
If you change the clock source to be pll3_120M instead of PLL3_PFD1 do you have the same behavior? Are you able to see this signal in the CLKO2 pin?
Have you checked the datecode of the devices that are causing issues?
Best Regards,
Alejandro
Dear Alejandro san,
We have only 2 boards failing with a rate failure of 1/5000.
We changed the clock source to be pll3_120M.We have the same behavior.
We have checked the datecode. They are not causing issues.
We are trying to get the momentary information that PLL stop .
We will report the results when known.
Best Regards,
Koichi Sakagami
Dear Alejandro san,
We investigate momentary information that ipu1_hsp_clk_root stops .
1: The ipu1_hsp_clk_root stops when CCM_CSCDR3[ipu1_hsp_clk_sel] is modified.
2: Then the PLL3_PDF1 does not stop.
We confirmed it with outputting the "video_27M_clk_root" signal to CLKO1 pin .
We can see PLL3_PDF1 that is running.
We assume that the ipu1_hsp_clk_root stopping cause is not PLL3_PDF1
but a clock multiplexer which is set by CCM_CSCDR3[ipu1_hsp_clk_sel].
[Question]
Could you tell us the way to set the right sequence about PLL lock and clock-multiplexer setting ?
To say about the uboot code ,the CCM_CSCDR3[ipu1_hsp_clk_sel] is modified after the PLL3 locked.
When we changed the sequence of PLL lock and clock-multiplexer setting,
(before the PLL3 locked ,the CCM_CSCDR3[ipu1_hsp_clk_sel] is modified)
the number of times that a phenomenon happens decreases.
We continue to inspect whether it does not occur or not completely.
Best Regards,
Koichi Sakagami
****************
Hi,
Have you tested removing the IPU and its corresponding clock initialization? just to make sure that is the problem.
Best Regards,
Alejandro
Dear Alejandro san,
Have you reproduced the phenomenon on your boards ?
We continue to execute the code switching over the clock multiplexer (CCM_CSCDR3[ipu1_hsp_clk_sel]) in uboot .
As a result,
The phenomenon occurred with the high frequent board in around ten minutes .
The phenomenon occurred with the low frequent board in around a few days .
We are trying to reproduce the phenomenon with Sabre board.
Does the extremely rare possibility that a clock stops by configuring the mux exist
in the clock multiplexer module structurally ?
Best Regards,
Koichi Sakagami
Hi,
Unfortunately I have not found any issue related or something related. I have seen in different devices that chaging muxes, divisors etc. may cause problems and it is always a good practice to configure all muxes and divisors before setting the final PLL frequency.
I wonder if this is something that can be reproduced in one of our boards, I would like to start testing.
Best Regards,
Alejandro