The CPU frequency can't reach the maximum frequency

Hi Nvidia,

SDK: Jetpack 7 R38.2 flashed onto a designed carrier board.

Execute the following commands:
sudo mvpmodel -m 0
sudo jetson_clocks
After running sudo tegrastats, the CPU frequency did not reach 2.6 GHz.

However, this issue was not observed on the Jetson AGX Thor devkit.

I would like to query Nvidia: If the INA238 chip is removed from the designed carrier board, will this allow the CPU, GPU, or EMC frequencies to reach their maximum?
Although attempting to increase the CPU frequency at the OS level, will it be restricted by the BPMP Firmware?

If the INA238 chip is replaced, which parts should be modified?
Besides modifying the following in source/hardware/nvidia/t264/nv-public/nv-platform/tegra264-p4071-0000.dtsi:

i2c@c600000 {
ina238@44 {
compatible = “ti,ina238”;
reg = <0x44>;
shunt-resistor = <2000>;
status = “okay”;
label = “VIN”;
};
};

No INA238-related information was found in bootloader or source/hardware/nvidia/t264/nv-public/. The only exception is the bootloader/rcmboot_blob/blob.bin file, but I believe this part is not provided by Nvidia for external modification.

Thanks.

Hi pomelo_hsieh,

What’s your customization different from the devkit?

Could you add INA234 chip back to confirm if the issue is caused from it?

Hi Kevin

What’s your customization different from the devkit?

——>We used an ADC IC instead of a power monitor( INA234 ), allowing us to only detect the input voltage of the carrier board.

Could you add INA234 chip back to confirm if the issue is caused from it?

——>No, we don’t have INA234 chip, so we can’t do the exchange experiment

Will there be any answers to the following questions, Does INA238 have any other functions besides detect power consumption by overall system and OCP function?

If the INA238 chip is removed from the designed carrier board, will this allow the CPU, GPU, or EMC frequencies to reach their maximum?

Thanks!

Channel 1: VIN is monitored by INA238.
Please refer to Jetson Thor Product Family — NVIDIA Jetson Linux Developer Guide for details.

Please let me check this with internal team.

Hi Kevin,

Updating some information. After running the tegrastats command, the kernel log continuously displays:
[ 632.321699] cpufreq: cpu8,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 632.328670] cpufreq: cpu10,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 632.335662] cpufreq: cpu10,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.365966] cpufreq: cpu0,cur:650000,set:2601000,delta:1951000,set ndiv:2899
[ 633.366032] cpufreq: cpu0,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 633.366097] cpufreq: cpu2,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.373040] cpufreq: cpu2,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.380016] cpufreq: cpu4,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.387008] cpufreq: cpu4,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 633.393993] cpufreq: cpu6,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.400978] cpufreq: cpu6,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.407955] cpufreq: cpu8,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 633.414949] cpufreq: cpu8,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 633.421923] cpufreq: cpu10,cur:649000,set:2601000,delta:1952000,set ndiv:289
[ 633.428915] cpufreq: cpu10,cur:650000,set:2601000,delta:1951000,set ndiv:289
[ 634.459337] cpufreq: cpu0,cur:649000,set:2601000,delta:1952000,set ndiv:2899
[ 634.459402] cpufreq: cpu0,cur:650000,set:2601000,delta:1951000,set ndiv:289

It seems that SYSTEM_OC_N pin gets asserted with the removal of INA238.
When SYSTEM_OC_N is asserted, CPUfreq and GPUfreq will be throttled by 75%, that’s why you see ~650MHz on CPU.
Please add external pull up for SYSTEM_OC_N.

Hi Kevin

Thank you for your reply.
We added the pull-up of SYSTEM_OC_N by 4.7k to VDD_1.8V, and the measured status of SYSTEM_OC_N is H, but the CPU frequency remains at 650MHz. Is the pull-up of SYSTEM_OC_N required to be always on?

Yes, it is required as you’ve removed INA238 on your custom carrier board.

Hi Kevin,

I think I’ve found the cause. It’s because SOC_THERM_OC2 was set to unused in the pinmux template.
Do you know which pins in Jetson_Thor_Series_Modules_Pinmux_Template_v1.4.xlsm absolutely cannot be reconfigured?

Thanks.

It is configured as SOC_THERM_OC2/Input by default.
image

Pinmux spreadsheet is used to configure the pins according to your use case.
Unconfigurable pins have been hidden.