iMX6DL : uboot hung issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMX6DL : uboot hung issue

1,058 Views
koichisakagami
Contributor II

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.

Sequence.bmp

[Question]
    Could you advise  a check point to us for solving this issue ?

Best Regards,
Koichi Sakagami

Labels (1)
0 Kudos
8 Replies

649 Views
alejandrolozan1
NXP Employee
NXP Employee

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

0 Kudos

649 Views
koichisakagami
Contributor II

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

0 Kudos

649 Views
alejandrolozan1
NXP Employee
NXP Employee

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

0 Kudos

649 Views
koichisakagami
Contributor II

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

0 Kudos

649 Views
koichisakagami
Contributor II

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
****************

0 Kudos

649 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

Have you tested removing the IPU and its corresponding clock initialization? just to make sure that is the problem.

Best Regards,

Alejandro

0 Kudos

649 Views
koichisakagami
Contributor II

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

0 Kudos

649 Views
alejandrolozan1
NXP Employee
NXP Employee

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

0 Kudos