Overclocking?

[NativeCode]

Is it possible to overclock at 1.5 ghz?

[Etx]

Yeah, really interesting whether it is possible to make it as a steps like on GKD350H, where the highest is 1.9 GHz.
There is enough free space inside the housing near the processor to easily mount some copper heatsink there to handle the excessive heat because of overclocking.

[NativeCode]

We tried 1.4Ghz and 1.5Ghz with some higher core voltage options. But the system was quite unstable and even didn't boot from time to time.
So we think the SoC silicon yield rate seems to be very low.

[Etx]

Oh, thanks for sharing this info. Good to know you've tried to squeeze all the juices available in this hardware.

[TuberViejuner]

I think it's not a good idea, may be with a cooler...

[ducadan]

i'm curios, can you also downclock the device? I'm thinking if i don't have access to a charging device and i want to prolong the battery.

[mad_ady]

You can reduce max cpu frequency and change governor, that should help.
Also reducing backlight will add time.

[ducadan]

i'm really noob at linux stuff(as in near 0 experience), but with google found https://wiki.archlinux.org/index.php/CP ... cy_scaling. Now, changing some "config" files , i think i can figure out, buuuuuuuut is there a little program for the OG Advance(for when it arrives) with GUI that i can use? ..... Hmmm i think even some batch files that changes the base/boost frequencies that i can run would be sufficient. Sorry for the troubles and thx for supporting this amazing handheld.

[rooted]

You can reduce max cpu frequency and change governor, that should help.
Also reducing backlight will add time.

Taking 3 of the 4 cores offline may help a bit more than clock speed.

[mad_ady]

Shameless plug: https://github.com/mad-ady/odroid-cpu-control

[npaladin2000]

Just to let you know, RetroRoller has an optional kernel with a wider CPU clock range, up to 1.5 GHz, and so far our users testing it are not seeing any stability issues. We have no intention of making it the default kernel though, people will have to switch to it manually if they want to try it, and if they see issues they can switch back. But maybe it's a little more stable governing up to 1.5 GHz rather than being pinned at 1.5 GHz?

https://github.com/valadaa48/retroroller/wiki/Kernel

[joy]

Just to let you know, RetroRoller has an optional kernel with a wider CPU clock range, up to 1.5 GHz, and so far our users testing it are not seeing any stability issues. We have no intention of making it the default kernel though, people will have to switch to it manually if they want to try it, and if they see issues they can switch back. But maybe it's a little more stable governing up to 1.5 GHz rather than being pinned at 1.5 GHz?

https://github.com/valadaa48/retroroller/wiki/Kernel

Hi @npaladin2000,
Thank you for sharing the information and your valuable opinion.
We will look into RetroRoller kernel and check system benchmark and stability issues.

We've put stability tests to squeeze out system performance up to 1.5GHz before OGA was released,
but at that time, most of samples got failed system stress tests with higher cpu frequency than 1.32GHz,
so we removed the higher cpu clock options by default to operate OGA stably. (no default debug port)

But I think your suggestion is very worth a try
even if there is no more room for higher cpu clock and we can't guarantee system stability.
I will try to make an option that OGA users can switch max cpu frequency (like via kernel command with boot.ini)
while checking the further room for system performance on RetroRoller kernel.

[meveric]

well it's relatively easy to activate the missing options in the DTS file for the ODROID Go Advance by removing the /delete-node/ opp-XXXXXX00000; entries on the dts file.
That way you get up to 1.5 GHz as an option rather quickly and easy.
Only problem is, it doesn't do anything besides faking the output.
It will report it's running on 1512 MHz but it's still running at 1296 MHz.
If you test performance, there really isn't any difference between 1296 MHz and 1416 MHz, or 1512MHz.
So if that's the only thing RetroRoller did to activate 1.5 GHz on the image, it won't do anything at all.
Especially with their claim that they activate from 400 MHz to 1.5 GHz this seems to be what they did, as the first line that was removed from the options is:
/delete-node/ opp-408000000; (408 MHz)
and the last line is:
/delete-node/ opp-1512000000; (1512 MHz)
But once again, just activating the options in the dts file doesn't necessarily mean it's running on real 1512 MHz

[npaladin2000]

No, you also have to swap in a new kernel with different CPU governor options.

[joy]

