This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Internal 32.768K clock reference for the RTC of AM389x

We use internal 32.768K clock reference for the RTC of AM389x and select Audio PLL generated 32KHz Clock.
The clock source is SYSCLK18 in Audio PLL module. There is no information about the SYSCLK18. How to  
configure the SYSCLK18 to generate 32KHz Clock ? And what value should be set to  N,P,FREQ,M ?
Thanks!

  • Hi Lianqing,

    SYSCLK18 has two sources:

    1. 32 KHz system clock (sys_32k_ck in linux kernel)

    2. audio pll clock 1 (audio_pll_a_ck in linux kernel)

    In both cases, the frequency of SYSCLK18 (sysclk18_ck in linux kernel) is 32 KHz (32768 Hz).

    By default, the RTC is supplied with /sys_32k_ck/sysclk18_ck/rtc_c32k_fck clock. When you set 0x1 in bit CM_SYSCLK18_CLKSEL[0] CLKSEL (address 0x48180378), the RTC is supplied with /audio_pll_clk1_ck/audio_pll_a_ck/sysclk18_ck/rtc_c32k_fck clock. In both cases, you supply the RTC with 32 KHz clock, no need to modify anything else.

    I hope this helps.

    Best regards,

    Pavel

  • Thanks for your answer.

    But /audio_pll_clk1_ck don't be initialized in u-boot and linux kernel. There aren't example data for /audio_pll_clk1_ck in AM389x User Manual, as for /audio_pll_clk2_ck --- /audio_pll_clk5_ck in page-191 (SPRUGX7-1 July 2011). Maybe the AM389x don't support /audio_pll_clk1_ck, is it right ?

    Best regards.

  • Hi Lianqing,

    audio_pll_clk1_ck is the name for this clock in linux kernel source code, in AM389x User Manual (SPRUGX7 – 1 July 2011), it is named audio pll clock 1, see section 1.8.3.1.4 Audio PLL. Reading this section, SYSCLK18 is 32.678 KHz by default, no need to modify the Audio PLL settings (N, P, FREQ, M). You just need to set 0x1 in bit CM_SYSCLK18_CLKSEL[0] CLKSEL and you will supply the RTC with internal 32 KHz clock, coming from the Audio PLL.

    Is this expected behaviour not observed in your board?

    BR,

    Pavel