i.MX6ULL 792MHz performance issue in Linux

[manux]

MCIMX6Y2CVM08AB (792MHz) slower than MCIMX6Y2CVM05AB (528MHz) under Linux.

Tests performed:

* console command: B=`date +%s`;ps -a;ps -a;ps -a;E=`date +%s`; echo "$((E - B))"

Takes 1~2sec on MCIMX6Y2CVM05AB (528MHz)

Takes 4~5sec on MCIMX6Y2CVM08AB (792MHz)

* iperf3 -c xxx.xxx.xxx.xxx

9.32 Mbits/sec on MCIMX6Y2CVM05AB (528MHz)

3.46 Mbits/sec on MCIMX6Y2CVM08AB (792MHz)

Other observation:

cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

returns 528000 with MCIMX6Y2CVM05AB (528MHz)

returns 24000 with MCIMX6Y2CVM08AB (792MHz)

if following command executed:

echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

MCIMX6Y2CVM08AB (792MHz) performs slightly better than MCIMX6Y2CVM05AB (528MHz)

And command: cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq returns 528000 for both models.

How can I make the i.MX6ULL run properly at 792MHz ?

I built my kernel using using linux-imx-lf-6.6.52-2.2.0.tar.gz from NXP.

[Zhiming_Liu]

Hi @manux 

returns 24000 with MCIMX6Y2CVM08AB (792MHz)

--> This is not expected value. The MCIMX6Y2CVM08AB  is not running on 792MHz.

The speed grade will be detected in uboot with reading fuse in chip. Did you try to use echo 792000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq ?

Please run below tests.

Best Regards,
Zhiming

[manux]

Hi Zhiming,
Thanks for you quick reply.
Below are the commands you asked to run:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
198000 396000 528000 792000
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
ondemand performance
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
24000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
792000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
198000
# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
24000
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
792000

Best Regards,
Emmanuel

[manux]

Hi Zhiming,

Here are result on few more commands:

# echo 792000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
792000
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
792000
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
24000

# cat /sys/kernel/debug/clk/arm/clk_rate
24000000

* system is sluggish.

# echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
528000

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
528000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000

# cat /sys/kernel/debug/clk/arm/clk_rate
528000000

* system has much better responsiveness but is limited to 528MHz.

As mentioned earlier, my board is populated with a MCIMX6Y2CVM08AB

[Zhiming_Liu]

Hi

I did test on EVK board.

NXP i.MX Release Distro 6.6-scarthgap imx6ul7d ttymxc0

imx6ul7d login: root
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
900000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
792000
root@imx6ul7d:~# cat /sys/kernel/debug/clk/arm/clk_rate
198000000
root@imx6ul7d:~# cat /sys/kernel/debug/clk/arm/clk_rate
792000000
root@imx6ul7d:~# cat /sys/kernel/debug/clk/arm/clk_rate
792000000
root@imx6ul7d:~# cat /sys/kernel/debug/clk/arm/clk_rate
792000000

At least it proves that it's not a software problem, it's probably your hardware design that can't support it run on 792Mhz

Best Regards,
Zhiming

[manux]

Hi Zhiming,

According to what I see In the code, the frequency not supported by the hardware are automatically disabled.