It will report it's running on 1512 MHz but it's still running at 1296 MHz.
If you test performance, there really isn't any difference between 1296 MHz and 1416 MHz, or 1512MHz.
So if that's the only thing RetroRoller did to activate 1.5 GHz on the image, it won't do anything at all.

Hi @meveric,

There are some more related points to change max cpu frequency.
(1) bin scaling limit
https://github.com/hardkernel/linux/blo ... 1.dts#L339

(2) rockchip opp select
https://github.com/hardkernel/linux/blo ... p_select.c

(3) px30 pll rates
The bin scale value depends on this pll_rate_table order.
https://github.com/hardkernel/linux/blo ... px30.c#L34

Only by modifying cpu0_opp_table, max cpu performance will be limited in 1.296GHz as you pointed.

This week, I had no room to look into RetroRoller kernel.
I will check it next week and also check its real performance using system benchmark utilities.

[joy]

Just to let you know, RetroRoller has an optional kernel with a wider CPU clock range, up to 1.5 GHz, and so far our users testing it are not seeing any stability issues. We have no intention of making it the default kernel though, people will have to switch to it manually if they want to try it, and if they see issues they can switch back. But maybe it's a little more stable governing up to 1.5 GHz rather than being pinned at 1.5 GHz?

https://github.com/valadaa48/retroroller/wiki/Kernel

Hi @npaladin2000,
I've looked into the RetroRoller kernel and did put some benchmark test to confirm its real performance.
There are the higher cpu frequency sets, 1.416GHz and 1.512GHz
but, as I checked, the actual performance is limited at 1.296GHz in case of 1.416 & 1.512GHz.

I used the following kernel repo
https://github.com/valadaa48/linux/commits/RR
, and looked through patches here, too.
https://github.com/valadaa48/retrorolle ... -odroidgo2

I found only patches to add cpu frequency sets, and the commit related to bin scaling is to scan each cpu's scaling range from 1.2GHz ('15'), 1.296GHz ('13') as @merveric mentioned.
There is no update that I expected like system optimization in core side.
Please refer to my previous post.
viewtopic.php?f=187&t=37452#p296755

Or do you know there is any update in early boot loaders side (ex. miniloader and so on)?
Or Maybe @valadaa48 knows the history, I think.

Here is my test result.
I use Ubuntu 20.04 ES image and switched kernel repo.

I considered 4 Full cores and performance governor option.
1. Instruction

Code: Select all

$ sysbench --version
sysbench 1.0.11

$ sysbench cpu --cpu-max-prime=100000 --time=10 --threads=4 run

Code: Select all

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 
408000 600000 816000 1008000 1200000 1248000 1296000 1416000 1512000 

# echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 
1512000

# echo 1416000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 
1416000

# echo 1296000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 
1296000

2. Test Restult

GO2_CPUMAX_TEST_RETROROLLER.png (42.2 KiB) Viewed 18926 times

With 1.4 & 1.5GHz option, 'total number of events' & 'events' must be increased.
When we tested the actual cpu performance with 1.4 & 1.5GHz by modifying rockchip cpu opp drivers, system got fails or hang.
And in case of single core option, higher benchmark result was shown between 1.30~1.37GHz range, but with 2 cores option, got fail.
That's why 1.5GHz options was removed by default... it was not heating or high current issue.

[bmurphr1]

Would taking a dremel and modifying the battery compartment sidewalls and moving it over enough to put a 5mm heatsink on the CPU make much of a difference? We've been having this discussion on Discord and we found out that if we move the battery all the way to the side of the unit and removed the wall where the battery slips into that it leaves just enough space to include a 5mm copper heatsink on top of the RK3326. I know Crash said that it was not a heat or (voltage) issue but I still wouldn't mind using the overclocking script inside of Retro Roller to at least attempt a frequency higher than 1.3ghz with passive cooling installed. Moving the battery to the side would give us at lesat 0.5 cm clearance to be able to add the heatsink and epoxy it into place with some Arctic Silver thermal adhesive.

I personally already have a copper shim mounted to my CPU and the shim is about 30mm x 30mm and I have thermal adhesive on the CPU but super glue on the RAM chips so that I don't spread heat over to the RAM chips and start corrupting memory, and it gives the copper shim more tensile strength to stay in place. I've tested temperatures in an SSH session and can see that temperatures have definitely decreased across the board especially when the processor is running at full tilt and is generating a lot of heat. My personal setup has shaved at least 10 C off the highest temperatures without modifying the internal structure of the OGA so it was definitely worth the experiment plus it'll let my OGA run for maybe 3 months longer than most other OGAs...lol.

