Is it possible to overclock the Rock Pi 4?

ioshomebrew · March 4, 2019, 8:54am

Hi, right now I’m looking into getting a Rock Pi 4, and I was wondering if it is possible to overclock the CPU or GPU?

Dante4 · March 4, 2019, 10:05am

In theory yes, because safe up limit of Rk3399 is 2.0 GHz for BIG cores and 1.5 for little (i.e. there is chips that works on this freq).
As for how, i have no idea. Maybe you need to edit device tree, but what exactly i don’t know

MrJim12 · March 4, 2019, 2:55pm

It should be possible.
mrfixit2001 has made following notice in announcement for the beta REcalbox release:

" Slight default overclock"

Can be found here:

ioshomebrew · March 4, 2019, 8:19pm

Do you know where you can edit the clock speed from the kernel source code?

O635789 · March 12, 2019, 1:14am

Honestly at this point if you could make most use of what the hardware is capable of, it will be good enough. The problem is most of the software like Chromium or VLC can’t even take the advantage of the chip at all.

stuartiannaylor · June 9, 2019, 11:25pm

Chromium is a problem all of its own as doesn’t support Linux hardware acceleration VLC can though.
Panfrost opensource drivers are out in Kernel 5.2 which should be interesting V4L2 also has but generally get confused with Mali.
Its likely that there will and could be acceleration but in terms of OC still interested as 2.0Ghz should be possible just dunno how toasty the heatsink gets but would be great to see what some tinkering with the DTS can get.
Also if there isn’t hardware accel then software via OC could help much.

github.com

armbian/build/blob/master/patch/kernel/rk3399-default/overclock-rk3399-to-1.5-2.0.patch

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
index 82514d1b..fddf3d7f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -121,6 +121,15 @@
 			opp-microvolt-L3 = <1050000 1050000 1200000>;
 			clock-latency-ns = <40000>;
 		};
