Tool/software:
Hi,
Where can I find the list of module ID's and list of clocks? Seems not clickable like what Am62x does
Thanks,
Dazong
Hi Anil,
With HW validation we want to make sure all peripherals are at correct clk freq and reading from sw is the most direct/easy way to do so. Could you suggest another way that I can verify lpddr4 freq?
SPI freq shows 25MHz too where we set it to
Thanks,
Dazong
Hello Dazong,
To verify the DDR frequency on the AM62L SOC, I have identified two possible software methods. Below is a detailed explanation of each method .
Method 1: Monitoring DDR PLL Input Usage in Other Peripherals
Approach:
• The DDR PLL input clock is used by multiple peripherals (e.g., timers, other high-speed interfaces).
• If any peripheral shares this clock, we could monitor that peripheral’s clock configuration .
• In AM62L, the DDR PLL input clock is not shared with any other IPs—it is dedicated only to the DDR subsystem.
Since no other peripheral can provide an indirect way to monitor the DDR frequency, this method is not applicable.
Method 2: Checking PLL Scaling Factors from Input to DDR Output Clock
Approach:
• Instead of monitoring another IP, we check the clock tree configuration to determine the DDR frequency.
• The input clock to the PLL is 25MHz, which passes through the PLLHSDIVA block to generate the DDR frequency.
• The key parameter to monitor is HSDIVCLKOUT2, which is responsible for providing the final DDR clock.
• By reading the scaling factor of HSDIVCLKOUT2, we can confirm if the expected frequency is being generated.
Implementation in AM62L:
1. The DDR PLL receives a 25MHz input clock.
2. The PLLHSDIVA block scales this input using a divider (HSDIVCLKOUT2).
3. The expected scaling factor is 5, which results in a DDR clock of 25MHz × 5 = 400MHz.
4. By checking if the HSDIVCLKOUT2 scaling factor is set to 5, we can confirm that the DDR is running at 400MHz.
Please make sure that , you are not supposed to set any values in that register which will impact to the DDR .
Regards,
Anil.
Hi Anil,
I am analyzing TF-A now. Could you please verify if I am looking at the correct file for clock settings.
plls: ti-processor-sdk-linux-am62lxx-evm-11.00.00.03\board-support\trusted-firmware-a-2.11+git\plat\ti\k3\am62l\scmi\drivers\soc\am62lx\clocks.c
periphrals: ti-processor-sdk-linux-am62lxx-evm-11.00.00.03\board-support\ti-u-boot-2024.10+git\dts\upstream\src\arm64\ti\k3-am62l-main.dtsi
Any other files I should look into? What I am trying to achieve is make sure the clock setting, then I will put the values into
With the visual output from the website, compare the result from SOC_ModuelGetClockFrequency()
For exmaple these fields
I am not sure if periprhals are set from uboot when boot from USB DFU
Thanks,
Dazong
Hello Dazong,
Please look at the flow of the SCMI call.
The Application requests the clock set or gets PSC on or off for the particular IPs.
This request is written in the Shared memory next the control is jumped to the ATF.
The ATF will decide whether the particular operation is performed either it is clock-set or get or PSC on or off.
So, in the ATF folder first level you can check these wrapper files.
The ATF request these calls to perform clock setting or PSC ON and OFF as well.
int32_t SOC_moduleGetClockFrequency(uint32_t moduleId, uint32_t clkId, uint64_t *clkRate);
To get the clock ID, we need to pass Module ID and clock ID, which are available in these below.h files.
So, you need to use these files to get the particular IP frequencies.
All PLL settings are done by the ROM bootloader and again user don't need to touch them.
I am not sure if you are trying to update or reconfigure different PLL settings ?
Why do you want to change the PLL settings ?
Please let me know, the above replies cleared your queries.
Regards,
Anil.
Hi Anil,
We have two questions:
1) We are trying to set the clock frequency for Timer module (Timer 2 and 3) using the gSocModulesClockFrequency[] inside ti_power_clock_config.c. We couldn't get the TFA to boot successfully when we use select clocks like HFOSC0_CLKOUT_SERDE shown in sysconfig below:
SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
{ AM62LX_DEV_TIMER2, AM62LX_DEV_TIMER2_TIMER_TCLK_CLK_PARENT_GLUELOGIC_HFOSC0_CLK, 25000000 },
//{ AM62LX_DEV_TIMER3, AM62LX_DEV_TIMER2_TIMER_TCLK_CLK_PARENT_GLUELOGIC_HFOSC0_CLK, 25000000 },
{ SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};
a) How can we get this to work?
b) Where are the two clocks marked in red coming from?
c) Timer 3 doesn't have the 11 clocks mux options like Timer 2 has, are they connected internally?
2) We also tried to set different frequency for MCSP1 using the snippet below.
SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
{ AM62LX_DEV_MCSPI1, AM62LX_DEV_MCSPI1_CLKSPIREF_CLK, 2400000000 },
{ SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
};
However, we noticed that tfa booting failed to complete when certain clock frequencies were used e.g. 2.4GHz, 1000MHz, 800MHz, 700MHz, 500MHz etc.
While other frequencies like 1.2GHz, 600MHz, 400MHz, 300MHz, 200MHz seems to work.
What's responsible for that?
Best,
Simeon
a) How can we get this to work?
Hello Simeon,
All timers in the SoC have a MUX selection mechanism for their input clock source.
Timer Clock (TCLK) Source
• The TCLK refers to the Timer input clock, which is derived from the output of the clock MUX.
• For example, to select HFOSC as the input clock for TIMER2, the parameter below is correct:
AM62LX_DEV_TIMER2_TIMER_TCLK_CLK_PARENT_GLUELOGIC_HFOSC0_CLK
/* ----------- TimerP ----------- */
#define CONFIG_TIMER0_CLOCK_SRC_MUX_ADDR (0x9117000u)
#define CONFIG_TIMER0_CLOCK_SRC_HFOSC0_CLKOUT (0x0u)
/* set timer clock source */
SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2);
*(volatile uint32_t*)AddrTranslateP_getLocalAddr(CONFIG_TIMER0_CLOCK_SRC_MUX_ADDR) = CONFIG_TIMER0_CLOCK_SRC_HFOSC0_CLKOUT;
SOC_controlModuleLockMMR(SOC_DOMAIN_ID_MAIN, 2);
Hi Anil,
What we are studying is still the input clock to the peripherals.
The file we are play around with is ti_power_clock_config.c
uint32_t gSocModules[]; SOC_ModuleClockFrequency gSocModulesClockFrequency[]; void Module_clockEnable(void);
{ AM62LX_DEV_TIMER2, AM62LX_DEV_TIMER2_TIMER_TCLK_CLK_PARENT_GLUELOGIC_HFOSC0_CLK, 25000000 },2. When play with MCSPI input clock freq, we observed it can be set to other values than 50MHz, like 100MHz, and SOC_ModuleGetClockFrequency() will also return 100MHz. my guess is the hsdiv_clkout6 is doing something as division can be set from /1 to /128. We are trying some values like up to 2.4GHz
{ AM62LX_DEV_MCSPI1, AM62LX_DEV_MCSPI1_CLKSPIREF_CLK, 2400000000 },
As Simeon mentioned, "frequencies like 1.2GHz, 600MHz, 400MHz, 300MHz, 200MHz seems to work". "clock frequencies were used e.g. 2.4GHz, 1000MHz, 800MHz, 700MHz, 500MHz etc. will fail"
{ AM62LX_DEV_MCSPI1, AM62LX_DEV_MCSPI1_CLKSPIREF_CLK, 600000000 },
SOC_moduleGetClockFrequency(AM62LX_DEV_MCSPI1, AM62LX_DEV_MCSPI1_CLKSPIREF_CLK, &clkRate);
info("MCSPI1 CLK RATE: %d\n", clkRate);
Print: MCSPI1 CLK RATE: 600000000
I guess ultimately it is two questions.
1. If we want to change the value of HSDIV, is it recommend to direct change the register itself using CSL_REG32_WR()?
2. If we want to change the mux input, like the case of timer2, why a valid parent clock name AM62LX_DEV_TIMER2_TIMER_TCLK_CLK_PARENT_GLUELOGIC_HFOSC0_CLK is not working, the whole application just stuck
Thanks,
Dazong
Hi Anil,
After trying direct MUX register configuration for timer, I don't see clock freq changes, still getting 100MHz. With CONFIG_TIMER0_CLOCK_SRC_MUX_ADDR) = CONFIG_TIMER0_CLOCK_SRC_HFOSC0_CLKOUT I think it should be 25Mhz since it is directly coming from HFO?
SOC_controlModuleUnlockMMR(SOC_DOMAIN_ID_MAIN, 2);
*(volatile uint32_t*)AddrTranslateP_getLocalAddr(CONFIG_TIMER0_CLOCK_SRC_MUX_ADDR) = CONFIG_TIMER0_CLOCK_SRC_HFOSC0_CLKOUT;
SOC_controlModuleLockMMR(SOC_DOMAIN_ID_MAIN, 2);
TIMER CLK RATE: 100000000
Thank you,
Dazong
Hello Dazong,
Before making any changes, please confirm which HSDIV you’re planning to modify.
This is critical because modifying an HSDIV affects multiple IPs, and an incorrect change can lead to system performance degradation.
Important Considerations:
• HSDIV changes impact all clock consumers using that output.
• If your SoC’s PLL feeds several peripherals via the same HSDIV, changing its divider can unintentionally slow down multiple modules.
About ATF and Clock Control:
• ATF does not expose straightforward APIs.
• It uses SCMI (System Control and Management Interface) for all device control operations (like clocks, resets, and power domains).
SCMI Clock & PSC Control Flow:
1. The application writes a message into the SCMI shared memory.
2. The application issues an SMC (Secure Monitor Call) to invoke ATF. Here, the application is stops and jump to the ATF code .
3. Inside ATF, the message is parsed and dispatched for Clock set/get and Power domain (PSC) enable/disable
4. ATF processes the request and sends the response back through the same shared memory.
5. The application reads the result after the SMC returns.
Suggested Files to Review:
To understand the full flow of set_clock, get_clock, and psc enablement:
• Start from the SCMI protocol layer in the code.
• Trace the flow through the platform-specific service handlers.
• From there, the call goes into internal clock/PSC driver layers (not a single API, it’s a chained call flow).
The codes below are on the ATF side, so when the SCMI call requests based on the set or get or psc enabled, the ATF calls the particular API.
Regards,
Anil.