if (of_machine_is_compatible("fsl,imx6ull")) {
if (val < OCOTP_CFG3_6ULL_SPEED_792MHZ)
imx6x_disable_freq_in_opp(dev, 792000000);

if (val != OCOTP_CFG3_6ULL_SPEED_900MHZ)
imx6x_disable_freq_in_opp(dev, 900000000);

I tested that by adding the 900MHz in my devtree and the available frequencies remains: 198000 396000 528000 792000

I also tested the same software on my EVK that has a MCIMX6Y2CVM05AB and the available frequencies are limited to: 198000 396000 528000

It seems that my hardware should be able to run at 792MHz.

Could you provide me with the output of: "cat /sys/kernel/debug/clk/clk_summary" ?

Thanks.

Best Regards.

Emmanuel

[Zhiming_Liu]

Hello @manux 

Yes, the unsupported frequency is disabled. The chip on top of the EVK I tested yesterday supports 900MHz, and the EVK has to be designed to run at 900MHz.

The issue at hand is not whether the chip supports it or not, but whether the circuit design supports it or not.

1. The SoC requires VDD_SOC 1.325~1.5V and VDD_ARM 1.2~1.26V to run at 792MHz, but the on-board power supply is unable to stabilize the output or the current supply is insufficient.

2. High-frequency operation requires a higher degree of cleanliness of the power supply, excessive ripple may cause voltage fluctuations, affecting the core circuit. The current problem is not in the chip support or not, but the circuit design support or not.

It is recommended that monitor VDD_ARM or VDD_SOC with an oscilloscope during your test.

Best Regards,
Zhiming

[manux]

Hi Zhiming,

I added many "printk" all over the "imx6q-cpufreq.c" driver to try to follow the process and I still think there is issues with the code.

1) clock rate of 24MHz can be expected per following comment found in the source code:
/*
* ON i.MX6ULL, the 24MHz setpoint is not seen by cpufreq
* so we neet to prevent the cpufreq change frequency
* from 24MHz to 198Mhz directly. busfreq will handle this
* when exit from low bus mode.
*/
if (old_freq == FREQ_24_MHZ && new_freq == FREQ_198_MHZ)
return 0;

But because of this condition if the frequency is set to 24MHz and there is a request to change to 192MHz nothing happens.
And the busfreq is not triggered because the function is exited.
For instance if I start with the governor "powersave" the cpuinfo_cur_freq remains stuck at 24000.
Also if I change the governor to "userspace" and try to set 192MHz, cpuinfo_cur_freq remains stuck at 24000.
But if I set 396000 or 528000 first,then cpuinfo_cur_freq get set to the proper frequency and from there I can set the frequency back to 198MHz.

returns from my added printk's:

# insmod imx6q-cpufreq.ko
[ 115.393111] low power run support = 1
[ 115.483249] nvmem-cells, speed_grade is 4325378
[ 115.506858] CPU grade = 2 [00000002]
[ 115.512868] Number of clock steps = 4
[ 115.536780] Clock step[0] = 198000
[ 115.542604] Clock step[1] = 396000
[ 115.568559] Clock step[2] = 528000
[ 115.586576] Clock step[3] = 792000
[ 115.621704] policy clock = 2189893632
[ 115.662062] policy current = 24000
[ 115.695058] policy suspend = 792000
[ 115.700857] frequency[0] = 198000
[ 115.737995] Set target frequency skipped [OF=24000, NF=198000]
[ 115.775595] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 24000 KHz, changing to: 198000 KHz
[ 115.810147] Set target frequency skipped [OF=24000, NF=198000]
[ 116.090206] imx_thermal 20c8000.anatop:tempmon: Industrial CPU temperature grade - max:105C critical:100C passive:95C

# echo 198000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 1852.345245] Set target frequency skipped [OF=24000, NF=198000]

# echo 396000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 1887.200273] 198 MHz, 1150 mV --> 396 MHz, 1025 mV
[ 1887.209614] Bus Frequency High requested (LPR + Lowest Freq)
[ 1887.225491] VDD_PU set to 1175000 uV
[ 1887.227245] VDD_SOC set to 1175000 uV
[ 1887.233090] VDD_ARM set to 1025000 uV
[ 1887.267384] Set ARM clock rate to 99000000 [Err = 0]
[ 1887.326338] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 1887.342686] Set source SECONDARY_SEL to parent PLL2_PFD2_396M [Err = 0]
[ 1887.354623] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 1887.362123] Set source PLL1_SW to parent STEP [Err = 0]
[ 1887.392227] Set ARM clock rate to 396000000

# echo 198000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 1963.627098] 396 MHz, 1025 mV --> 198 MHz, 950 mV
[ 1963.635415] Set ARM clock rate to 198000000 [Err = 0]
[ 1963.641562] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 1963.672254] Set source SECONDARY_SEL to parent PLL2_PFD2_396M [Err = 0]
[ 1963.726929] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 1963.784374] Set source PLL1_SW to parent STEP [Err = 0]
[ 1963.791249] Set ARM clock rate to 198000000
[ 1963.806756] VDD_ARM set to 950000 uV [Err = 0]
[ 1963.807276] VDD_SOC set to 1175000 uV [Err = 0]
[ 1963.812413] Bus Frequency High released (LPR + Lowest Freq)

