Dear TI team,
while moving from SDK 07.00 to SDK 07.01 we noticed that our SYS/BIOS sleep calls (via Task_sleep) on an A53 core slept longer than before.
With SDK 07.00 sleeping for 10,000 ticks would sleep for 10 seconds, now it is sleeping for 12.5 seconds.
The GTC which serves as the time base for the A53 timer is clocked from CPSWHSDIV_CLKOUT2. Looking at MCU_PLL0_HSDIV_CLKDIV I noticed that the HSDIV2 output is now configured to divide /10 (0x9), whereas with SDK 07.00 that output was configured to divide /8 (0x7). This is was explicitly changed some time ago (https://git.ti.com/cgit/keystone-rtos/board/commit/src/am65xx_idk/am65xx_idk_pll.c?id=52f145f3ada21e9332e36937b5278671587426ec). Now the divider seems to be back at /10.
By default the SYS/BIOS code seems to assume 200 MHz for the A53 timer. At some point we changed that to 250 MHz by setting v8aTimer.intFreq.lo = 250000000 in the xdc config file, so basically our previous workaround causes the timing to be off now.
The change was probably introduced by commit 01a010b197879a071bd484947dcae8e9afe97ed5 (PRSDK-8607: Board: Removed CSL based PLL config functions in AM65x Board library) that changed the code in packages/ti/board/src/evmKeystone3/board_pll.c to use the Sciclient to configure the clocks, instead of directly writing to the PLL registers. I checked the new code, and there is one CPSW clock that is getting configured for 250 MHz, but I suspect that this is a different PLL output.
Is it intentional that the CPSW HSDIV2 output got switched back to 200 MHz?
What was the reason for having the 250 MHz starting with commit 52f145...?
Should we explicitly configure the GTC to 200 (or 250?) MHz or are there some guarantees that it will always come up with a known frequency? Should we configure CPSW_HSDIV2 explicitly as the clock parent, and then configure the frequency?
Regards,
Dominic