RK3568 not able to clock at up to 2 GHz

sbc-bench measurements reveal that so far no RK3568 SBC is able to clock up to the promised 2.0 GHz: https://forum.odroid.com/viewtopic.php?p=346334#p346334

It seems the SoC temp in combination with some firmware BLOB limits maximum ARM core clockspeeds. At the end of the aforementioned thread is a simple bash script that might help exploring this theory. The higher the temp diff tested the more insights of course.

As such… asking for volunteers…

1 Like

For me the Rock 3A had been a bittersweet experience so far. The support seems to be sporatic IMHO. Hardware wise, after placing orders via allnet China, I’m still waiting for my deliveries of accessories. In the current time frame that may be due to the current “lockdown” being experienced in China (speculation on my part) but it’s been longer than that since the order was placed, with no response from Radxa when querried. Software wise some OS’s advertised to work with the 3A are “half baked”. As I’ve previously stated IMHO this is not the fault of the many developers who work tirelessly, but in the fact that Radxa advertises that the OS’s will work. Not mentioning that one won’t “completely” work. All that said, hardware limitations come as no supprise. As for volunteers, I am retired with more time than talent :relaxed: but if you can instruct me I’m certainly willing.

@tkaiser do you think its the SoC or that maybe the reference PCB didn’t do a good thermal job and maybe there is room for improvement?
I dodged the RK356x offerings as for me it has seemed to be a complete curveball to board manufactures as it had some extremely unique features that sort of get lost in general purpose style offerings.

I guess the thing to do would be to see if stability can be retained whilst undervolting the opp table as guess its still very much at EVB settings but would be the 1st time a manufacturer has fallen short on expectations, but maybe the OPP table does tweak and current voltages are high?
Also on the Odroid for many its upside down and a horrific thermal solution in that orientation but at least Odroid went for a reasonable board format where a 2280 does board mount without horrible risers.
Not sure at all why radxa went again for that horrible Pi format when you have a 2280 m.2 but thermal wise its orientation is more ‘normal’ and does have a fan header and the usual copper shim can often help much.

The kernel submissions are still coming in thick and fast https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v5.18-rc2&qt=grep&q=rk356
So yeah its still very much a work in progress but the offerings by all manufactures have left me bemused as it could of had some extremely cost effective specific uses but from what I have seen tend to be overpriced general purpose solutions which I don’t think Rockchip ever intended.

@Google_User Did you get the heatsink and do you have a fan that you can put on the fan header or put a 12v fan on 5v or 5v fan on 3.3v and also try a copper shim.

@tkaiser does some great scripts https://github.com/ThomasKaiser/sbc-bench#execution for testing just git clone and test.

For me in a very crowded SBC space niche those Quad-core Cortex-A55 perf level bloated general purpose boards are just not cost effective and neither are the compute modules even though likely will find commercial uses but with the offerings avail I am giving them a wide berth.

For anyone wanting to contribute it’s as easy as:

  • run sbc-bench at least once (since it installs the prerequisits)
  • curl https://gist.githubusercontent.com/ThomasKaiser/493119ecce14eec6f5ee4d8d8ff50828/raw/68b99578b0e8b7cf854154dc71975c9a677bbc31/test-rk3568-thermals.sh >test-rk3568-thermals.sh
  • inspect what test-rk3568-thermals.sh is doing (if you lack the skills to do this stop here since ‘running stuff from somewhere on the Internet’ is a rather bad idea)
  • put your RK3568 device in a position where it will experience huge thermal differences (for example on the window sill just minutes prior to the sun coming around the corner since any electronics device being exposed to direct sunlight will get warm if not even hot)
  • let the script run by /bin/bash ./test-rk3568-thermals.sh and stop with [ctrl]-[c] once the output got interesting
  • post the results here, preferrably inside a code block

The whole idea is to quickly exmamine whether the temperature reported by the SoC correlates with CPU clockspeeds measured. As such the higher the temperature difference the better.

The temperature range to be tested is between 0°C and 60°C. The lower starting point the better, higher temperatures not interesting since somewhere above 60°C or maybe 70°C Linux itself will start to throttle and reduce the clockspeeds by itself. But here it’s not about the clockspeeds the kernel thinks the cores would run at but the real clockspeeds obviously controlled by a MCU inside the SoC (e.g. 1910 MHz in reality while the cpufreq driver still happily tells ‘1992 MHz’).

@tkaiser when I went in search of the extender/mount for a nvme ssd, I found most vendors were out of stock. I went to Radxa via allnet China, and they said they had them and I’d need the heat sink to properly mount it, so I ordered that as well. That is the order I’m still waiting for…I currently have aone of those small generic “stick-on” heat sinks on the SOC. I think I have some old fans around here somewhere (theres a 24v one on the desk. I have a power supply from an old IPX system providing =3.3v, +5v, +12v, & -12v. or I can rig a variable without too much difficulty.

Update:
(For the sake of follow through),
I finally received the order from Radxa (via allchina net) only to be disappointed yet again. the M.2 mount/extender worked well enough, however the heatsink which they told me I MUST have for proper assembly was not even for the Rock 3A. but for the Rock PI 4. Clearly a different board with the SOC mounted on the bottom of the board not the top like the Rock 3A. The only purpose the heat sink serves in this case is as a base for the assembly to sit on. It disippates no heat at all. And just so you all know, The shipping charges were more than the cost of the items shipped.

The amlogic a311d has a similar arrangement with a closed blob locking the clock speed has anyone ever noticed a discrepancy (I have a hazy memory it was the same) as think this has been going on for some time and maybe they are all at it now :slight_smile:

I dunno why they would or how they justify as presume its the MCU code passing clock speed to kernel and is it always about 4% (As that hazy memory with Amlogic makes me think the error margin is roughly in the same ballpark)?
I guess it doesn’t matter that much as many are benchmarking with processes and not just quoting clock speeds but its curious to why they do it and its not accurate… ?