2) If for any reason the 792MHz is not achievable, why is not reverting back to the previous frequency/voltage ?
Instead the system is programmed back to 24MHz.
I also think, the code expect the 792MHz to have being set properly because:
- there are no error reported by any "deverr" of the "imx6q_set_target" function.
- cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq returns 792000
- none of the instructions failed during the process (see printk's output below)

returns from my added printk's:

# echo 792000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 5439.390660] 528 MHz, 1175 mV --> 792 MHz, 1225 mV
[ 5439.398097] VDD_PU set to 1175000 uV
[ 5439.398338] VDD_SOC set to 1175000 uV
[ 5439.402688] VDD_ARM set to 1225000 uV
[ 5439.415987] Set ARM clock rate to 264000000 [Err = 0]
[ 5439.446903] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 5439.496090] Set source SECONDARY_SEL to parent PLL2_BUS [Err = 0]
[ 5439.525964] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 5439.569613] Set source PLL1_SW to parent STEP [Err = 0]
[ 5439.579642] New Freq (792000000) > PLL2_BUS Freq (528000000)
[ 5439.600478] Set PLL1_SYS clock rate to 792000000 [Err = 0]
[ 5439.625774] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 5439.658958] Set ARM clock rate to 792000000

"Err" value is the return of the instruction that make the change reported by the printk from the "imx6q_set_target" function.

Best Regards,
Emmanuel

[Zhiming_Liu]

Hi @manux 

From the first log, the driver Set target frequency skipped [OF=24000, NF=198000]. It looks like it's a dts configuration issue. 

I find a reference dts: https://github.com/sallenkey-wei/I.MX6ull_test/blob/master/IMX6ULL/linux/linux-imx-rel_imx_4.1.15_2....

You can try to add power supply node and define reg_arm & reg_soc referring your hardware.

&cpu0 {
	arm-supply = <&reg_arm>;
	soc-supply = <&reg_soc>;
	dc-supply = <&reg_gpio_dvfs>;
};

Best Regards,
Zhiming

[manux]

Hi Zhiming,

Thank you very much for the info.
I cheched my devtree and I already have the "arm-supply = <&reg_arm>;" and "soc-supply = <&reg_soc>;".
I tried to add the "dc-supply = <&reg_gpio_dvfs>;" but then I got a compilation error:
ERROR (phandle_references): /cpus/cpu@0: Reference to non-existent node or label "reg_gpio_dvfs"

But You may have a good point, perhaps my devicetree is no longer adequate for more recent kernels.
My dts and dtsi have evolved from the ones I had when I started working on my EVK few years ago.
And at the time the MCIMX6Y2CVM08AB was not released yet.
I will compare my files against the ones found in the kernel 6.6.52-2.2.0 source tree.

Additional info:
After adding some more printk, it seems that the problem is not being able to program the PLL1_SYS to anything higher than 24MHz.
Even when the driver uses the PLL1_SYS to set the CPU speed to half speed as a temporarily step, it does get set properly and there is no check in the code to ensure proper operation, see messages below:

# echo 396000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 640.347357] 198 MHz, 1150 mV --> 396 MHz, 1025 mV
[ 640.357356] Bus Frequency High requested (LPR + Lowest Freq)
[ 640.390490] VDD_PU set to 1175000 uV [Err = 0]
[ 640.392715] VDD_SOC set to 1175000 uV [Err = 0]
[ 640.434222] VDD_ARM set to 1025000 uV [Err = 0]
[ 640.450313] Set ARM clock rate to 99000000 [Err = 0]
[ 640.493786] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 640.531225] Verify ARM clock rate: 24000000 [s/b 99000000] <--------------------
[ 640.559520] Set source SECONDARY_SEL to parent PLL2_PFD2_396M [Err = 0]
[ 640.584828] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 640.610393] Set source PLL1_SW to parent STEP [Err = 0]
[ 640.616774] Set ARM clock rate to 396000000 [Err = 0]
[ 640.637178] Verify ARM clock rate: 396000000 [s/b 396000000]

# echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 909.426387] 396 MHz, 1025 mV --> 528 MHz, 1175 mV
[ 909.433897] VDD_PU set to 1175000 uV [Err = 0]
[ 909.434188] VDD_SOC set to 1175000 uV [Err = 0]
[ 909.446158] VDD_ARM set to 1175000 uV [Err = 0]
[ 909.470331] Set ARM clock rate to 198000000 [Err = 0]
[ 909.489266] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 909.521505] Verify ARM clock rate: 12000000 [s/b 198000000] <--------------------
[ 909.570184] Set source SECONDARY_SEL to parent PLL2_BUS [Err = 0]
[ 909.591569] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 909.610621] Set source PLL1_SW to parent STEP [Err = 0]
[ 909.616925] Set ARM clock rate to 528000000 [Err = 0]
[ 909.651071] Verify ARM clock rate: 528000000 [s/b 528000000]

Thanks again for your support.

Best Regards,
Emmanuel

[Zhiming_Liu]

Hi @manux 

Yes, I agree with you. The driver fail to set 198MHz from 24MHz. At least there's something missing from the device tree. Does your power desgin support DVFS? 

Set target frequency skipped [OF=24000, NF=198000]

Best Regards,
Zhiming

[manux]

Hi Zhiming,

Originally I was planning to use the "ondemand" governor to have the CPU voltage and frequency automatically adjusted depending on the CPU load.
But for the time being I am just using the "userspace" to debug why the system doesn't go over 528MHz.

I re-created a new "dtsi" file for my system by copying integrally the content of "imx6ul.dtsi" and "imx6ull.dtsi" from the "linux-imx-lf-6.6.52-2.2.0" source tree.
I also tested the new rebuild with another of my board, just in case the first one had a defective CPU.
But unfortunately nothing changed, the PLL1_SYS seems to be limited to 24MHz.
It looks like the PLL1_SYS is stuck in bypass mode.
As long as the requested frequency is lower or equal to 528MHz everything is fine, PLL1_SW connect to STEP connected to SECONDARY_SEL connected to PLL2.
When the frequency needs to be above 528MHz, PLL1_SW must connect to PLL1_SYS but it is stuck at 24MHz.

I have attached the "/sys/kernel/debug/clk/clk_summary" for each frequency setting.
As you can see "PLL1_SYS" is always 24000000.

Best Regards,
Emmanuel

[Zhiming_Liu]

Hi @manux 

Can you debug these code behavior here in imx6ul_opp_check_speed_grading? Tracing the call of imx6x_disable_freq_in_opp.

	/*
	 * Speed GRADING[1:0] defines the max speed of ARM:
	 * 2b'00: Reserved;
	 * 2b'01: 528000000Hz;
	 * 2b'10: 696000000Hz on i.MX6UL, 792000000Hz on i.MX6ULL;
	 * 2b'11: 900000000Hz on i.MX6ULL only;
	 * We need to set the max speed of ARM according to fuse map.
	 */
	val >>= OCOTP_CFG3_SPEED_SHIFT;
	val &= 0x3;

	if (of_machine_is_compatible("fsl,imx6ul"))
		if (val != OCOTP_CFG3_6UL_SPEED_696MHZ)
			imx6x_disable_freq_in_opp(dev, 696000000);

	if (of_machine_is_compatible("fsl,imx6ull")) {
		if (val < OCOTP_CFG3_6ULL_SPEED_792MHZ)
			imx6x_disable_freq_in_opp(dev, 792000000);

		if (val != OCOTP_CFG3_6ULL_SPEED_900MHZ)
			imx6x_disable_freq_in_opp(dev, 900000000);
	}

There are some patches included in latest linux: History for drivers/cpufreq/imx6q-cpufreq.c - nxp-imx/linux-imx , maybe you can try the 6.12.3.


Best Regards,
Zhiming

[manux]

Hi Zhiming,

I partially fixed my problem by modifying the "imx6q-cpufreq" driver.
Apparently the "PLL1_BYPASS" is routed by default to "PLL1_BYPASS_SRC" being 24MHZ.
Therefore when "PLL1_SYS" parent is set to "PLL1_BYPASS" instead of "STEP" to allow for a frequency greater than 528MHz, it can't be programmed higher than 24MHz.

