While the Rockchip RK3588 processor is advertised as reaching 2.4 GHz, not all RK3588 chips may achieve this frequency. The keyword is PVTM (Process-Voltage-Temperature Monitor), and we’ll try to explain why it does, and why some of the RK3588 processors may only be clocked at about 2.3 GHz, while others will run fine at 2.4 GHz.
This all started with Rock 5B SBC debug party, where we noticed our boards did not reach the same frequency. Willy Tarreau noted the “pvtm” value was different between our boards:
- Willy’s board: (Cortex-A76 cluster 1 @ 2,304 MHz, cluster 2 @ 2,352 MHz)
1234567# dmesg|grep cpu.*pvtm[ 2.606324] cpu cpu0: pvtm=1482[ 2.606542] cpu cpu0: pvtm-volt-sel=3[ 2.614206] cpu cpu4: pvtm=1722[ 2.618389] cpu cpu4: pvtm-volt-sel=5[ 2.626814] cpu cpu6: pvtm=1744[ 2.630998] cpu cpu6: pvtm-volt-sel=6 - CNXSoft board (Cortex-A76 cluster 1 @ 2,304 MHz, cluster 2 @ 2,304 MHz) :
123456[ 3.620281] cpu cpu0: pvtm=1490[ 3.620376] cpu cpu0: pvtm-volt-sel=4[ 3.627377] cpu cpu4: pvtm=1736[ 3.631320] cpu cpu4: pvtm-volt-sel=5[ 3.639103] cpu cpu6: pvtm=1732[ 3.643069] cpu cpu6: pvtm-volt-sel=5 - Thomas Kaiser (tkaiser) board: (Cortex-A76 cluster 1 @ 2,400 MHz, cluster 2 @ 2,400 MHz)
123456[ 3.117399] cpu cpu0: pvtm=1528[ 3.117491] cpu cpu0: pvtm-volt-sel=5[ 3.124529] cpu cpu4: pvtm=1785[ 3.128495] cpu cpu4: pvtm-volt-sel=7[ 3.136234] cpu cpu6: pvtm=1782[ 3.140173] cpu cpu6: pvtm-volt-sel=7
For reference, CPU 0 to 3 are Cortex-A55 cores, CPU 4-5 are two Cortex-A76 cores (cluster 1), and CPU 6-7 are two Cortex-A76 cores (cluster2). The frequencies reported above are Operating Performance Point (OPP) reported by the kernel, but the actual measured frequency in SBC-Bench.sh script may differ:
- CNXSoft board:
123456789Checking cpufreq OPP for cpu4-cpu5 (Cortex-A76):Cpufreq OPP: 2304 Measured: 2304 (2304.996/2304.969/2304.943)Cpufreq OPP: 2208 Measured: 2214 (2215.206/2215.036/2214.696)...Checking cpufreq OPP for cpu6-cpu7 (Cortex-A76):Cpufreq OPP: 2304 Measured: 2298 (2298.327/2298.300/2298.196)Cpufreq OPP: 2208 Measured: 2208 (2208.369/2208.369/2208.248) - Thomas board
123456789Checking cpufreq OPP for cpu4-cpu5 (Cortex-A76):Cpufreq OPP: 2400 Measured: 2348 (2348.432/2348.405/2348.268) (-2.2%)Cpufreq OPP: 2208 Measured: 2185 (2185.642/2185.619/2185.571)Checking cpufreq OPP for cpu6-cpu7 (Cortex-A76):Cpufreq OPP: 2400 Measured: 2348 (2348.350/2348.268/2348.159) (-2.2%)Cpufreq OPP: 2208 Measured: 2185 (2185.548/2185.453/2185.311)
What’s really odd is that we have different OPP frequencies. Thomas’ Cortex-A76 cores are set up to 2,400 MHz, but are only measured to 2,348 MHz. It’s still better than the 2304 and 2,298 MHz measured on my system.
We’ll see if we can find more details about pvtm in the Rockchip RK3588 TRM (and SDK). It can indeed be found in Chapter 17 entitled “Process-Voltage-Temperature Monitor (PVTM)” of TRM Part 2.
As described in the technical reference manual:
The Process-Voltage-Temperature Monitor (PVTM) is used to monitor the chip performance variance caused by chip process, voltage, and temperature.
PVTM supports the following features:
- A clock oscillation ring is integrated and used to generate a clock like signal, the frequency of this clock is determined by the cell delay value of clock oscillation ring circuit.
- A calculation logic is used to measure the frequency of the clock oscillation ring.
- Follow PVTM blocks are supported:
- BIGCORE0_PVTM, used near A76_0/1
- BIGCORE1_PVTM, used near A76_2/3
- LITCORE_PVTM, used near DSU and A55_0/1/2/3
- NPU_PVTM, used near NPU
- GPU_PVTM, used near GPU
- PMU_PVTM, used near PMU
So that means not only the three CPU clusters (1x Cortex-A55 and 2x Cortex-A76) frequencies are impacted by the PVTM, but also the GPU and NPU frequencies, while for the PMU it appears to be used for low power modes as an alternative to a 32KHz clock source. The documentation further explains there are two methods of calculation (manual and auto):
A clock is generated by the oscillation ring and a frequency fixed clock clk_pvtm is used to calculate the cycles of the clock. Supposing the time period is 1s, then the clock period of oscillation ring clock is T= 1/clock_counter(s), the cell delay value is T/2.
For manual mode, user can only get one frequency result for a calculation.
For auto mode, user can set the calculation times, and get the maximum, minimum and average frequency during calculation. It also supports to generate an interrupt when the minimum or average frequency below a threshold. The threshold can be configured.
Every chip will be slightly different during manufacturing, and some may be able to reach 2.4 GHz while others not. The room temperature may also impact the performance. I’m based in the North of Thailand, and my room temperature is usually around 28°C, so it’s not impossible that my board can reach 2.4 GHz in winter (about 20°C in the morning), but is limited to about 2.3 GHz for the rest of the year…
The PVTM is probably used in conjunction with the PVTPLL (Chapter 18) which is “used to monitor the chip performance variance caused by chip process, voltage, and temperature, and generate a set of reference signals for adjusting the voltage of the chip.
I also wanted to check RK3588 Linux SDK on Gitlab as well, but I’ve just requested access from Rockchip, so we have to wait. Having said that the PVTM is not a new thing and I could find a patch submitted to mainline Linux in 2018 for the RK3288 processor, but I’ve just only noticed now. The Rockchip’s Linux CPUFreq driver documentation also mentions PVTM and how it assigns OPP values:
Rockchip’s CPUFreq driver attempts to read leakage value from eFuse and get frequency count from pvtm, then supplies the OPP framework with ‘prop’ information which is used to determine opp-microvolt-<name>property of OPPS when it is parsed by the OPP framework. This is based on operating-points-v2, but the driver can also create the “cpufreq-dt” platform_device to compatibility with operating-points.
Companies will sometimes create new part numbers for chips with the same functionality but different frequencies and Rockchip did that for RK3399K @ 2.0 GHz, RK3399 @ 1.8 GHz, and RK3399-T @ 1.5 GHz, but the small differences we’re seeing between Rockchip RK3588 processors probably did not warrant naming a new part, or it may come up later on.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Jean-Luc, not sure if you’re also reading the thread about the “debug party”, but I also shared my findings and analysis there: https://forum.radxa.com/t/rock-5b-debug-party-invitation/10483/141
In short, PVTM is an interesting way to estimate the silicon quality. It’s only a measure and not a limitation. The OPPs are conditioned on these values. It’s just that we’re missing extra OPPs in the DTS to compensate for the lower grade in our CPUs, but we could create new OPPs like we used to before. At least I think Radxa ought to do it to make sure that their customers do not face different frequencies, which tends to leave a negative feeling of a product. Instead it would be better if some heat more. When I have a bit more time to get back to these tests, I’ll try to add 25mV to the CPU, it seems based on the other values that this increase should be sufficient as it’s what differs between PVTM steps.
I don’t think you’d see different values in winter and summer. @tkaiser measured the difference between a hot and a cold boot and it was the same. After all that’s the principle of this mechanism, to assess the silicon after eliminating the variations caused by voltage and temperature, so that makes sense.
It’s a weird system. The PVTM is part of the silicon and therefore not in the ideal position to measure performance/quality, I don’t understand why they do not use binning.
Won’t be the first Chinese SoC with sensor defects either.
No, it’s the opposite. It’s part of the affected area and serves as a canary. From what I’ve read on the subject, some chips implement many PVTM clocks to try to cover the maximum possible area.
BTW: to get an idea about further PVTM variations in the wild I did some Geekbench data mining: https://github.com/ThomasKaiser/sbc-bench/blob/master/results/geekbench-rk3588/results.md
The ‘8 Cores @ 0.00 Hz’ entries can be skipped (no cpufreq support) and I would also skip everything prior to 2022 due to maybe other/static cpufreq OPP. Of course Geekbench’s way to ‘report’ clockspeeds is flawed but that’s all we have.
Do you still have your Mekotronics RK3588 and what speed does that give? Mekotronics have had their RK3588 available and in use for months so is it better, more mature development wise.
I’ve not checked the PVTM value, but the maximum frequency was 2210 MHz in Android 12.
Have you run Linux on Mekotronics ?
I know the Mekotronics has a more stable Android with Google Play mostly working. Mind you these are designed as signage players, if I recall correctly.
I haven’t scheduled time to run Linux on R58.
I would not expect different RK3588 hardware to have much differences in terms of software support, everything is still work in progress.
I suspect that losing 0.1Ghz is unlikely to concern many.
In order to make comparison with a more mature release of the SOC, running the same tests on the Mekotronics would be logical.
It also has to be noted that this is a pre production board, handed out to a few in order to identify bugs and issues to be fixed.
It’s not a matter of “losing 0.1 GHz” but figuring why the advertised frequency may not necessarily be reached. It can translate to FPS in games or anything else, that is not trivial to explain by the casual user who may have a hard time guessing wrong that this or that distro doesn’t run at the same frequency, or that this or that perf test program could give different results between boots, especially if it may reach close to 10%. Admittedly once understood there’s nothing dramatic, but it just deserves an explanation.
And this is perfectly within the type of stuff that initially appeared as bugs that possibly needed to be fixed. Now that it’s explained we can move on to other things. I think this one should be advertised as “2.2+ GHz” since 2.2 seems to be the base value and the rest depends on the batch. I guess that over the long term it will become more common to see different grades of CPUs and maybe some will be sold at different prices and official frequencies as is already being done in the x86 world.
If using FPS in games was to be used as comparison, 0.1Ghz as a percentage of the maximum 2.4Ghz is pretty much 5%.
So in a game expected to run at 60FPS for optimal performance, using 5% as a broad expectation of potential loss, this would mean a game running at 59.5FPS, which nobody would ever notice, hence it not being a factor to be of any concern.
Of course, with this being a pre production board, any anomalies are worth reporting such that final production can be as advertised.
If it is seemed that 2.3 is the maximum then this can be the revised advertised figure if absolute accuracy is desired.
But the tech industry is not exactly known for its conformity to accuracy as in hard drives being measured upin 1000 instead of 1024.
Exciting times nonetheless for this SOC, which takes devices in its particular sector to a new level after a long wait.
I have no doubt that there will be those that were invited to the debug party who will show results of gaming and other general uses.
Gaming and emulation videos for the RK3588 have been on YouTube for months hence how it is known that RK3588 CPU, GPU is faster than a Nvidia shield Pro.
> So in a game expected to run at 60FPS for optimal performance, using 5% as a broad expectation of potential loss, this would mean a game running at 59.5FPS, which nobody would ever notice
Your calculations look odd, 5% would give 57, and even if nobody would notice, they would notice the reported value that differs from their friends and would start looking in the wrong direction.
In addition, 2208 is even 8% and it’s the highest frequency not affected by PVTM. That gives 55 FPS from 60 at 2400. Again, a reason for some people to question where it comes from.
You know that people overclock to gain less than 10%, do you ?
> I suspect that losing 0.1Ghz is unlikely to concern many.
That’s not the point as already explained. It’s about understanding and documenting PVTM behaviour so all the crap reviews that will follow on YT get the idea.
Also it’s not ‘0.1Ghz’ but we’ve seen already just an 2256 MHz OPP (see Creepbench result for soon to be revealed Firefly Station N1) and as this blog post explained PVTM is not limited to CPU cores but also affects GPU and NPU clockspeeds and even the PMU domain and as such results with ‘gaming’ can differ even more.
> a more mature release of the SOC, running the same tests on the Mekotronics
Huh? Do you suffer from the same problem as TheLiarUK who can’t differentiate between boards and SoCs and hardware and software?
The ‘mother’ of all the current RK3588 thingies out there is called ‘Rockchip RK3588 EVB1 LP4 V10 Board’ since they’re all just variants of RK’s reference design. And said ‘EVB1 Board’ has been measured by sbc-bench already with just ~2320 MHz on the 3rd CPU cluster. PVTM is a design feature of recent Rockchip SoCs and not a matter of ‘maturity’.
(off topic a bit) Didn’t know you live in Thailand, me too (Thai) greeting from southern. Here in Trang always get chips hot easily (I have F1C100s running Buildroot Linux). Idle temp is 40 ish degree C. But since the CPU runs at 400 something MHz, It’ practically no different at all. I don’t have RK3588 board on hand so not quite sure how the PVTM would look like here in Trang. But I’m sure that it not gonna reach 2.4GHz
Since each chip is slightly different, some may be able to run at 2.4 GHz even in hotter climates. It’s also unclear whether the room temperature really impacts the PVTM results (see Willy’s comment above).
Very few games or emulators are cpu constrained but it would be interesting to know if we will be able to force at least one of the big core clusters beyond this limitation or not, since many emulators games that are cpu intensive require good single core performance for most parts.
Also, while 5% may not be significant on cpu clocks for games, gpu clocks may be, and that would be difficult to measure. In fact, while we have a great tool for testing real cpu frequencies with tkaiser sbc bench (and willy) , we dont for gpu frequencies and that’s a pain in the ass, benchmarking wise. Gpu performance may differ for various reasons, like ram bandwidth, so we can’t just run glmark2 and compare to know if they run at different frequencies. In fact, my T4 ddr3 usually perform 17% higher on glmark2 just bc of running at 1866 MT/S instead of 1600 MT/S like on lpddr4 based rk3399s.
> we dont for gpu frequencies and that’s a pain in the ass, benchmarking wise
Nope, since nobody cares. Those involved in ‘gaming’ and this other crap love to be served by numbers without meaning. It’s just like the average Android smartphone consumer: the more cores the better.
Once someone interested in this area starts to do some serious ACTIVE benchmarking that might change.
Haha dude, many do care about gaming on arm linux. And those hate android gaming for most parts. Especially with software like box64/box86/box32.
Anyway, to get any box to work with on this new platform, we need panfrost, so mainline… an year ahead to say at least.
Anyone ever seen statistics for pvtm values for several years?
(or dmesg logs for same SoC&pcb within years on ‘consumer level’ usage?)
thx
> Anyone ever seen statistics for pvtm values for several years?
Most probably Rockchip engineers. But outside RK? While PVTM is in use at least since RK3399 who took notice so far?
And how should dmesg output help if people are told to prefer mainline kernel where all the relevant BSP info is missing?
thx, for the overview of pvtm values (sorted for 456f:rk3399/’diverse boards’/cpu_values and 456g:rk3399/’diverse boards’/mostly gpu values)
for analyzing pvtm values alternation with surroundings/board temperatures, hw loading (cpu clusters,gpu,(npu),pmu,(memory controller?)), input voltage(s) one would need at least one single board for being on standardized/defined surroundings (at sustained, constant hw load) and fully documented, considering hw configuration (dts, bits from boot blobs, (image) maybe even a combined bootscript/bootloader/BSPkernel, so hw counter/rtc started before kernel was initialized?)
the only other SBC supplier interested in such insights and providing results to consumers/customers would be Hardkernel. Maybe Rockchip engineers provide some numbers from years experience (wrt to changes on SoC’s silicon)?
first description seen (from online available sources)
RK3288 ‘Technical Reference Manual’, page ~726
(theoretical knowledge since ~1 decade, RK3288 started ~2014)
(not only rk3399 SoCs, but also a rk3328, some rk3568, rk3588 pvtm values)
dmesg clock times are low 1digit to low 10’s seconds numbers for logged pvtm values, makes assume that pvtm adjusts pvtm managed parts only on startup (no later pvtm values in dmesg, even with benchmarking loads)?
( just another try: cpu pvtm values http://ix.io/45mG, gpu/npu pvtm values http://ix.io/45mO )
PVTM is documented in TRM of many Rockchip SoC, from 2014- 2015 I have seen PVTM mentioned. So why the suddenly problems?