It's hard to imagine that RockChip had such bad luck with every last silicon chip to the point that they can't run past 1.3ghz but if they were purchased in bulk at a huge discount I can certainly see why this particular chip is what ended up inside of the system, but I'm holding out hope that at least with enough cooling that frequencies above 1.3ghz are still possible.

Any thoughts?

[joy]

but I still wouldn't mind using the overclocking script inside of Retro Roller to at least attempt a frequency higher than 1.3ghz with passive cooling installed.

Hi @bmurphr1,
Are you using the latest version of Retro Roller image?
Can you share the information about image version of the Retro Roller image you're using?
And please share where the overclocking script inside is located in the image.
I will use the image and look into it more.

I think there must be a reason why Retro Roller has the option and the users mention it continuously.
So I want to look into it if there is anything more I can figure out.

I did put many kinds of tests with various combinations of CPU core numbers and CPU frequency sets.
BUT, I haven't tried run-time switching of CPU cores numbers with higher frequency sets over 1.3GHz after booting.
Theoretically, it can be possible to run higher frequency over 1.3GHz with fewer cpu cores (1 or 2 core),
but as I tested before, the condition of only 1.35GHz with a single core is a margin for stable booting. It didn't exceed the limit.
But for other cases 'after booting' (like running games with single thread), it's worthy to check more.

[bmurphr1]

I'm on the testing repo, and if you contact the author of Retro Roller (valadaa48) or join the Retro Game Handhelds discord server there are droves of us users and testers on there that use the Arch version of Retro Roller even to this day. We've seen reports that the CPU in short bursts can "possibly" hit 1.55ghz but sustained I'm sure that Crash is right and that there is some kind of hardware limitation that prevents us from running the RK3326 at it's native speed. I don't know for sure if valadaa48 wants us to give out the instructions on how to convert RR Arch over to the testing branch but it's exceptionally easy to do and only involves changes to one file...right now though he's focusing more on Retro Roller running on top of Void Linux which only uses a 40MB boot image and doesn't even come with any cores pre-installed - you have to download them all manually from Safarikniv's repo in order to get all of the cores onto your system (or copy them over to the SD card after flashing it in *nix) so most of his focus is on Void Linux builds right now.

[joy]

Hi @bmurphr1,
Thank you for your feedback and sharing your opinion.

OK. I will find the test branch and test it using a full-built image. I've checked only the test kernel branch.
Or I will contact @valadaa48.

[npaladin2000]

The instructions for switching over are right on the Wiki, so feel free to follow them.

[notime2d8]

I was looking at the rk3308 a quad-core A35 Rockchip SOC. And that chip is also set at 1296mhz but ram at 590mhz.

The rk1808 is a dual core A35 SOC, has 1416mhz, 1512mhz, and 1608mhz CPU clock speeds, but for ram it goes from 784mhz and the next step at 924mhz??

The rk3328 A53 SOC has the same 1296mhz CPU cap, but for ram it also has 800mhz, 850mhz, and 933mhz. I was thinking of trying those at some point.

Also we can try the GPU clock and the sdmmc , but the sdmmc clock may lead to i/o errors.

Rockchip CPU's are overclock-able but it's always been hit or miss with each CPU taking different clocks. At least with my experience with rk3036, 3188T, and rk3368 devices.

Has anyone found or seen any bottlenecks with this device? If i had to assume it would be the random i/o on the micro SD card? It would be cool if we had a sticky with bench-marked micro SD cards. The last recommendations i found for rpi's were Samsung evo's and A1 rated cards, with A2 cards testing slower.

[valadaa48]

The custom kernel -rr has some patches and as joy and crash mention I can't guarantee I tweaked everything to make it a full overclock. In my testing I did notice a measured improvement in sysbench and left it at that. In retrospect, I have run into spurious heating issues under certain workloads and decided not to port these changes to RRVL in the interest of stability.

[valadaa48]