Scaling governor : 'userspace'
Scaling frequency: '792000'
CPU frequency : '24000'
arm (24000000)
pll1_sw (24000000)
pll1_sys (24000000)
pll1_bypass (24000000)
pll1_bypass_src (24000000)
osc (24000000)

I fixed the PLL1 routing to the driver by adding the 2 following lines in front of the "PLL1_SW" routing:

Added:
ret = clk_set_parent(clks[PLL1_BYPASS].clk, clks[PLL1].clk);
ret = clk_set_parent(clks[PLL1_SYS].clk, clks[PLL1_BYPASS].clk);
In front of:
ret = clk_set_parent(clks[PLL1_SW].clk, clks[PLL1_SYS].clk);

Now here is what happens when I set 792MHz:

# echo 792000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 572.153108] 528 MHz, 1175 mV --> 792 MHz, 1225 mV
[ 572.160512] VDD_PU set to 1175000 uV [Err = 0]
[ 572.160847] VDD_SOC set to 1175000 uV [Err = 0]
[ 572.173439] VDD_ARM set to 1225000 uV [Err = 0]
[ 572.193463] Set source PLL1_BYPASS to parent PLL1 [Err = 0]
[ 572.212726] Set source PLL1_SYS to parent PLL1_BYPASS [Err = 0]
[ 572.233746] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 572.249253] Set ARM clock rate to 264000000 [Err = 0]
[ 572.255365] Verify ARM clock rate: 264000000 [s/b 264000000] <-------------------- (1)
[ 572.275037] Set source SECONDARY_SEL to parent PLL2_BUS [Err = 0]
[ 572.286820] Set source STEP to parent SECONDARY_SEL [Err = 0]
[ 572.293659] Set source PLL1_SW to parent STEP [Err = 0]
[ 572.312386] New Freq (792000000) > PLL2_BUS Freq (528000000)
[ 572.327136] Set source PLL1_BYPASS to parent PLL1 [Err = 0]
[ 572.333604] Set source PLL1_SYS to parent PLL1_BYPASS [Err = 0]
[ 572.353401] Set PLL1_SYS clock rate to 792000000 [Err = 0]
[ 572.367373] Verify PLL1_SYS clock rate: 792000000 [s/b 792000000] <-------------------- (2)
[ 572.388433] Set source PLL1_SW to parent PLL1_SYS [Err = 0]
[ 572.395655] Set ARM clock rate to 792000000 [Err = 0]
[ 572.402664] Verify ARM clock rate: 792000000 [s/b 792000000] <-------------------- (2)

# ./cpu_clk_route.sh
Scaling governor : 'userspace'
Scaling frequency: '792000'
CPU frequency : '792000' <-------------------- (3)
arm (792000000)
pll1_sw (792000000)
pll1_sys (792000000)
pll1_bypass (792000000)
pll1 (792000000)
osc (24000000)

(1) ARM frequency is now set properly to half speed as temporary step.
(2) ARM and PLL1_SYS frequency is now set properly in the final step.
(3) Frequency reported properly in "cpuinfo_cur_freq"

Now I have to fix the problem during the kernel initialization as it seems that "PLL1_SW" is not routed properly either.
Apparently "PLL1_SYS" is routed by default to "STEP" and as 792MHz can't be achieved by PLL2 it get set to "OSC".
Resulting in the same behavior of the CPU clock being set to 24MHz.

# ./cpu_clk_route.sh
arm (24000000)
pll1_sw (24000000)
step (24000000)
osc (24000000)

Best Regards,
Emmanuel

[Zhiming_Liu]

Hi @manux 

I did test after disabling 900MHz in opp table on EVK(L6.12.3). At least it proves that maybe it's not a software issue?

root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
792000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
198000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
792000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
792000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
396000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
528000
root@imx6ul7d:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
198000 396000 528000 792000

As the i.MX6ULL on EVK is not MCIMX6Y2CVM08AB. That's all I can do for now. Personally, I still have reservations: the likely cause is hardware.


Best Regards,
Zhiming

[manux]

Hi Zhiming,

