RPi 3B does not scale down core voltage along with arm_freq

[nadrimajstor]

Describe the bug RPi 3B is excessively overheating on a non trivial workload. CPU throttling is unhelpful as the core voltage does not scale down with ~~core clock~~ arm_freq.

To reproduce Take a RPi model 3B and boot with firmaware after Apr 15 2020 version 82f9bb929ce2186eb1824178c1ae82902ad6275c

Expected behaviour Core voltage should follow ~~core clock~~ arm_freq, namely when thermal throttling kicks in and ~~core~~ arm_freq goes to 600MHz the core voltage should go down to 1.2000V.

Actual behaviour Core voltage does not follow ~~core clock~~ arm_freq, that is when thermal throttling scales down ~~core clock~~ arm_freq to 600MHz the core voltage stays at 1.3312V

System

• Raspberry Pi 3 Model B Rev 1.2
• Arch Linux ARM
• Jan 18 2023 12:29:24 version 658f02cc8edcb68a568273f05d2b6ceede181e15
• Linux betmedrpi 5.15.89-3-rpi-ARCH #1 SMP Tue Jan 24 05:08:11 MST 2023 armv7l GNU/Linux

Logs n/a

Additional context Tried booting with older files in boot/{*.dat,*.bin,*.elf} and AFAICT firmware from Apr 15 2020 is the last one where core voltage down-scaling was operative on a 3B board. For example:

[root@rpi3b ~]# vcgencmd vcos version
Apr 15 2020 11:43:08
Copyright (c) 2011 Broadcom
version 82f9bb929ce2186eb1824178c1ae82902ad6275c (clean)
host buildbot
[root@rpi3b ~]# vcgencmd get_config int
aphy_params_current=819
arm_freq=1200
arm_freq_min=600
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x387520
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
init_uart_clock=0x2dc6c00
lcd_framerate=60
mask_gpu_interrupt0=1024
mask_gpu_interrupt1=0x10000
over_voltage_avs=0x200b2
pause_burst_frames=1
program_serial_random=1
ramfsaddr=-1
sdram_freq=450
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x9a7ec80
hdmi_pixel_freq_limit:1=0x9a7ec80
[root@rpi3b ~]# (vcgencmd measure_clock arm ; vcgencmd measure_clock pllb ; vcgencmd measure_volts core) | column
frequency(45)=1200126000        frequency(0)=0                  volt=1.3312V
[root@rpi3b ~]# echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
[root@rpi3b ~]# (vcgencmd measure_clock arm ; vcgencmd measure_clock pllb ; vcgencmd measure_volts core) | column
frequency(45)=600000000 frequency(0)=0          volt=1.2000V

Looks like subsequent firmware versions have inoperative core voltage downscaling. For example:

[root@rpi3b ~]# vcgencmd vcos version
Apr 16 2020 12:33:18
Copyright (c) 2011 Broadcom
version 30355345c483638d3f8b013f58f0ee17094e7de2 (clean)
host buildbot
[root@rpi3b ~]# vcgencmd get_config int
aphy_params_current=819
arm_freq=1200
arm_freq_min=600
audio_pwm_mode=514
config_hdmi_boost=5
core_freq=400
desired_osc_freq=0x387520
disable_commandline_tags=2
disable_l2cache=1
disable_overscan=1
display_hdmi_rotate=-1
display_lcd_rotate=-1
dphy_params_current=547
enable_tvout=1
force_eeprom_read=1
force_pwm_open=1
framebuffer_ignore_alpha=1
framebuffer_swap=1
gpu_freq=300
init_uart_clock=0x2dc6c00
lcd_framerate=60
mask_gpu_interrupt0=1024
mask_gpu_interrupt1=0x10000
over_voltage_avs=0x200b2
pause_burst_frames=1
program_serial_random=1
ramfsaddr=-1
sdram_freq=450
total_mem=1024
hdmi_force_cec_address:0=65535
hdmi_force_cec_address:1=65535
hdmi_pixel_freq_limit:0=0x9a7ec80
[root@rpi3b ~]# (vcgencmd measure_clock arm ; vcgencmd measure_clock pllb ; vcgencmd measure_volts core) | column
frequency(48)=800084000         frequency(100)=2400000000       volt=1.3312V
[root@rpi3b ~]# echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
[root@rpi3b ~]# (vcgencmd measure_clock arm ; vcgencmd measure_clock pllb ; vcgencmd measure_volts core) | column
frequency(48)=600000000         frequency(100)=1200000000       volt=1.3312V

