AM6442: Linux system clock drift

I haven't used the Ethernet/IP Adapter Intercore Tunneling demo yet, but I've seen similar issues when using Linux + R5f software in parallel.

You could try and check if the clock of the GTC (global timestamp counter, which drives the ARM timer that is used for the Linux sytem clock) changes before/after starting the tunneling demo. You can dump the clocks with "k3conf dump clock" and check for any differences before/after.

Regards,

Dominic

Hi Dominic,

thank you for your quick response. Didn't know that tool but it is indeed very usefull. I found that diff between if the tunneling example and the hello world:

138c138
< |    13     |     2    | DEV_CPSW0_CPTS_RFT_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 200000000       |
---
> |    13     |     2    | DEV_CPSW0_CPTS_RFT_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 225000000       |
165c165
< |    84     |     1    | DEV_CPTS0_CPTS_RFT_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 200000000       |
---
> |    84     |     1    | DEV_CPTS0_CPTS_RFT_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 225000000       |
219c219
< |    19     |     1    | DEV_DCC3_DCC_CLKSRC1_CLK                                                                             | CLK_STATE_READY     | 200000000       |
---
> |    19     |     1    | DEV_DCC3_DCC_CLKSRC1_CLK                                                                             | CLK_STATE_READY     | 225000000       |
337,338c337,338
< |    61     |     0    | DEV_GTC0_GTC_CLK                                                                                     | CLK_STATE_READY     | 200000000       |
< |    61     |     1    | DEV_GTC0_GTC_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                           | CLK_STATE_READY     | 200000000       |
---
> |    61     |     0    | DEV_GTC0_GTC_CLK                                                                                     | CLK_STATE_READY     | 225000000       |
> |    61     |     1    | DEV_GTC0_GTC_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                           | CLK_STATE_READY     | 225000000       |
410c410
< |    23     |     2    | DEV_MCU_DCC0_DCC_CLKSRC2_CLK                                                                         | CLK_STATE_READY     | 48000000        |
---
> |    23     |     2    | DEV_MCU_DCC0_DCC_CLKSRC2_CLK                                                                         | CLK_STATE_READY     | 96000000        |
501c501
< |   149     |     0    | DEV_MCU_UART0_FCLK_CLK                                                                               | CLK_STATE_READY     | 48000000        |
---
> |   149     |     0    | DEV_MCU_UART0_FCLK_CLK                                                                               | CLK_STATE_READY     | 96000000        |
503c503
< |   160     |     0    | DEV_MCU_UART1_FCLK_CLK                                                                               | CLK_STATE_READY     | 48000000        |
---
> |   160     |     0    | DEV_MCU_UART1_FCLK_CLK                                                                               | CLK_STATE_READY     | 96000000        |
534,535c534,535
< |   114     |     1    | DEV_PCIE0_PCIE_CPTS_RCLK_CLK                                                                         | CLK_STATE_READY     | 200000000       |
< |   114     |     2    | DEV_PCIE0_PCIE_CPTS_RCLK_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                               | CLK_STATE_READY     | 200000000       |
---
> |   114     |     1    | DEV_PCIE0_PCIE_CPTS_RCLK_CLK                                                                         | CLK_STATE_READY     | 225000000       |
> |   114     |     2    | DEV_PCIE0_PCIE_CPTS_RCLK_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                               | CLK_STATE_READY     | 225000000       |
571,572c571,572
< |    81     |     3    | DEV_PRU_ICSSG0_IEP_CLK                                                                               | CLK_STATE_READY     | 200000000       |
< |    81     |     4    | DEV_PRU_ICSSG0_IEP_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 200000000       |
---
> |    81     |     3    | DEV_PRU_ICSSG0_IEP_CLK                                                                               | CLK_STATE_READY     | 225000000       |
> |    81     |     4    | DEV_PRU_ICSSG0_IEP_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 225000000       |
595,596c595,596
< |    82     |     3    | DEV_PRU_ICSSG1_IEP_CLK                                                                               | CLK_STATE_READY     | 200000000       |
< |    82     |     4    | DEV_PRU_ICSSG1_IEP_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 200000000       |
---
> |    82     |     3    | DEV_PRU_ICSSG1_IEP_CLK                                                                               | CLK_STATE_READY     | 225000000       |
> |    82     |     4    | DEV_PRU_ICSSG1_IEP_CLK_PARENT_POSTDIV4_16FF_MAIN_2_HSDIVOUT5_CLK                                     | CLK_STATE_READY     | 225000000       |