I guess it possible that there is an incompatibility issue between the software and this specific model of i.MX6ULL (MCIMX6Y2CVM08AB).

May be the problem is also present on the MCIMX6Y2CVM05AB but as it is limited to 528MHz it is not noticeable and the problem get fixed in the 900MHz version.

But at the end the CPU is functional if programmed properly.

I wrote a new driver for the cpu-freq to handle the PLL1 properly and it works, I even optimized the sequence to avoid the need of the temporary half frequency setting.

I can set all the frequencies manually and they are all reported properly, including the 792MHz.

The "ondemand" governor also seems to work up to 792MHz, at least no crash so far.

The CPU performs much better than originally, the network is about 5 times faster.

Thank you very much for your help

Best Regards,
Emmanuel

[manux]

Hi Zhiming,

Yes, I already did and the grade reported is 2, supposedly 792MHz for a iMX6ULL.
See driver messages below.

# insmod imx6q-cpufreq.ko
[ 115.393111] low power run support = 1
[ 115.483249] nvmem-cells, speed_grade is 4325378
[ 115.506858] CPU grade = 2 [00000002] <--------------------
[ 115.512868] Number of clock steps = 4
[ 115.536780] Clock step[0] = 198000
[ 115.542604] Clock step[1] = 396000
[ 115.568559] Clock step[2] = 528000
[ 115.586576] Clock step[3] = 792000
[ 115.621704] policy clock = 2189893632
[ 115.662062] policy current = 24000
[ 115.695058] policy suspend = 792000
[ 115.700857] frequency[0] = 198000
[ 115.737995] Set target frequency skipped [OF=24000, NF=198000]
[ 115.775595] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 24000 KHz, changing to: 198000 KHz
[ 115.810147] Set target frequency skipped [OF=24000, NF=198000]
[ 116.090206] imx_thermal 20c8000.anatop:tempmon: Industrial CPU temperature grade - max:105C critical:100C passive:95C

I will try if the latest release 6.12.3_1.0.0 from NXP makes any difference.
I was also planning to test one of my older system to see if the problem was always there or it is sometimes introduced recently.
I guess it is also possible that I screwed up my new build.

I also found where the 24MHz get set, it is in the function "update_ddr_freq_imx6_up(int ddr_rate)" in "busfreq_ddr3.c".

#dmesg | grep -i "bus freq
[ 0.303601] Bus freq driver module loaded
[ 23.368054] Bus freq set to 24000000 start...
[ 23.368525] Bus freq set to 24000000 done!

Early in the boot the DDR bus speed is set to 400MHz, then after 23 sec it get set to 24MHz.
Apparently it could be related to the CPUIDLE.
Trying to prevent it freeze the kernel and the watchdog kicks in.
I will try to rebuild the kernel with the CPUIDLE disabled, to see if the bus would remain at higher frequency.

Thank you for your support.

Best Regards,
Emmanuel

[manux]

Thank you very much to keep looking into my problem.

The VDD_SOC_IN is powered with a 3A voltage regulator (RT5753ALGQWA) set to 1.362V (measured 1.374V).
I was aware that the VDD_SOC_IN needs to be 125mV above VDD_ARM_CAP and VDD_SOC_CAP to operate properly.
Therefore theoretically VDD_SOC_IN is above the minimum 1.325V and VDD_ARM_CAP (1.362 - 0.125 = 1.237) is above the minimum 1.2V.
I use 3x10uF + 1x22uF capacitors the regulator output (recommended to be between 44uF and 66uF).
These capacitors are MLCC and I used 4 of them to have a low ESR.
For all the CPU decoupling capacitors, I use the same values as the EVK and are located very close to the pads at the back of the CPU.
All capacitors are high temperature rated and at least rated for 3 times the expected voltage.
Unfortunately I have no access to measure VDD_ARM_CAP or VDD_SOC_CAP with a scope.
As mentioned above all the decoupling capacitors are located on the back of the CPU on the bottom side of the board and the board needs to be plugged to a backplane to operate.

Best Regards,
Emmanuel

[manux]

Hi Zhiming,
I forgot to mention that my PLL1 is set to 792MHz.
At least that what the "clk_summary" reports.