Hi everyone,
We are currently doing tests on the MIMX8QM5CVUFFAB and found some strange behaviour regarding clocks. The first thing we noted is that even though the clock is limited to 1.3 GHz for the Cortex A72 and 1.104 GHz for the Cortex A53, the cpufreq driver allows us to set the higher frequency of 1.6 GHz and 1.2 GHz. The SCFW seems to correctly ignore the higher frequencies but this leads to a missmatch between cpufreq and the actual clock rate:
root@apalis-imx8-15556460:~# cat /sys/bus/cpu/devices/cpu4/cpufreq/scaling_cur_freq
1596000
root@apalis-imx8-15556460:~# cat /sys/kernel/debug/clk/clk_summary |grep a72
a72_clk 0 0 0 1296000000 0 0 50000 Y cpu4 no_connection_id
root@apalis-imx8-15556460:~# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_cur_freq
1200000
root@apalis-imx8-15556460:~# cat /sys/kernel/debug/clk/clk_summary |grep a53
a53_clk 0 0 0 1104000000 0 0 50000 Y cpu0 We would expect that this is either solved by a special cpufreq driver or then by a fdt fixup in U-Boot. However, I can't find any of this solutions in the BSP. Can you confirm that this is currently not implemented?
A second clocking issue affects the GPU, even though according to the datasheet the GPU should only run at 625 MHz it runs at 800MHz:
root@apalis-imx8-15556460:~# cat /sys/kernel/debug/gc/clk
gpu0 mc clock: 797983833 HZ.
gpu0 sh clock: 996002801 HZ.
gpu1 mc clock: 798002539 HZ.
gpu1 sh clock: 995989749 HZ.
root@apalis-imx8-15556460:~# cat /sys/kernel/debug/clk/clk_summary |grep gpu
gpu_shader1_clk 0 0 0 996000000 0 0 50000 Y 54100000.gpu shader
gpu_core1_clk 0 0 0 798000000 0 0 50000 Y 54100000.gpu core
gpu_shader0_clk 0 0 0 996000000 0 0 50000 Y 53100000.gpu shader
gpu_core0_clk 0 0 0 798000000 0 0 50000 Y 53100000.gpuHere the SCFW does not limit the clock, which seems to be a violation of what is written in the datasheet. My expectation would also be here that there is a fdt fixup in U-Boot to address this but I could not find it. Can you confirm that this is currently not implemented?
The version of the SCFW, ATF and U-Boot should be recent enough to properly support the i.MX8QM with the 1.3 GHz limitation:
U-Boot 2024.04-34984-g64f00b21ff8 (Dec 04 2024 - 14:42:45 +0100)
CPU: NXP i.MX8QM RevB A53 at 1104 MHz at 33C
DRAM: 4 GiB
Core: 203 devices, 24 uclasses, devicetree: separate
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Model: Toradex 0091 Apalis iMX8QM 4GB WB IT V1.1A
Serial#: 15556460
Boot: MMC0
Reset cause: POR
BuildInfo:
- SCFW 83624b99, SECO-FW c9de51c0, IMX-MKIMAGE ca5d6b2d, ATF 616a458
- U-Boot 2024.04-34984-g64f00b21ff8Best regards,
Stefan
current bsp is based on nxp mek board, don't find specific bsp for industrial, you can change the bsp by yourself
Hi @joanxie
Thanks for the update. Can you point me to the right BSP for the industrial version of the i.MX8?
Thanks and best regards
Stefan
the bsp you used isn't for industrial, so the A72 core define 1596000000 as max, you can remove
this from a72_opp_table: opp-table-1
linux-imx/arch/arm64/boot/dts/freescale/imx8qm.dtsi at lf-6.6.y · nxp-imx/linux-imx · GitHub
you also can refer to this workaround, for the 1.3G imx8qm
[OUTDATED] Workaround for de-rating i.MX 8QM/QP parts before SCFW 1.16.0 releases - NXP Community
Hi @joanxie
The following versions are used:
SCFW: 1.17.0 (83624b99)
U-Boot: lf_v2022.04 https://github.com/nxp-imx/uboot-imx/tree/lf_v2024.04
Linux: lf-6.6.y https://github.com/nxp-imx/linux-imx/tree/lf-6.6.y
Regards,
Stefan
what bsp version and SCFW version do you test? let me double check it