Sorry to wake up this old thread, but I got around to building my custom kernel in RRVL and have some new stats on my overclock to 1.464GHz(?). I tried checked my old notes and my RR branch, and indeed I don't see the tweaks I made where I achieved better sysbench scores (they were certainly less than these). Admittedly, I made a horrible habit in Archlinux making local tweaks to source in the package directory itself so I must not have pushed them. Thankfully, Void's package manager makes this difficult.

Code: Select all

odroid@rrvl $ sudo sysbench cpu --cpu-max-prime=100000 --time=10 --threads=4 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Initializing random number generator from current time


Prime numbers limit: 100000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:   116.18

General statistics:
    total time:                          10.0144s
    total number of events:              1164

Latency (ms):
         min:                                   34.24
         avg:                                   34.39
         max:                                   51.56
         95th percentile:                       34.33
         sum:                                40029.22

Threads fairness:
    events (avg/stddev):           291.0000/0.71
    execution time (avg/stddev):   10.0073/0.00

Code: Select all

$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 
1464000

$ cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 
1464000

$ cat /sys/class/thermal/thermal_zone0/temp # at idle
44545

# cat /sys/class/thermal/thermal_zone0/temp # under sysbench load above
56818

Indeed on stock, I get about 257 events on avg so this appears to be a 13.3% increase. I also tested dreamcast, ppsspp, pcsx 32bit and of course Contra in nestopia and I haven't noticed any issues yet. Indeed the system feels to be a bit smoother and more snappy, but this could all just be a figment of my imagination!

Code: Select all

rockchip,bin-scaling-sel = <
    0               6
    1               6
>;

opp-1464000000 {
    opp-hz = /bits/ 64 <1464000000>;
    opp-microvolt = <1350000 1350000 1350000>;
    opp-microvolt-L0 = <1350000 1350000 1350000>;
    opp-microvolt-L1 = <1350000 1350000 1350000>;
    opp-microvolt-L2 = <1300000 1300000 1350000>;
    opp-microvolt-L3 = <1250000 1250000 1350000>;
    clock-latency-ns = <40000>;
};