Seams like instanciation of the icssg which needs 200 MHz changes the GTC. Is there somethink in the sysconfig which prevents that GTC change? Maybe disable the IEP Clk Sync Mode but it is grayed out as well as the Core Clk (Hz) setting.

Regards
Martin

Hello Martin,

I guess you can use that as a workaround, but you need to be aware that now the GTC clock is wrong until the point where the R5f started (probably vai remoteproc?).

The proper location would be within U-Boot (or maybe TF-A?), which initially configures the clock for the GTC, and have that configure for the 200 MHz from the start. IIRC it's U-Boot, and that also configures the register from which the clock frequency is read, so the information would be propagated to Linux, too.

Please note that I'm not TI. It would be great if someone from them could comment on this issue.

Regards,

Dominic

Hi Dominic,

I do not use remoteproc to start R5 cores but the SPL OSPI Linux boot mode, so I think until arch arm timer driver is probed, the R5 core already configured GTC.

But you are right. Would be great if someone form TI could verify that!

Regards
Martin

Hello Martin,

I have not looked at clock frequencies for this example yet, so I'll be learning with you. I will loop in the dev team, but I think they are already on holiday for the next week. So it might just be us for now.

In the SysConfig settings for the project, do you see specific clock frequencies specified for the PRU cores and the IEP counter? What are those frequencies?

PLL2_hsdiv5 is used by multiple peripherals. I have not tested this, but if multiple peripherals all use the same clock source, but try to configure it to different frequencies, I would expect that the first applied setting would stick. The AM64x Clock Tree Tool is a graphical interface you can use to try different clock settings and see how it impacts other peripherals.

One option would be to set different clock sources for IEP counter and GTC counter if you want them running at separate frequencies, but it would be easier to align the timestamps if they have the exact same clock source.

Agreed that you want to configure both u-boot and Linux devicetrees to align with whichever clock frequency you end up using for the GTC. Note that in later versions of the SDK (SDK 11.x onwards I believe), we use the same devicetree file for both u-boot and Linux. But SDK 9.x still has a separate devicetree file for U-Boot and Linux.

Regards,

Nick

Hello Martin,

Following up

I have unlocked the thread so we can continue the conversation.

Have there been any updates from your side?

If you are seeing different behavior with SBL boot vs SPL boot, it is likely because the SBL initialization is setting core clocks differently than SPL boot.

Where is SPL setting the clock frequency?

I spent some time poking around SDK 11.1 today (upon checking the thread I see you using SDK 9.2, so uboot files will be structured differently). In this later version of the SDK, the devicetree files shared with Linux are here:
ti-u-boot-2025.01+git/dts/upstream/src/arm64/ti
and the SPL / R5 devicetree files should be here:
ti-u-boot-2025.01+git/arch/arm/dts

It looks like the R5F SPL file k3-am642-r5-sk.dts includes the Linux/uboot file k3-am642-sk.dts which is under the "dts/upstream" directory (and this allows the R5F SPL file to refer to devicetree nodes as needed).

It looks like this is where the clock-name "gtc" is set to 200kHz:

From https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/clocks.html , we can see that MAIN_0_HSDIVOUT6_CLK is the input that is selected as the clock source in the assigned-clock-parents entry (where GTC has a clock ID of 61)

ti-u-boot-2025.01+git/arch/arm/dts/k3-am642-r5-evm.dts

        a53_0: a53@0 {
                compatible = "ti,am654-rproc";
                reg = <0x00 0x00a90000 0x00 0x10>;
                power-domains = <&k3_pds 61 TI_SCI_PD_EXCLUSIVE>,
                                <&k3_pds 135 TI_SCI_PD_EXCLUSIVE>,
                                <&k3_pds 137 TI_SCI_PD_EXCLUSIVE>;
                resets = <&k3_reset 135 0>;
                clocks = <&k3_clks 61 0>, <&k3_clks 135 0>;
                clock-names = "gtc", "core";
                assigned-clocks = <&k3_clks 61 0>, <&k3_clks 135 0>;
                assigned-clock-parents = <&k3_clks 61 2>;
                assigned-clock-rates = <200000000>, <1000000000>;
                ti,sci = <&dmsc>;
                ti,sci-proc-id = <32>;
                ti,sci-host-id = <10>;
                bootph-pre-ram;
        };

Regards,

Nick