AM625: CPU running at wrong frequency (1GHz vs 1.25GHz)

Hi,

What do the following commands show on your device?

root@am62xx-evm:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor              
schedutil
root@am62xx-evm:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
200000 400000 600000 800000 1000000 1250000 
root@am62xx-evm:~# 

Hello Judith,

this is the output:

cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
schedutil
root@verdin-am62-15037377:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
200000 400000 600000 800000 1000000 
root@verdin-am62-15037377:~#

I would clarify that despite the linux kernel "error", uboot is running the SoC out of specification and, in my opinion, this is what we should try to fix.

However, error is reported, only 1 time, during startup:

[    1.575185] davinci_mdio 8000f00.mdio: Configuring MDIO in manual mode
[    1.620496] davinci_mdio 8000f00.mdio: davinci mdio revision 9.7, bus freq 1000000
[    1.630029] am65-cpsw-nuss 8000000.ethernet: initializing am65 cpsw nuss version 0x6BA01103, cpsw version 0x6BA81103 Ports: 3 quirks:00000006
[    1.643101] am65-cpsw-nuss 8000000.ethernet: initialized cpsw ale version 1.5
[    1.650272] am65-cpsw-nuss 800065-cpsw-nuss 8000000.ethernet: CPTS ver 0x4e8a010c, freq:500000000, add_val:1 pps:0
[    1.667492] am65-cpsw-nuss 8000000.ethernet: set new flow-id-base 19
[    1.678432] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 1250000 KHz, changing to: 1000000 KHz
[    1.703667] mmc0: CQHCI version 5.10

Regards,

Emanuele

Hi,

Ok, seems like you could modify U-boot device tree to get rid of this error.

Try the following DTS change:

diff --git a/arch/arm/dts/k3-am62x-r5-sk-common.dtsi b/arch/arm/dts/k3-am62x-r5-sk-common.dtsi
index b4a5e3cfa1..7c93ed42d5 100644
--- a/arch/arm/dts/k3-am62x-r5-sk-common.dtsi
+++ b/arch/arm/dts/k3-am62x-r5-sk-common.dtsi
@@ -46,7 +46,7 @@
                clocks = <&k3_clks 61 0>;
                assigned-clocks = <&k3_clks 61 0>, <&k3_clks 135 0>;
                assigned-clock-parents = <&k3_clks 61 2>;
-               assigned-clock-rates = <200000000>, <1250000000>;
+               assigned-clock-rates = <200000000>, <1000000000>;
                ti,sci = <&dmsc>;
                ti,sci-proc-id = <32>;
                ti,sci-host-id = <10>;

Hi Judith,

I have just tried but seem that the clock does not change.

Maybe this clock is controlled by drivers/firmware/ti_sci.c:ti_sci_cmd_clk_set_freq ?

I'm working around this module but seem like it is used in a very early stage where printf doesn't work...

Emanuele

Hi,

Do not use the ti_sci driver to change CPU frequency. The change that I sent you should have worked.

What device do you have so I can send you the binaries that worked for me?

- AM62x SK EVM?
- GP or HS-FS device?

~ Judith

Hello,

it is my own board AM62x toradex verdin am62 with a GP device...

Hi,

Ok, Can you please explain how you are building then?

~ Judith

the sources are here: https://git.toradex.com/cgit/u-boot-toradex.git/tree/?h=toradex_ti-u-boot-2023.04, board/toradex/verdin-am62, verdin-am62_a53_defconfig and verdin-am62_r5_defconfig.

the build procedure, apart for that, is what you would do on the TI AM62 SK board. no differences expected that would affect this specific issue.

in addition to that, we cannot test on the TI SK board since we have only boards with 1.4GHz CPU. you cannot use your binaries to run on the verdin-am62 since the hardware is differente and it would just not boot.

Hi Fd,

I could provide a bootlog where this change works on TI EVM. I cannot apply patch and test if I do not have your board.

One thing we could do is verify you are booting the correct binaries. Please show the top commit in U-boot using git show command. Then show the bootlog for the boot using the binaries that you built.