I tried for a 1.488 overclock with increased voltage to 1360000 (1350000 wouldn't post) and while it boot, dmesg started producing the following errors:

Code: Select all

[    1.613682] rockchip-thermal ff280000.tsadc: Missing tshut mode property, using default (cru)
[    1.613714] rockchip-thermal ff280000.tsadc: Missing tshut-polarity property, using default (low)
[    1.613869] rk_tsadcv2_temp_to_code: Invalid conversion table: code=4095, temperature=2147483647
[    1.614173] rockchip-thermal ff280000.tsadc: tsadc is probed successfully!
[    1.615386] cpu cpu0: bin=0
[    1.615471] cpu cpu0: leakage=5
[    1.628557] cpu cpu0: temp=42272, pvtm=52629 (52741 + -112)
[    1.629588] cpu cpu0: pvtm-volt-sel=1
[    1.629646] cpu cpu0: bin-scale=6
[    1.630542] core: _opp_supported_by_regulators: OPP minuV: 1360000 maxuV: 1360000, not supported by regulator <--- this line
[    1.630567] cpu cpu0: _opp_add: OPP not supported by regulators (1488000000)
[    1.630619] cpu cpu0: avs=1
[    1.630655] cpu cpu0: avs-scale=4, opp-scale=0
[    1.630673] cpu cpu0: avs scale_rate=1512000000
[    1.630691] cpu cpu0: Failed to adjust opp table
[    1.630833] cpu cpu0: Failed to find opp_table: -19
[    1.630871] cpu cpu1: cpufreq_init: failed to get clk: -2
[    1.630897] cpu cpu2: cpufreq_init: failed to get clk: -2
[    1.630922] cpu cpu3: cpufreq_init: failed to get clk: -2

[   20.579147] rockchip-dmc dmc: cpu2 policy NULL
[   20.635170] rockchip-dmc dmc: cpu2 policy NULL
[   20.695136] rockchip-dmc dmc: cpu2 policy NULL
(this keeps repeating in perpetuity)

I'll try to take a look tomorrow to see if I can fix this and see how high I can get this to go. Depending on stability and power draw, I may consider adding more lower frequencies if that will help with battery life.

@joy, @meveric, let me know your thoughts or suggestions. @notime2d8, I've been following your gpu overclocks, perhaps there is testing or experience we can share.

[joy]

I tried for a 1.488 overclock with increased voltage to 1360000 (1350000 wouldn't post) and while it boot, dmesg started producing the following errors:

Code: Select all

[    1.613682] rockchip-thermal ff280000.tsadc: Missing tshut mode property, using default (cru)
[    1.613714] rockchip-thermal ff280000.tsadc: Missing tshut-polarity property, using default (low)
[    1.613869] rk_tsadcv2_temp_to_code: Invalid conversion table: code=4095, temperature=2147483647
[    1.614173] rockchip-thermal ff280000.tsadc: tsadc is probed successfully!
[    1.615386] cpu cpu0: bin=0
[    1.615471] cpu cpu0: leakage=5
[    1.628557] cpu cpu0: temp=42272, pvtm=52629 (52741 + -112)
[    1.629588] cpu cpu0: pvtm-volt-sel=1
[    1.629646] cpu cpu0: bin-scale=6
[    1.630542] core: _opp_supported_by_regulators: OPP minuV: 1360000 maxuV: 1360000, not supported by regulator <--- this line
[    1.630567] cpu cpu0: _opp_add: OPP not supported by regulators (1488000000)
[    1.630619] cpu cpu0: avs=1
[    1.630655] cpu cpu0: avs-scale=4, opp-scale=0
[    1.630673] cpu cpu0: avs scale_rate=1512000000
[    1.630691] cpu cpu0: Failed to adjust opp table
[    1.630833] cpu cpu0: Failed to find opp_table: -19
[    1.630871] cpu cpu1: cpufreq_init: failed to get clk: -2
[    1.630897] cpu cpu2: cpufreq_init: failed to get clk: -2
[    1.630922] cpu cpu3: cpufreq_init: failed to get clk: -2

[   20.579147] rockchip-dmc dmc: cpu2 policy NULL
[   20.635170] rockchip-dmc dmc: cpu2 policy NULL
[   20.695136] rockchip-dmc dmc: cpu2 policy NULL
(this keeps repeating in perpetuity)

Hi @valadaa48,
Thank you for sharing your investigation.

Regulator range for CPU_VDD is set as 0.95V ~ 1.35V.
- RK817 BUCK2
- defined as vdd_arm here.
https://github.com/hardkernel/linux/blo ... 1.dts#L623

Code: Select all

			vdd_arm: DCDC_REG2 {
				regulator-always-on;
				regulator-boot-on;
				regulator-min-microvolt = <950000>;
				regulator-max-microvolt = <1350000>;
				regulator-ramp-delay = <6001>;
				regulator-initial-mode = <0x2>;
				regulator-name = "vdd_arm";
				regulator-state-mem {
					regulator-off-in-suspend;
					regulator-suspend-microvolt = <950000>;
				};
			};

Buck2 of RK817 supports Max. 2.4V (12.5mV step) by its specification, so it's available to adjust the maximum value to higher values like 1.4V,
but, from RK3326 point of view, higher CPU_VDD value than "1.35V" is over-spec,
max voltage for CPU_VDD is 1.35V.

But just try it only for test!

[valadaa48]

Thanks Joy.

I report that I'm running at 1.512GHz @ 1.4V now and it seems stable.

Here are some further stats:

Code: Select all

400MHz   events (avg/stddev):           21.0000/0.00
1.296GHz events (avg/stddev):           255.2500/1.48
1.464GHz events (avg/stddev):           291.5000/0.87
1.488GHz events (avg/stddev):           296.5000/0.50
1.512GHz events (avg/stddev):           301.2500/0.83

Couldn't get it past 1.512GHz though, I guess the cpu just won't actually overclock? Also, GPU I managed to get to 600 but it kept failing under load, 560MHz seems better even with the cpu at 1.512GHz. I don't have a good way of benchmarking the gpu and it seems it's really only used for games I don't play, so I'm not too concerned and will leave it up to a reader that has more interest.

What I did not manage to figure out was how to enable more than 3 cpu frequencies, say if you set cpu governor to userspace and allowed each step from 1.296 to 1.512 then let the user manually select what they are comfortable with. It seems according to sysbench that it wouldn't go past the 3rd index entry in the opp table.

Anyway, I'm pretty satisfied with this. The system feels more snappy overall and FPS seems to be increased with less deviation. Although maybe this is still all just a figment of my imagination!

[rooted]

I don't know if it's available but something like quake 3 would be a good GPU benchmark.

[notime2d8]

Couldn't get it past 1.512GHz though, I guess the cpu just won't actually overclock? Also, GPU I managed to get to 600 but it kept failing under load, 560MHz seems better even with the cpu at 1.512GHz. I don't have a good way of benchmarking the gpu and it seems it's really only used for games I don't play, so I'm not too concerned and will leave it up to a reader that has more interest.

This is what I found as well. It's weird too because 590MHZ works as well without crashing. But I didn't notice any improvement from the GPU for 520-590mhz only at 600mhz. But I'm using a 3d game loop in Reicast to benchmark. I also upgraded to the latest Mali kernel driver, with no improvement. And I run my Android kernel at 1.5ghz with no issues after long use. But Rockchip CPUs are funny, every chip may not be stable at 1.5ghz. But I've run 5 ogas at that speed with no issue.

Also something I found weird...my oga didn't generate heat until I overclocked the ram to 850mhz...no noticable improvement in benchmarks or UI but my oga did get warmer.

But for Dreamcast emulation. It seems the GPU is the bottleneck that and/or emulator optimization.

[valadaa48]

Couldn't get it past 1.512GHz though, I guess the cpu just won't actually overclock? Also, GPU I managed to get to 600 but it kept failing under load, 560MHz seems better even with the cpu at 1.512GHz. I don't have a good way of benchmarking the gpu and it seems it's really only used for games I don't play, so I'm not too concerned and will leave it up to a reader that has more interest.

This is what I found as well. It's weird too because 590MHZ works as well without crashing. But I didn't notice any improvement from the GPU for 520-590mhz only at 600mhz. But I'm using a 3d game loop in Reicast to benchmark. I also upgraded to the latest Mali kernel driver, with no improvement. And I run my Android kernel at 1.5ghz with no issues after long use. But Rockchip CPUs are funny, every chip may not be stable at 1.5ghz. But I've run 5 ogas at that speed with no issue.

Also something I found weird...my oga didn't generate heat until I overclocked the ram to 850mhz...no noticable improvement in benchmarks or UI but my oga did get warmer.

But for Dreamcast emulation. It seems the GPU is the bottleneck that and/or emulator optimization.

Yeah, I tried everything I could to get the GPU stable at 600 but didn't have any success. Interesting about the RAM, I didn't know that was overclockable. I haven't tried it yet as I do only have 1 device.

I don't know if we're able to get a standalone flycast to try, but certainly in ppsspp's case, its libretro core is dog slow. Like 20fps vs 60fps in standalone. I also tested @crash's retrorun to see if it was perhaps related to anything in retroarch itself and I noticed the same performance degradation vs standalone. I'm guessing it must be either something inherent with the libretro semantics or something in ppsspp itself that doesn't lend itself well to the libretro code paths.

[notime2d8]

I wonder why we can't get over 1.512GHz the kernel has other options defined in clk-px30.c:

Code: Select all

	PX30_CPUCLK_RATE(1608000000, 1, 7),
	PX30_CPUCLK_RATE(1584000000, 1, 7),
	PX30_CPUCLK_RATE(1560000000, 1, 7),
	PX30_CPUCLK_RATE(1536000000, 1, 7),

I wonder if we're missing a setting somewhere. I also couldn't find any information on "rockchip,bin-scaling-sel" how it works or what it's values mean.

[sana2dang]

https://github.com/hardkernel/linux/tre ... dgoA-4.4.y

Hi.

In the above source code
What can be modified to enable overclocking?

[Slaminger]

I wonder why we can't get over 1.512GHz the kernel has other options defined in clk-px30.c:

Code: Select all

	PX30_CPUCLK_RATE(1608000000, 1, 7),
	PX30_CPUCLK_RATE(1584000000, 1, 7),
	PX30_CPUCLK_RATE(1560000000, 1, 7),
	PX30_CPUCLK_RATE(1536000000, 1, 7),

I wonder if we're missing a setting somewhere. I also couldn't find any information on "rockchip,bin-scaling-sel" how it works or what it's values mean.

its not that we CAN'T do it, its that the device becomes unstable and has issues loading or crashes.

[rooted]

I wonder why we can't get over 1.512GHz the kernel has other options defined in clk-px30.c:

Code: Select all

	PX30_CPUCLK_RATE(1608000000, 1, 7),
	PX30_CPUCLK_RATE(1584000000, 1, 7),
	PX30_CPUCLK_RATE(1560000000, 1, 7),
	PX30_CPUCLK_RATE(1536000000, 1, 7),

I wonder if we're missing a setting somewhere. I also couldn't find any information on "rockchip,bin-scaling-sel" how it works or what it's values mean.

its not that we CAN'T do it, its that the device becomes unstable and has issues loading or crashes.

I don't believe all devices will become unstable, just most.

[notime2d8]

I wonder why we can't get over 1.512GHz the kernel has other options defined in clk-px30.c:

Code: Select all

	PX30_CPUCLK_RATE(1608000000, 1, 7),
	PX30_CPUCLK_RATE(1584000000, 1, 7),
	PX30_CPUCLK_RATE(1560000000, 1, 7),
	PX30_CPUCLK_RATE(1536000000, 1, 7),

I wonder if we're missing a setting somewhere. I also couldn't find any information on "rockchip,bin-scaling-sel" how it works or what it's values mean.

its not that we CAN'T do it, its that the device becomes unstable and has issues loading or crashes.

I don't believe all devices will become unstable, just most.

Yes, I could overclock my OGA BE to 1.5GHZ and it was stable. I could set in 1536,1560, and 1608, and it would boot and run just fine, but checking the CPU speed it would still report 1512. I couldn't get the kernel to report anything higher or not boot because of the higher clocks. It was just a quick try though.

[joy]

Hi.
Based on RRVL linux github and the following overclock-related commit, we tested cpu benchmarks.
https://github.com/valadaa48/linux/commits/rrvl
https://github.com/valadaa48/linux/comm ... 0820a0e144

And we uploaded a commit to test overclock options by setting max cpu frequency via a kernel command parameter.
https://github.com/hardkernel/linux/com ... 37eac2b462

Still there is an unsolvled problem.
On RRVL image with the overclock option, OGS boots normally and the sysbench score of 1.512GHz is reasonable,
but using HK ES image, system freezing is still shown even with 1.440GHz.
It seems there are some different factors and I think forum users can find better solutions.

Here is a test guide and some benchmark results.

1. Setting guide using boot.ini
Using max_cpufreq in boot.ini, you can set max cpu frequency limit.

Code: Select all

# Boot Arguments
setenv bootargs "root=UUID='e139ce78-9841-40fe-8823-96a304a09859' rootwait rw fsck.repair=yes net.ifnames=0 fbcon=r
otate:3 console=/dev/ttyFIQ0 splash plymouth.ignore-serial-consoles consoleblank=0"

setenv bootargs ${bootargs} max_cpufreq=1440

Available frequency list is as following.

Code: Select all

1512
1488
1464
1440
1416
1368
1296
1200
1008
600
408

By default, max cpu freuqency is set as 1.296GHz.

ex) max_cpufreq=1296

Code: Select all

root@goadvance:~# echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 
root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 
performance
root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 
408000 600000 1008000 1200000 1296000 
root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 
1296000

ex) max_cpufreq=1416