+		opp-1512000000 {
+			opp-hz = /bits/ 64 <1512000000>;
+			opp-microvolt = <1200000>;
+			opp-microvolt-L0 = <1200000>;
+			opp-microvolt-L1 = <1175000>;
+			opp-microvolt-L2 = <1150000>;
+			opp-microvolt-L3 = <1125000>;
+			clock-latency-ns = <40000>;
+		};
 	};

 	cluster1_opp: opp-table1 {

This file has been truncated. show original

The A53 might go higher but guess its very much dependent on cooling, but they seem to have more headroom

ahillelt · July 5, 2019, 7:50pm

Wondering if anyone figured out how to play with overclock settings on Radxa Ubuntu Server release?

stuartiannaylor · July 5, 2019, 8:26pm

The above is Armbian not even sure if their default is running at 1.9/1.5 as opposed to 1.8/1.4.
Haven’t read up but the problem is with noobs not providing decent cooling rather than OC.

It should clock to 2.0/1.6 but the time needed for length of time runs to prove longterm effects means its just not been done yet.
I am going to run @ 2.0/1.6 but it will be quite a long time before I can say it works.

Armbian already seem to think the above is safe enough and maybe check there images as yes Ubuntu & Debian.

ahillelt · July 5, 2019, 8:36pm

Got it, thanks. I am using the large heatsink and put a fan on top of it, that should give it decent enough cooling to see if we push it to 2.0/1.6. I want to avoid having to recompile, so was curious if I could Nano into a file somewhere once operational.

stuartiannaylor · July 5, 2019, 8:47pm

You will have to test the Armbian images as found the above github ref and another from google @ 2.0ghz when I was thinking of trying myself.

Also I don’t think you have to compile as you just need a device tree compiler/convertor
dtc -O dtb -o p4080ds.dtb p4080ds.dts

dtc is a ubuntu package just takes the binary bungs out a text that you edit and convert that back to the binary.

Saying that the Debian image build service on Ubuntu in the Radxa github is just basically set target=base/desktop and arch=armhf/arm64 and just follow the instructions as its very easy.

ahillelt · July 5, 2019, 9:13pm

Ha, didn’t realize that the debian build was no more than that! Figured Radxa did some extra things. Should’ve looked closer on Github, thanks!

github.com

radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

/*
 * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
 *
 * This file is dual-licensed: you can use it either under the terms
 * of the GPL or the X11 license, at your option. Note that this dual
 * licensing only applies to this file, and not this project as a
 * whole.
 *
 *  a) This library is free software; you can redistribute it and/or
 *     modify it under the terms of the GNU General Public License as
 *     published by the Free Software Foundation; either version 2 of the
 *     License, or (at your option) any later version.
 *
 *     This library is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *     GNU General Public License for more details.
 *
 * Or, alternatively,
 *

This file has been truncated. show original

stuartiannaylor · July 5, 2019, 10:03pm

https://wiki.radxa.com/Rockpi4/dev/Debian

Is a great guide just misses target=base if you want a server base rather than desktop.
Also ARCH=$ARCH ./mk-rootfs-stretch.sh && ./mk-image.sh ARCH=$ARCH ./mk-rootfs-stretch-arm64.sh && ./mk-image.sh for the 64bit.

But on 16.04 or bionic after the above simple guide it provides an extremely simple build service as

Just pulls in all the required radxa patched git repo’s for a complete image and has the root scripts to put it all together.

https://wiki.radxa.com/Rockpi4/dev

ahillelt · July 5, 2019, 10:07pm

Good to know, was going for Server based. Also has the OpenCL instructions, have to dig into those too to see if Mali can be overclocked too. Still wish Radxa came out with some kind of tool so that there is less risk of screwing something up. Appreciate your help so far!

stuartiannaylor · July 5, 2019, 10:14pm

Most are waiting for Panfrost and Mesa in 5.2 as then it all becomes opensource mainline with less chance of incompatibility.
Can not say at the moment as 5.2-rc7 & Mesa 19.1.1 are not working that well but it might be its a bit bleeding edge and are out of sync as the 5.2 release should be in conjunction with 19.1.2 as the debug messages clearly say ToDo

https://wiki.radxa.com/Rockpi4/dev/kernel-mainline

ahillelt · July 5, 2019, 10:27pm

Thankfully the T860 is built on Midgard GPUs!

stuartiannaylor · July 5, 2019, 11:36pm

Apart from the crashes if you are testing the current master of 5.2, Mesa & DRM it feels fast.
Its a pain its all so bleeding edge but going mainline is massive as basically things like opencl should just work.

ARM Mali-T860MP4 GPU, support OpenGL ES1.1/2.0/3.0, OpenCL1.2, DirectX11.1 etc
Embedded 4 shader cores with shared hierarchical tiler

Maybe have a look at https://github.com/pocl/pocl as also there is OpenCl for the cpu/neon support
http://portablecl.org/

PS when I was playing with the manjaro images and checking the boot console I did notice that it seemed it was booting via uboot @ 2.0Ghz and until the kernel governor kicked in it then down clocked to 1.8ghz.
After seeing that I think 2.0Ghz is prob very possible.

ahillelt · July 6, 2019, 12:02am

Funny, so many of these distros tweaked with the RK3399 clock-speeds, but no one really wants to talk about the testing they did to pick the stable point. I think I can overcome thermal throttling, will have to play around. From what I am reading, some of the efficiency cores give issues at 1.8Ghz, each core has it’s own tolerance, one post somewhere mentioned they had to keep it at 1.7Ghz across all the littles.

stuartiannaylor · July 6, 2019, 4:16am

I think most just copied the Rockchip ref board in fact much of what we have is modifications to the original Rockchip ref board.

I have been waiting for the delivery of a 12v fan controller that is on an extremely slow boat from China or its not coming, don’t know which yet.

The google chromebooks DTSI is prob the one to copy I can not find the damn thing but big/little it was running 2.0ghz/1.6ghz from memory and they had elevated the voltages with a slight OC at top clock speed.
There is another thing that I am trying to work out and that is governor to use as they may of sealed 1.7ghz constant because the scaling can produce latency sensitivity.
I was reading up on what I could and googling snippets of info with my usual confused expression on such matters.

If you are going to OC stick the governor on performance IE full clock speed constant and see how you go.
I am not even sure but rather than just change you might me able to add another speed step.
If you are giving it a go give us as shout and share your dts as likewise I will do the same.

It wasn’t google but the gru board doh!

2.0/1.5ghz not 2.0/1.6ghz

stuartiannaylor · July 6, 2019, 9:46pm

@ahillelt

If you start with the preview for Mangaro the latest master for mesa is now fixed on 5.2-rc7.

You might want to try opencl on that platform as its now looking good.

You need to install the linux-aarch64-rc & linux-aarch64-rc-headers
Also remove ‘xf86-video-fbturbo-git’ as that is what is being used current.
You will then see artifacts on a reboot so you need to build the very latest mesa

https://panfrost.freedesktop.org/building-panfrost-mesa.html

reboot after you have added the missing dependencies

this can help you setup those

basically sudo pacman -S bc python-pip flex bison base-devel ncurses

You might need to do the same with drm but try mesa first as so far its looking really good for 5.2 and 19.1.2 that gets released in 3 days

ahillelt · July 6, 2019, 10:11pm

My Rock Pi 4 got damaged, I ordered a new 4 A, should arrive hopefully soon. Damaged wasn’t related to tweaking, physical damage due to toolbox falling on it.