Hi everybody. I decided to try overclocking my VF2, using my idea from here
EDIT: a few hours later and following comment from @hexdump0815 , it is obvious that all I am doing here is setting the desired CPU scaling, as distinct from the actual CPU clock frequency…
I’m a bit better educated now 
and working on the cpufreq side of things; which involves changes to the actual kernel and not just the device tree.
[drivers/clk/starfive/clk-starfive-jh7110-pll.h is where the cpufreq magic is defined]
original post:
I made the bare minimal changes; simply adding a new 1.8GHz entry to the clock definitions in jh7110.dtsi, then recompiling my kernel; installing the resultant kernel+libc packages, and importing the new /boot/dtbs/starfive in place of the old one.
Once I rebooted, everything is working correctly, Networking, Storage, GPU are all as expected, /sys shows the new CPU frequency available and being used… I’ve had a play in gnome/wayland and everything works, OctoPrint and mjpeg-streamer both started and run, SCUMMvm plays fine. I’m confident nothing important on my system has broken.
Whether it has got faster is subjective: A bit, but not much.
- From my perspective as a desktop / commandline user the system feel pretty much as before. It didnt make me go ‘wow’ in the way that swapping rootfs from a SD card to a NVMe did.
- I dont have any benchmarks, nor much interest in them, so no numbers… sorry.
- The machine is running a bit hotter, but not by much.
- I have a good 20x20x10 passive heatsink thermally bonded to my CPU but no fan.
- I’ll see how this goes over time; my SBCeye system logs the temp and can graph it for me later.
user@rose:~/kernel/linux$ uname -a
Linux rose.easytarget.org 5.15.0-rose18-dirty #4 SMP Mon Jun 5 15:55:33 CEST 2023 riscv64 GNU/Linux
user@rose:~/kernel/linux$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
375000 500000 750000 1500000 1800000
user@rose:~/kernel/linux$ git status
HEAD detached at VF2_v2.11.5
Changes not staged for commit:
modified: arch/riscv/boot/dts/starfive/jh7110.dtsi
user@rose:~/kernel/linux$ git diff
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index b6a6386b9551..692ada746a2c 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -39,6 +39,10 @@ opp-1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1040000>;
};
+ opp-1800000000 {
+ opp-hz = /bits/ 64 <1800000000>;
+ opp-microvolt = <1040000>;
+ };
};
cpus {
user@rose:~$ uptime
18:43:06 up 2:42, 2 users, load average: 0.02, 0.03, 0.08
user@rose:~$ cat /sys/class/thermal/thermal_zone0/temp
50528
Caveats:
- I did this on the previous (VF2_v2.11.5) release; I have yet to upgrade to the latest one.
- YMMV
7 Likes
i think i tried that some time ago as well, but in the end there was no real speedup - i think the total score of “7z b” is a very good and easy benchmark to verify if it is really faster or not
2 Likes
Thankyou for the reminder about '7zz b', and you are right. Swapping between the two device trees showed, clearly, that there was no discernible speed increase.
2 Likes
I think the last time I overclocked CPUs was around 1996-1998. In the computer shop where I worked at the time, we were offered a special deal on Pentium Pro CPUs by a wholesaler. I bought two of them and a matching dual Pentium Pro motherboard from Tyan, which was more expensive than the CPUs and RAM together.
At that time, CPUs were sometimes still sold in low clock speeds at low prices until the model was discontinued, although the process was already so well perfected that almost all CPUs also ran at significantly higher clock speeds.
The Pentium Pro was actually not a pure CISC CPU but a CISC/RISC hybrid.
Microprocessor Report
As far as I can remember, I was able to overclock my two 150 MHz Pentium Pro to 200 MHz, but to do so I had to overclock the bus from 60 MHz to 66 MHz, which was too unsafe for me. So I let them run at 180 MHz for a long time (two years?), which worked without problems. I had to compile the kernel for my S.u.S.E. Linux myself in order to enjoy SMP. As an alternative, I also experimented with Windows NT 3.5.
What was really great about my Dual PPro motherboard was the gigantic RAM memory. 
“This full size (13"x12”) AT board includes eight 72-pin SIMM sockets with support for a maximum of 1GB EDO or FPM DRAM. "
8 Likes
You also might try to dig there as this topic already raised here with “more working” commits before: Older 1.75ghz opp points
1 Like
@strlcat , thank you, useful link 
I’m busy elsewheere but hope to spend an hr with examples and datasheets to understand the timers; and then work out which new frequencies are appropriate for the cpufreq definitions table. I’d like to doublecheck the PMU side of things too.
But it will need to wait until I have more important stuff done…
@SunWukong
In my case it was turning a Pentium120 into a Pentium150… those were the days.
Can you share results of running 7z b on your current setup?
1 Like
Sure:
user@rose:~$ 7zz b
7-Zip (z) 22.01 (riscv64) : Copyright (c) 1999-2022 Igor Pavlov : 2022-07-15
64-bit locale=C.UTF-8 Threads:4
Compiler: 12.2.0 GCC 12.2.0
Linux : 5.15.0-rose : #3 SMP Thu Apr 6 17:15:27 CEST 2023 : riscv64
PageSize:4KB hwcap:112D
LE
1T CPU Freq (MHz): 1485 1486 1485 1486 1486 1486 1486
2T CPU Freq (MHz): 197% 1469 198% 1466
RAM size: 7925 MB, # CPU hardware threads: 4
RAM usage: 889 MB, # Benchmark threads: 4
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 2934 305 935 2855 | 69206 391 1508 5904
23: 2246 242 946 2289 | 67890 392 1497 5874
24: 2300 259 953 2473 | 66119 392 1482 5802
25: 2378 282 962 2716 | 64202 391 1461 5714
---------------------------------- | ------------------------------
Avr: 2464 272 949 2583 | 66854 392 1487 5824
Tot: 332 1218 4203
…this is despite the system thinking it can go to 1.8Ghz, the measured CPU frequency gives it away, 1.5Ghz is the limit. Not surprising since the starfive cpufreq implementation tops out at 1.5…
2 Likes
Yep. Although I also wanted to experiment abit, rebuilding kernel scared me lol.
Please, report in detail if you’ll succeed on overclocking.
1 Like
I’m compiling as I type this… (takes 39 mins usually)
diff --git a/drivers/clk/starfive/clk-starfive-jh7110-pll.h b/drivers/clk/starfive/clk-starfive-jh7110-pll.h
index 87843181ecf8..35ff2062e9c1 100644
--- a/drivers/clk/starfive/clk-starfive-jh7110-pll.h
+++ b/drivers/clk/starfive/clk-starfive-jh7110-pll.h
@@ -125,7 +125,9 @@ enum starfive_pll0_freq_value {
PLL0_FREQ_1000_VALUE = 1000000000,
PLL0_FREQ_1250_VALUE = 1250000000,
PLL0_FREQ_1375_VALUE = 1375000000,
- PLL0_FREQ_1500_VALUE = 1500000000
+ PLL0_FREQ_1500_VALUE = 1500000000,
+ PLL0_FREQ_1625_VALUE = 1625000000,
+ PLL0_FREQ_1750_VALUE = 1750000000
};
enum starfive_pll0_freq {
@@ -138,7 +140,9 @@ enum starfive_pll0_freq {
PLL0_FREQ_1250,
PLL0_FREQ_1375,
PLL0_FREQ_1500,
- PLL0_FREQ_MAX = PLL0_FREQ_1500
+ PLL0_FREQ_1625,
+ PLL0_FREQ_1750,
+ PLL0_FREQ_MAX = PLL0_FREQ_1750
};
enum starfive_pll1_freq_value {
@@ -233,6 +237,22 @@ static const struct starfive_pll_syscon_value
.dacpd = 1,
.dsmpd = 1,
},
+ [PLL0_FREQ_1625] = {
+ .freq = PLL0_FREQ_1625_VALUE,
+ .prediv = 24,
+ .fbdiv = 1625,
+ .postdiv1 = 1,
+ .dacpd = 1,
+ .dsmpd = 1,
+ },
+ [PLL0_FREQ_1750] = {
+ .freq = PLL0_FREQ_1750_VALUE,
+ .prediv = 12,
+ .fbdiv = 875,
+ .postdiv1 = 1,
+ .dacpd = 1,
+ .dsmpd = 1,
+ },
};
static const struct starfive_pll_syscon_value
I’ll let you know , it’s remote (in my apartment, I’m elsewhere) so this may grind to a halt when my laptop runs out of juice. Problem is I’m compiling Armbian for the mangopi-mq-pro on this laptop right now and the battery is nose-diving. 
3 Likes
Mine a little better but at par with yours. So let’s see the change after overclocking.
1 Like
Bum. 
With the new kernel 7z still tests the cores at 1500(ish):
Compiler: 12.2.0 GCC 12.2.0
Linux : 5.15.0-rose1750-dirty : #1 SMP Tue Jun 6 16:31:17 CEST 2023 : riscv64
PageSize:4KB hwcap:112D
LE
1T CPU Freq (MHz): 1483 1486 1484 1486 1481 1486 1484
2T CPU Freq (MHz): 197% 1473 200% 1485
I’ll look at what is wrong later, my brain just coredumped due to low energy.
I did rebuild of my kernel with patches to pll header file and dtsi files as listed in commits ref’d by you and me and can for now confirm it does not work for some reason. The change is purely cosmetic - no change in power draw on usb meter nor on numerous numbercrunch tasks and core temperature for now, although it says 1.75GHz is available and even tries to apply it. Strange.
3 Likes
I further played with SYSCFG registers directly from U-Boot on a V1.3B board and cannot get it past 1584MHz, after that system hangs, freezes, faults or spits garbage:
VF2# echo $bogomips
timer start; hash sha256 100000000 02000000; timer get
VF2# md 1303001c 1
1303001c: 0000007d }...
VF2# md 13030024 1
13030024: 042ba603 ..+.
# (here, CPU freq is calculated as 24MHz * (*(0x1303001c[0:11]) / *(0x13030024[0:5]))
# spl boot defaults shown above: 24000000 * (0x7d / 0x3) = 984000000 (around 1000MHz)
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
1.326
VF2# mw 1303001c c0 # 1536MHz, current increases...
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.867
VF2# mw 1303001c c4
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.849
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.849
VF2# mw 1303001c c5
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.845
VF2# mw 1303001c c6 # 1584MHz, current is around 0.56A but bootup@984MHz is 0.49A, increasing value further increases it...
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.841
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
0.841
VF2# mw 1303001c c7
VF2# run bogomips
sha256 for 100000000 ... 101ffffff ==> 9644d54421ff378e06f5197ec0ab037d101feeb25f5b0dea0cd2e78a75012cef
Unhandled exception: Load access fault
EPC: 00000000cce0c492 RA: 00000000ccdc7aac TVAL: ffffffffffffffff
EPC: 0000000040264492 RA: 000000004021faac reloc adjusted
SP: 00000000cc5977b0 GP: 00000000cc597de0 TP: 0000000000000001
T0: 00000000cc5978b0 T1: ffffffffd3a0a26d T2: 0000000066821485
S0: 00000000cce5e8f0 S1: 0000000000000005 A0: 00000000cc5c2e90
A1: ffffffffffffffff A2: 0000000000000005 A3: 00000000cc5c2e90
A4: 0000000000000000 A5: ffffffffffffffff A6: 0000000000000074
A7: 0000000000000010 S2: 00000000cce60870 S3: 00000000cc5c2e90
S4: 00000000cce5e730 S5: 0000000000000000 S6: 0000000000000000
S7: 0000000000000000 S8: 0000000000000000 S9: 0000000000000000
S10: 00000000cc5c2f10 S11: 0000000000000000 T3: ffffffffa0002020
T4: fffffffffda1d311 T5: 0000000000001311 T6: 00000000cc597890
Code: 4501 a01d 87b3 00e6 c803 0007 87b3 00e5 (c783 0007)
### ERROR ### Please RESET the board ###
pll0 is 24MHz * (*(0x1303001c[0:11]) / *(0x13030024[0:5]))
Let me know if I’m doing something wrong. Might be influence onto peripherals too?
The program below was used to calculate the values:
#include <stdio.h>
#include <stdlib.h>
unsigned uatoi(const char *s)
{
return (unsigned)strtoul(s, NULL, 0);
}
int main(int argc, char **argv)
{
unsigned prediv, sysclkdiv, fbdiv;
unsigned result;
if (argc < 4) return 1;
fbdiv = uatoi(argv[1]);
fbdiv &= 0xfff;
if (fbdiv == 0) fbdiv = 1;
prediv = uatoi(argv[2]);
prediv &= 31;
if (prediv == 0) prediv = 1;
sysclkdiv = uatoi(argv[3]);
sysclkdiv &= 7;
if (sysclkdiv == 0) sysclkdiv = 1;
result = (24 * (fbdiv / prediv)) / sysclkdiv;
printf("The clock will be %uMHz\n", result);
printf("mw 13020004 %x\n", sysclkdiv);
printf("mw 1303001c %x\n", fbdiv);
return 0;
}
Trying to get there from different angles always cuts me off at 1584MHz…
3 Likes
@strlcat , I did manage to get CPUfreq to ask for 1625Mhz, having re-added the definitions removed by SF.
Unfortunately as the CPUfreq driver loads during the kernel boot the system hard locks, and halts. Sometimes I see SBI errors at that point, sometimes not.
My uninformed analysis is that openSBI goes foobar when the call is made to it for a cpu frequency setting that is out of bounds, or something equally horrible.
So far I have confined myself to changes in the kernel, To take this further I’d need to set up and build for openSBI, and I really dont have time for that at the moment.
I’m also busy with trying to build Armbian using purely upstream (SBI,U-Boot,kernel6.4rcX) sources for my mangopi-mq-pro…
Maybe once that is sorted and there is a matching wayland image for the latest VF2 release I’ll return to it.
4 Likes
Same on my end with my second V1.3B guinea pig board. But I decided to start from roots: earlier in U-Boot SPL. I generated four SPL binaries by modifying beginning of it’s board_init_f function where call to starfive_jh7110_pll_set_rate with desired frequency is done. Then I have partitioned a spare sdcard into my U-Boot+OpenSBI testbench setup where JH7110’s BootROM does read from sdcard of both SPL and main firmware instead of QSPI. (By the way, thank you devs for implementing this! Swapping bootable sdcards feels like old way swapping boot diskettes. And adds a charm while hacking)
For some reason, neighter 1250MHz nor 1375MHz did work, board did not even proceed with SPLs patched for that freq. Nor as 1650MHz or 1750MHz too (obviously?). Only SPL default 1000MHz and patched 1500MHz worked and resulted in booting main U-Boot. Then I tried to patch the SPL so that even an invalid number got passed to starfive_jh7110_pll_set_rate. Nah, it ignored it and sat freq to odd 966MHz as clk dump command told me.
From this point I proceeded to modifying SYSCFG registers (more about them in TRM: SYS SYSCON) and ended up never reaching 1584MHz because after that stability of system is ruined.
It might be useful to implement this as U-Boot patch to add a custom command to try fiddling with this, but now I start to believe it will be waste of time because the system is already not stable to handle more than said frequency… Unless I made a mistake somewhere and affected some other clocks aswell.
During the mess with SYSCFG and related I also discovered a deep underclock is available here as well down to 100MHz or so and even more (did not test it). But it does not magically turn this thing into a powersaving bee. An absolute minimum of 0.4A input current was reached, which is not that much (bare board, without anything attached to it except of sdcard which draws about 20mA avg, with SPL boot default does 0.5A or 2.5W power draw)
5 Likes
and working on the 
