RPi 4 aarch64 2.1GHz overclock

Having issues with your DietPi installation or found a bug? Post it here.
Post Reply
desty_nova
Posts: 9
Joined: Fri Jul 03, 2020 3:48 pm

RPi 4 aarch64 2.1GHz overclock

Post by desty_nova »

Hello everyone!

I have a Raspberry Pi 4 aarch64 running DietPi v7.0.2. I'm trying to overclock it to 2.1Ghz, but it won't boot past the preset profiles at 1.9 GHz.
I already tried reduce to 2.0Ghz and adjust overvolt to 5 and then 6, but nothing happened.
Can somebody please enlighten me on what I'm missing? I only changed settings on /boot/config. Is there another place?
User avatar
MichaIng
Site Admin
Posts: 2783
Joined: Sat Nov 18, 2017 6:21 pm

Re: RPi 4 aarch64 2.1GHz overclock

Post by MichaIng »

What do you mean with "it won't boot past..."?
If it does not boot, then I bet 2.0 GHz is simply too high for your board. As it's not stable, we don't have it as preset ;).
Or do you mean that it still sticks with 1.9 GHz, even you changed the config file to clock higher? In this case please show your config.txt.
desty_nova
Posts: 9
Joined: Fri Jul 03, 2020 3:48 pm

Re: RPi 4 aarch64 2.1GHz overclock

Post by desty_nova »

MichaIng wrote: Fri Mar 19, 2021 9:52 am What do you mean with "it won't boot past..."?
I mean that I simply won't boot. I saw some discussions, including this forum that the boar can hold up to 2147 MHz if you have the proper cooling system (which I have). They even mentioned this tutorial.The only thing that I haven't done is this command sudo apt updatesudo apt dist-upgradesudo rpi-update, because I fear that things may conflict in the future with a dietpi-update.
MichaIng wrote: Fri Mar 19, 2021 9:52 am Or do you mean that it still sticks with 1.9 GHz, even you changed the config file to clock higher? In this case please show your config.txt.
If I set the clock through the presets menu, it will boot, but if I try to change the arm_freq value to 2100 direct in the config file, the board won't boot. I really don't know how the system works beyond setting the the values, so I have a theory this values might be conflicting somehow with the expected values set in the config file.

In case I run the sudo apt updatesudo apt dist-upgradesudo rpi-update command mentioned above, what could the consequences in the future updates?
And here is my config file as requested:

Code: Select all

# Docs: https://www.raspberrypi.org/documentation/configuration/config-txt/

#-------Display---------
# If you get no picture, set the following to "1" to apply most compatible HDMI settings.
#hdmi_safe=1

# Uncomment to adjust the HDMI signal strength if you have interferences, blanking, or no display.
# - Values from "0" to "11" are allowed, use values above "7" only if required, e.g. with very long HDMI cable.
# - Default on first RPi1 A/B is "2", else "5", on RPi4 this setting is ignored.
#config_hdmi_boost=5

# Uncomment if HDMI display is not detected and composite is being outputted.
#hdmi_force_hotplug=1

# Uncomment to disable HDMI even if plugged, e.g. to force composite output.
hdmi_ignore_hotplug=1

# Uncomment to force a console size. By default it will be display's size minus overscan.
framebuffer_width=16
framebuffer_height=16

# Uncomment to enable SDTV/composite output on RPi4. This has no effect on previous RPi models.
#enable_tvout=0
# SDTV mode
#sdtv_mode=0

# Uncomment to force a specific HDMI mode (this will force VGA).
#hdmi_group=1
#hdmi_mode=1

# Uncomment to force an HDMI mode rather than DVI. This can make audio work in DMT (computer monitor) modes.
#hdmi_drive=2

# Set "hdmi_blanking=1" to allow the display going into standby after 10 minutes without input.
# With default value "0", the display shows a blank screen instead, but will not go into standby.
# NB: With "1" some applications (e.g. Kodi, OMXPlayer) cannot prevent display standby due to missing DPMS signal.
hdmi_blanking=1

# Set to "1" if your display has a black border of unused pixels visible.
disable_overscan=1

# Uncomment the following to adjust overscan. Use positive numbers if console goes off screen, and negative if there is too much border.
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# Rotation
display_hdmi_rotate=0
lcd_rotate=0

#-------RPi camera module-------
#start_x=1
#disable_camera_led=1

#-------GPU memory splits-------
gpu_mem_256=16
gpu_mem_512=16
gpu_mem_1024=16

#-------Boot splash screen------
disable_splash=1

#-------Onboard sound----------
dtparam=audio=off

#-------I2C-------------
dtparam=i2c_arm=off
dtparam=i2c1=off
#dtparam=i2c_arm_baudrate=100000

#-------SPI-------------
dtparam=spi=off

#-------Serial/UART-----
# NB: Enabled for 1st run only. If you want to keep this setting, please set CONFIG_SERIAL_CONSOLE_ENABLE=1 in dietpi.txt before 1st boot.
core_freq=500
enable_uart=0

#-------Overclock-------
temp_limit=75
initial_turbo=60

over_voltage=4
arm_freq=1900
#core_freq=500

#over_voltage_min=0
#arm_freq_min=300
#core_freq_min=250
#sdram_freq_min=400
arm_64bit=1
dtoverlay=dietpi-disable_vcsm
dtoverlay=disable-wifi
max_framebuffer_width=16
max_framebuffer_height=16

User avatar
Joulinar
Posts: 4249
Joined: Sat Nov 16, 2019 12:49 am

Re: RPi 4 aarch64 2.1GHz overclock

Post by Joulinar »

Installation of rpi-update will not change anything at first stage. You just install the tool itself. However, if you would run it afterwards, you will be bumped to next Raspberry Pi OS kernel (development)
Pls let us know if a solution is working. This could help others if they hit by similar situation. Your DietPi Team
desty_nova
Posts: 9
Joined: Fri Jul 03, 2020 3:48 pm

Re: RPi 4 aarch64 2.1GHz overclock

Post by desty_nova »

Thank you for the explanation! So I think it is safer to stay out of the development kernel.
User avatar
MichaIng
Site Admin
Posts: 2783
Joined: Sat Nov 18, 2017 6:21 pm

Re: RPi 4 aarch64 2.1GHz overclock

Post by MichaIng »

rpi-update is generally not recommended indeed, as long as it does not contain a specific fix for a specific issue you face with the stable kernel. It's a tool to test bleeding edge unstable development kernel and firmware versions.

Try to increase the ARM frequency in smaller steps, e.g
1950 Mhz first and overvoltage 5 if that does not boot. You may also want to test disabling initial turbo, if it helps as then the max frequency is not applied directly at boot. Every chip is different, so while some may work fine with even 2100 Mhz, others may not even with 2000 Mhz.

DietPi-Config btw checks for and applies the exact same config.txt settings, so it does not conflict with manual changes.
Post Reply