Code: Select all

root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 
408000 600000 1008000 1200000 1296000 1368000 1416000 
root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 
performance
root@goadvance:~# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 
1416000

2. Benchmark Test Result

Code: Select all

$ sysbench cpu --cpu-max-prime=20000 --threads=4 run

ogs_benchmark_20210325.png (147.34 KiB) Viewed 14807 times

3. defconfig difference from RRVL
There are many different configuration between original odroidgoa_defconfig and the latest RRVL's config-4.4.189_RRVL-23,
I picked up just some related defconfig to run overclock on ES image (from my point of view...).
Maybe there can be other necessary configs that should be added to run overclock more stably.

[sana2dang]

By modifying and applying the contents below
1.488GHz boot sometimes succeeds.
1.464GHz boot was successful 10 times at 10 attempts.

https://github.com/valadaa48/linux/comm ... 39a2410858




The contents of the file changed only the following two items.
file : /arch/arm64/configs/odroidgoa_defconfig

#CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_USB_DWC2=m

[joy]

@sana2dang,
Oh! Nice Finding!
Thank you for sharing your update.

Which toolchain version are you using for OGS kernel build?

[sana2dang]

@joy,

vm - ubuntu 18.04

I followed the guide below. (
https://wiki.odroid.com/odroid_go_advan ... t-pcubuntu


aarch64-linux-gnu-gcc -v

gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)

