AM62 CPU OPP table

Hello there!

We are currently running some load tests on the Verdin AM62 module to ensure it will be able to handle the load/heat, that our product promises. This has lead to me checking up on CPU scaling, as we have no active cooling planned for the product. In researching this, I noticed the following log as part of dmesg:

[    1.356156] cpu cpu0: _of_add_opp_table_v2: no supported OPPs
[    1.361982] cpu cpu0: OPP table can't be empty

And when running cpufreq-info, I’m greeted with the following message:

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
analyzing CPU 2:
  no or unknown cpufreq driver is active on this CPU
analyzing CPU 3:
  no or unknown cpufreq driver is active on this CPU

It seems to me, that the OPP table defined in k3-am625.dtsi isn’t being accepted and I was wondering if this might affect the passive throttling of the CPU under loads producing high heat.
If so, are there any pointers as to how this might get fixed? I’ve not made any changes to the k3-am625.dtsi file, nor affected any of the phandles, in the device tree used for our product. The device tree files used are the ones from the downstream-based kernel, branch toradex_ti-linux-6.1.y.

Here is the output of tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.1.83-6.7.0+git.0a32d33d5fb7 #1-TorizonCore SMP PREEMPT Fri Jun 28 09:20:37 UTC 2024
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/0e8ba090352924ac981a8438306dfa37763d2cf0905c20e802c36746179ea748/0
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.7.0-build.18
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-am62-15380658
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin AM62 WB on prototype mk1
Toradex version:          0076 V1.1C
Serial number:            15380658
Processor arch:           aarch64
------------------------------------------------------------

Best regards,
Sophus

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Based on the context provided, it seems that the issue you’re encountering with the Verdin AM62 module is related to the CPU frequency scaling and the OPP (Operating Performance Points) table not being recognized or properly configured. This can affect the CPU’s ability to scale its frequency and manage heat through passive throttling.

Here are a few pointers that might help address the issue:

  1. Check Device Tree Configuration: Ensure that the OPP table is correctly defined in the k3-am625.dtsi file. Verify that the entries are complete and correctly formatted. Any missing or incorrect entries could lead to the OPP table not being recognized.

  2. Kernel Configuration: Make sure that the kernel is configured to support CPU frequency scaling. This includes enabling the necessary drivers and options in the kernel configuration. You might need to check if the CPU frequency scaling driver for the AM62 is enabled.

  3. Driver Support: Verify that the appropriate CPU frequency scaling driver is loaded and active. The message from cpufreq-info suggests that no driver is active, which could mean that the driver is not compiled into the kernel or not being loaded at runtime.

  4. Logs and Debugging: Check the kernel logs (dmesg) for any additional messages related to CPU frequency scaling or OPP table issues. These logs might provide more insight into what is going wrong.

  5. Consult Documentation: Review any available documentation or errata for the Verdin AM62 module and the associated SoC. There might be known issues or additional steps required to enable CPU frequency scaling.

  6. Community and Support: If the issue persists, consider reaching out to the Toradex community or support channels. They might have more specific insights or patches that address this issue.

If these steps do not resolve the issue, it might be necessary to delve deeper into the kernel and device tree configurations or seek further assistance from Toradex support.

Please, also check if these links can help you solve your problem:

iMX8M Plus PREEMPT_RT gets rebooted with rt-validation stress tests.

This issue is fixed in the 7.1 release

Sorry, I should’ve checked for known issues.

Is the 7.1 BSP release part of the TorizonOS 6.8.0 build?

No, It’s a part of Torizon OS 7.1 build.

Thanks! I’ll have a look at it. I was not aware of the artifacts page. I had been using the official homepage download links resources. The issue is marked resolved.