AM6442: Linux System Clock Falls Behind Real Time When CPSW is Activated on MCU

Hello Onur,

I remember seeing something similar. You could check the frequency of the GTC (e.g. with k3conf) before and after starting your MCU+ SDK application on the R5f.

My guess would be that the MCU+ SDK application changes some clocks. The GTC is what is used for the system time in Linux, and must always run at the same frequency.

If that's your problem you need to find a way to make MCU+ SDK code use the same clock frequencies.

Please note I'm not TI, and they might have other advise for you.

Regards,

Dominic

Hi Onur,

Let me check on this internally and get back to you.

Regards,

Nitika

Hi Nitka,

Since you are using the CPSW with the R5 I will need to pass your thread to the MCU support team. This may take up to another day.

Dominic has provided great solutions on other TI e2e threads.

Best Regards,

Schuyler

Hi, I compiled k3conf and checked GTC (clock id 61) frequency as Dominic Rath said. When I execute k3conf without CPSW enabled on MCU, GTC frequency is 225MHz. If I do the same with CPSW enabled on MCU, frequency is 200MHz.

I checked the code and it looks like in ti_power_clock_config.c (which is generated by SysConfig) only frequency of TISCI_DEV_CPSW0_CPTS_RFT_CLK is set to 200MHz. Is this clock related to GTC?

Let's say clock frequency must stay at 200MHz. Is it possible to tell Linux that GTC frequency is 200MHz?

Hi, 

I will meet with the Linux network developer and to discuss Linux options.

Best Regards,

Schuyler

Hello Onur,

the difference between 225 and 200 roughly matches your observed time discrepancy, but not as exactly as I'd hoped. Could you verify that by observing time for a longer period, and maybe with a stop watch? 30s at 200 MHz instead of 225 should cause the Linux system clock to fall 3.3s behind. The longer the period you observe, the less of an effect manual measurement has.

It would also be great if you could post the exact output from k3conf on which you based your assumptions.

I'm also a bit puzzled why Linux would run the GTC at 225 MHz by default. I just tried the latest TI RT SDK (09.02.01, debian) and the GTC defaults to 200 MHz.

This gets configured in the U-Boot R5f SPL device-tree: arch/arm/dts/k3-am642-r5-evm.dts:

So basically Linux (U-Boot) is already configuring the GTC for 200 MHz.

Could you verify the content of CTRLMMR_GTC_CLKSEL (0x43008030), and maybe attach the full output of k3conf dump clocks?

Onur Bay said:

I checked the code and it looks like in ti_power_clock_config.c (which is generated by SysConfig) only frequency of TISCI_DEV_CPSW0_CPTS_RFT_CLK is set to 200MHz. Is this clock related to GTC?

I believe the naming is a bit unfortunate. CPSW0_CPTS_RFT_CLK is a pin on the device, but in that context it is the CPSW0 CPTS reference clock input, which is muxed via CTRLMMR_CPSW_CLKSEL[2:0], see 12.2.1.4.7.1 CPSW0 CPTS Integration
in the TRM. It would be good if you could read that register (0x43008150) before/after as well.

Regards,

Dominic

Hi Dominic,

Firstly, thank you for the information you provided.

Dominic Rath said:

Could you verify the content of CTRLMMR_GTC_CLKSEL (0x43008030), and maybe attach the full output of k3conf dump clocks?

If we cannot get any results from the issue I will mention in this question, I will share the k3conf dump you requested.

Dominic Rath said:

This gets configured in the U-Boot R5f SPL device-tree: arch/arm/dts/k3-am642-r5-evm.dts

At this point there is a difference;

The bootloader of my system is SBL, not R5F SPL (I use sbl_ospi_linux ospi bootloader since I use OSPI Flash boot media). In this way, I can boot my R5F mcu applications and Linux.

In summary, the boot flow is as follows;

MCU: SBL - - MCU(R5F) App

Linux: SBL -- A53 SPL -- U-Boot -- Linux Kernel(fitImage)

So, is it possible to set the frequency of GTC clock in SBL phase?

Hello Onur,

I haven't used SBL booting for Linux yet, so I'm not completely sure how this is supposed to work.