[valadaa48]

If it helps, I did strip out as much as I could from the kernel but then I guess I slowly added it back to help debug the OGS. As sana2dang mentioned, RRVL didn't optimize for size, there may also be a -march flags in the kernel too like gentoo-experimental does. Also, I forced the cpu governor to userspace so it would boot at 1.296 to mitigate any instability on startup caused by potential spikes then set 1.5GHz on-demand or after everything settles.

Void Linux was on gcc 9.3.0 for a long time then we finally moved to 10.2.x.

To get more stable times, you should stop RetroArch on RRVL: `sudo sv stop retroarch`, not doing so tends to lower the sysbench score quite a bit.

I usually ran sysbench via: sudo sysbench cpu --cpu-max-prime=100000 --time=10 --threads=4 run

Code: Select all

408000 benchmarks to events (avg/stddev):           80.7500/0.83
1296000 (default) to 258
1416000 to 281.2500
1512000 to 301.0000

My unit even reached 1.6 with a bit more tweaking elsewhere in the DTS: events (avg/stddev): 318.5000/1.80

Interestingly enough, my same unit wouldn't boot EE at 1.5...

[joy]

@sana2dang,
Thanks for sharing the information.

If it helps, I did strip out as much as I could from the kernel but then I guess I slowly added it back to help debug the OGS. As sana2dang mentioned, RRVL didn't optimize for size, there may also be a -march flags in the kernel too like gentoo-experimental does. Also, I forced the cpu governor to userspace so it would boot at 1.296 to mitigate any instability on startup caused by potential spikes then set 1.5GHz on-demand or after everything settles.

