SoC lock-up when trying to CCM_UpdateRoot for I2C1 from M4 after Linux boots

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

SoC lock-up when trying to CCM_UpdateRoot for I2C1 from M4 after Linux boots

638 Views
dry
Senior Contributor I

I got the problem that when my M4 code using I2C1 is started after Linux boots, then the M4 and then A7 or entire SoC seems gets hard locked on when trying to set clocks for the I2C1 on the M4. The same code works ok if booted just from U-boot, with no Linux.

The M4 init code for I2C1 is : (BOARD_I2C_xx refers to I2C1 stuff)

RDC_SetPdapAccess(RDC, BOARD_I2C_RDC_PDAP, 3 << (BOARD_DOMAIN_ID * 2), false, false);
/* Select I2C clock derived from OSC clock(24M) */
CCM_UpdateRoot(CCM, BOARD_I2C_CCM_ROOT, ccmRootmuxI2cOsc24m, 0, 0);  <---- Locks up here when updating register
/* Enable I2C clock */
CCM_EnableRoot(CCM, BOARD_I2C_CCM_ROOT);
CCM_ControlGate(CCM, BOARD_I2C_CCM_CCGR, ccmClockNeededRunWait);
/// rest ....

The lock-up is on line with CCM_UpdateRoot, when that function trying to write to CCM_REG(ccmRoot) .

In the Linux sources I traced that a conflict is created in clk-imx7d.c , with:

imx_clk_set_parent(clks[IMX7D_SIM1_ROOT_SRC], clks[IMX7D_PLL_SYS_MAIN_120M_CLK]);

I haven't fully traced into that call, but if I remove this parent setting, then my problem with I2C1 init on the M4 goes away .. 

Any help / suggestions .. ? How does SIM1 root clock update mess up updating I2C1 root clock ?  

Labels (2)
0 Kudos
1 Reply

521 Views
Yuri
NXP Employee
NXP Employee

Hello,

 

  Is CCM block accessible by CM4 under Linux?

 

Have a great day,

Yuri

 

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

0 Kudos