I've compiled the sbl_ospi_linux code, and it seems that it doesn't explicitly set the GTC frequency, so I guess it runs at "whatever clock there is". The GTC driver does read the actual frequency, so at least it would "know" what that frequency is. Not sure if that is intended (it looks like an oversight in TI's code - someone from TI please correct me).

There doesn't seem to be a SysConfig option to configure the GTC clock.

You could try manually adding a call to SOC_moduleSetClockFrequency to set TISCI_DEV_GTC0 TISCI_DEV_GTC0_GTC_CLK to 200 MHz. You should verify with what clock parent you end up with (CTRLMMR_GTC_CLKSEL) and verify later in Linux that this clock parent remains stable at 200 MHz when you setup the remoteproc.

Regards,

Dominic

Hi Dominic,

Thanks for your help. I tried to find a way to inform Linux about the frequency of GTC because I'm not sure if setting GTC frequency back to 225MHz can break something.

I found out that Linux finds clock frequency by reading CNTFRQ_EL0 register. This register holds 225MHz by default. When I debug A53 SPL on CCS and change this register value to 200MHz, Linux detects frequency as 200MHz as expected and clock ticks synchronously with real time. U-Boot has an option (CONFIG_COUNTER_FREQUENCY) to set this register. Adding this option didn't worked for me because CNTFRQ_EL0 register can only be set when CPU is running at EL3 (highest exception level). Both U-Boot SPL and U-Boot runs at EL2.

I set a constant clock frequency on Linux devicetree. So Linux uses the frequency on devicetree instead of the one on CNTFRQ_EL0 register. This solves my problem but I have some questions.

Questions to TI:

1) In which boot stage frequency of CNTFRQ_EL0 is set?

2) According to boot logs I saw on this forum, some boards detect arch_sys_counter frequency (which is read from CNTFRQ_EL0) as 225MHz while others detect as 200MHz. What makes them differ? (maybe boot modes?)

3) If I leave Linux's frequency as default (225MHz) and set the GTC frequency to 225MHz from MCU application does that cause any malfunction CPSW or CPTS?

Schuyler Patton

Hi,

I am still working the question, the discussion we had revolved about ownership of the clock for cpsw. SInce you are using the R5 to operate the cpsw the TISCI clock id that the Linux CPSW driver uses should be given to the R5 code. Let me work to confirm that.

Best Regards,

Schuyler

Hi Onur,

Onur Bay said:

1) In which boot stage frequency of CNTFRQ_EL0 is set?

the CNTFRQ_EL0 register should be set in the TF-A (https://git.ti.com/cgit/atf/arm-trusted-firmware/). There's code that reads the GTC0_CNTFID0 register and uses that to program the CNTFRQ_EL0 register.

This register is just a means for software running after the "firmware" to know how the ARM generic timer is being clocked.

Onur Bay said:

2) According to boot logs I saw on this forum, some boards detect arch_sys_counter frequency (which is read from CNTFRQ_EL0) as 225MHz while others detect as 200MHz. What makes them differ? (maybe boot modes?)

In the default case, U-Boot R5 SPL configured the GTC clock to 200 MHz, TF-A programmed the CNTFRQ_EL0, and Linux is using that value.

In your case noone explicitly programmed the GTC, which appears to result in the 225 MHz. (This is just an assumption based on what we're seeing. Maybe someone at TI could verify what GTC clock is used for SBL -> U-Boot -> Linux boots).

Onur Bay said:

3) If I leave Linux's frequency as default (225MHz) and set the GTC frequency to 225MHz from MCU application does that cause any malfunction CPSW or CPTS?

I believe a GTC frequency of 200 or 250 MHz (something that results in an integer numer of nanoseconds) is much easier to work with.

What's more important is that the GTC is likely clocked by one of two parents:

MAIN_PLL2_HSDIV5_CLKOUT

MAIN_PLL0_HSDIV6_CLKOUT

Both of these clock parents are also used by other "timesync" peripherals like the CPSW CPTS reference clock. This is exactly why you're running into issues. The clock parent that was initially used to generate the 225 MHz clock for your GTC gets switched to 200 MHz, breaking Linux' idea of time.

I'm pretty sure the CPSW CPTS needs to be run at a frequency that gets you an integer number of nanoseconds. At least that's required for stuff like PTP to work.

Dominic Rath said:

You could try manually adding a call to SOC_moduleSetClockFrequency to set TISCI_DEV_GTC0 TISCI_DEV_GTC0_GTC_CLK to 200 MHz. You should verify with what clock parent you end up with (CTRLMMR_GTC_CLKSEL) and verify later in Linux that this clock parent remains stable at 200 MHz when you setup the remoteproc.

Did you give that a try, or do you think there's something wrong with this suggestion?

Onur Bay said:

3) If I leave Linux's frequency as default (225MHz) and set the GTC frequency to 225MHz from MCU application does that cause any malfunction CPSW or CPTS?

From what I've read about your issue I believe it makes more sense to configure the GTC to 200 MHz. As I've explained above that will result in Linux usinng the 200 MHz from the beginning.

Best Regards,

Dominic