Void Linux was on gcc 9.3.0 for a long time then we finally moved to 10.2.x.

To get more stable times, you should stop RetroArch on RRVL: `sudo sv stop retroarch`, not doing so tends to lower the sysbench score quite a bit.

@valadaa48,
Thanks for your detailed descriptions.
Yes. I found the differences of kernel configuration and I tried the same defconfig on HK ES image, but it rarely boots with over 1.464GHz on my test environment.
But sana2dang already got normal booting in case of 1.464 GHz and 1.488 GHz, so maybe I missed something in other test factors or environment.
Also toolchain, front-end applications and system configurations for each base image can be important factors affecting the difference of booting stability and performance.

Let's keep sharing what we research in each environment here in this thread.

By the way, we made a simple wiki page related to this topic.
https://wiki.odroid.com/odroid_go_advan ... /overclock

[crashoverride]

Looking at the data (chart posted by @joy), it appears that the Reference Image kernel is doing more work per clock than the RRVL image. This could possibly explain why one image is affected more by over-clocking than the other: more work changes the thermal dynamics of heat generation to dissipation.

The RRVL 1512Mhz is roughly equivalent to the 1416Mhz Reference Image in terms of work per clock. Both operate correctly at this performance level.

[edit]
For more accurate results, testing should probably be performed in uboot. However, I do not know if any benchmarking/stress tools are available there.

[joy]

Looking at the data (chart posted by @joy), it appears that the Reference Image kernel is doing more work per clock than the RRVL image. This could possibly explain why one image is affected more by over-clocking than the other: more work changes the thermal dynamics of heat generation to dissipation.

The RRVL 1512Mhz is roughly equivalent to the 1416Mhz Reference Image in terms of work per clock. Both operate correctly at this performance level.

In the case where emulationstation is running on HK ES image, sysbench score goes down as I tested on RRVL image,
and the offset is almost same.
Please refer to the 1st table and 3rd one.
So, as you mentioned, more work can change the situation.

[edit]
For more accurate results, testing should probably be performed in uboot. However, I do not know if any benchmarking/stress tools are available there.

That's a good approach.

[valadaa48]

Just in case, you may try forcing userspace governor in the kernel config so you'll be booting at 1.296. My supposition is systemd is a bit heavier and has more parallelism than runit. Runit is actually serial and RRVL loads very few services. Then only after things settle, bump the cpu freq to what the user selected.

[Slaminger]

Tested and working ok on Retro Arena, will be included in the next build which is uploading now.