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?
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
It should be possible.
mrfixit2001 has made following notice in announcement for the beta REcalbox release:
" Slight default overclock"
Can be found here:
Do you know where you can edit the clock speed from the kernel source code?
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.
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.
The A53 might go higher but guess its very much dependent on cooling, but they seem to have more headroom
Wondering if anyone figured out how to play with overclock settings on Radxa Ubuntu Server release?
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.
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.
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.
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!
Is a great guide just misses target=base if you want a server base rather than desktop.
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.
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!
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
Thankfully the T860 is built on Midgard GPUs!
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
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.
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.
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
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
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
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
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.