~ Judith

Hello,

I'm sure that I loaded the corrected binaries.

Judith, do you know which driver and which registers affect the A53 clock? I would check if the modification is somehow not working due to our device tree (or something else).

Emanuele

Hi Emanuele,

It is set by R5 SPL and A53 SPL. I will verify what driver is involved and get back to you.

~ Judith

Hi,

thank you Judith.

That driver seem to be a remote process communication module.

From my test the clock subsystem seem to be managed by drivers/clk/ti/clk-k3.c.

In the dts it is here ("ti,k2g-sci-clk"):

&cbass_main {
    ...
	dmsc: system-controller@44043000 {
		compatible = "ti,k2g-sci";
		ti,host-id = <12>;
		mbox-names = "rx", "tx";
		mboxes = <&secure_proxy_main 12>,
			 <&secure_proxy_main 13>;
		reg-names = "debug_messages";
		reg = <0x00 0x44043000 0x00 0xfe0>;
		...

		k3_clks: clock-controller {
			compatible = "ti,k2g-sci-clk";
			#clock-cells = <2>;
		};
	};

From my test changing this:

a53_0: a53@0 {
        ...
		assigned-clock-rates = <200000000>, <1250000000>;
		...
	};

to this:

a53_0: a53@0 {
        ...
		assigned-clock-rates = <200000000>, <1000000000>;
		...
	};

affect some debug prints I have enabled (output by R5 SPL):

With 1000000000
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=61 [1]=2)
ti_clk_of_xlate(clk=81fffe28, args_count=2 [0]=61 [1]=0)
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=61 [1]=0)
ti_clk_set_rate: propagating rate change to parent postdiv4_16ff_main_0_hsdivout6_clk, rate=200000000.
ti_clk_set_rate: clk=postdiv4_16ff_main_0_hsdivout6_clk, div=1, rate=200000000, new_rate=200000000, diff=0
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=135 [1]=0)
ti_clk_set_rate: clk=hsdiv0_16fft_main_8_hsdivout0_clk, div=1, rate=1000000000, new_rate=25000000, diff=975000000
ti_clk_set_rate: propagating rate change to parent, rate=1000000000.
ti_clk_set_rate: pll_tgt=2000000000, rate=1000000000, div=2

With 1250000000
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=61 [1]=2)
ti_clk_of_xlate(clk=81fffe28, args_count=2 [0]=61 [1]=0)
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=61 [1]=0)
ti_clk_set_rate: propagating rate change to parent postdiv4_16ff_main_0_hsdivout6_clk, rate=200000000.
ti_clk_set_rate: clk=postdiv4_16ff_main_0_hsdivout6_clk, div=1, rate=200000000, new_rate=200000000, diff=0
ti_clk_of_xlate(clk=81fffe48, args_count=2 [0]=135 [1]=0)
ti_clk_set_rate: clk=hsdiv0_16fft_main_8_hsdivout0_clk, div=1, rate=1250000000, new_rate=25000000, diff=1225000000
ti_clk_set_rate: propagating rate change to parent, rate=1250000000.
ti_clk_set_rate: pll_tgt=2500000000, rate=1250000000, div=2

But, executing some very simple benchmark in A53 u-boot proper the performance is always the same and likely (by some rough calculation) 1.25 GHz:

int testam62(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[])
{
	int i;
	printf("AM62 Test start\n");
	for (i = 0; i < 1000000000; i++)
		asm volatile("nop");
	printf("AM62 Test end\n");
	return 0;
}

I measured it with grabserial and give it always 1.6 seconds (that is the time to execute 2000000000 instructions).

I'll try to debug the clock setup code and I'll check in the early boot stage of A53 (SPL) if the clock is different ("correct").

Thank you and kind regards,

Emanuele

Hi Judith,

thank you for the answer... I'll wait for news from you.

Kind regards,

Emanuele

Hi,

Update, it seems like it is an issue with U-boot after all. We are pending to add PPL calibration to SPL in all Sitara devices with DM.

~ Judith