[popcornmix]

Try vcgencmd measure_clock v3d. I'm seeing 300MHz and that causes the voltage to increase.

That request comes from the v3d kernel driver.

If you comment out dtoverlay=vc4-kms-v3d I think you'll find v3d clock isn't boosted and you get 1.2V.

We need to think about what the behaviour should be for arm clock boosts when throttling. (Some are not optional, like any boosted clocks required for hdmi 4kp60 on a Pi 4).

[popcornmix]

When Pi4 came out we maintained an original firmware tree (for pi0-3 firmware), and a Pi4 firmware tree in parallel. And at some point we switched the pi0-3 over to the pi4 tree, which was became a common tree.

This is the final commit of the original (pi0-3) firmware tree.

[root@rpi3b ~]# vcgencmd vcos version
Apr 15 2020 11:43:08
Copyright (c) 2011 Broadcom
version 82f9bb929ce2186eb1824178c1ae82902ad6275c (clean)

This is the first commit that switched to the Pi4 tree

[root@rpi3b ~]# vcgencmd vcos version
Apr 16 2020 12:33:18
Copyright (c) 2011 Broadcom
version 30355345c483638d3f8b013f58f0ee17094e7de2 (clean)

which means a lot of code changed at that point.

[popcornmix]

I've tested actual throttling on a pi3 and seems to behave as desired. When the temperature reaches the critical temperature, v3d goes from 300Mhz to 250MHz and core voltage from 1.2875 to 1.2.

What temperature are you getting when stressing the Pi, and seeing core voltage still at 1.3312V

[nadrimajstor]

@popcornmix I'm truly sorry for my incorrect wording. I've updated the comment and title to reflect that I've been looking at arm_freq value. Using firmware after Apr 15 2020 no matter what I do, changing scaling_governor to powersave on an idle system, or waiting a couple of minutes running a simple web app in chromium to reach 85°C, core voltage is always at volt=1.3312V. It affects only 3B model. Same image on a 3B+ board works as expected.

[popcornmix]

With a pi3 model B running a heavy stress (with processor with limited air flow) I get: https://pastebin.com/MZx7YfWP

This shows as temperature exceeds 80'C the arm gets throttled, and when arm is sufficiently throttled (below 600MHz, about 86'C) the gpu clocks (core, v3d) are throttled and voltage returns to 1.2V.

On my board it is behaving as expected. If your load doesn't reach 600MHz/86'C then you won't see the gpu side throttled and the voltage drop.

[nadrimajstor]

@popcornmix You are right. My image does have dtoverlay=vc4-fkms-v3d and indeed that is why I don't see 1.2V on a powersave scaling_governor. If that is expected behavior I should rephrase the title and comment. My bad for trying to be smart, as the actual issue is: When temperature reaches 86°C I get no signal on the monitor. If I put boot/{*.dat,*.bin,*.elf} files from the Apr 15 2020 build when temperature reaches 86°C I get icon showing a fully-filled thermometer.

[popcornmix]

When temperature reaches 86°C I get no signal on the monitor.

Do you also have this issue with dtoverlay=vc4-kms-v3d (that's the default these days)? What hdmi mode are you in when this happens?

[nadrimajstor]

For what it's worth, archlinuxarm did have as default dtoverlay=vc4-kms-v3d, however with that setting xserver had a blank screen, so I've changed to dtoverlay=vc4-fkms-v3d.

Today I've tested:

• 3B with state 0xa [HDMI CUSTOM RGB full 16:9], 1920x1080 @ 60.00Hz, progressive
• 3B+ with state 0x6 [DVI CUSTOM RGB full 16:9], 1920x1080 @ 60.00Hz, progressive

both gave no signal at 86°C.