cmoski

@5kft -- Thanks for this, worked like a charm! For anyone looking for more -- all I had to do was grab the device tree tools and run the following on the existing dtb in the boot directory:
 
dtc -O dts s5p6818-nanopi-fire3.dtb > fire3-devicetreetxt.dts #[Modify frequencies on dts file, too lazy to build a sed command] dtc -O dtb fire3-devicetreetxt.dts > s5p6818-nanopi-fire3.dtb I think on the FriendlyArm provided distro this would be the 05.dtb file as @wtarreau mentioned. No recompilation of the kernel required, just a reboot.
 
It seems that for any overclock a small voltage bump is required. I am still looking into if this will push my 10 port USB hub (60w anker) past its rated capacity when all 10 Fire3's are loaded to 100%.
 
@wtarreau -- If you have a chance I'd love to take a look at your thermal throttling point configuration. Standard disclaimer of course noted :-)
 
Thank you both!
 

I did just that:
 

 
The thick thermal pad has been removed and replaced with a 15x15mm copper shim (0.8mm height). The grey stuff around the SoC are leftovers from another thermal pad (came with RockPro64) just to prevent shorting things with the heatsink.
 
I tried to use sbc-bench in thermal testing mode. NanoPi Fire is in upright position (so convection might help a little bit) in a room with 24°C ambient temperature.
sbc-bench.sh -T 80 ; sbc-bench.sh -t 60 Problem N° 1: with stock thermal pad I would have to wait endlessly for the SoC to cool down below 60°C (that what 'sbc-bench.sh -t 60' is supposed to do). The board once hot remained at 62°C to 63°C. I had to temporarely switch cpufreq governor to let the CPU cores clock down from 1400 to 400 MHz to get an idle temperature below 60°C again.
 
Then numbers were as follows:
1400 MHz: 146.17 sec 1300 MHz: 148.42 sec 1200 MHz: 0 sec 1100 MHz: 0 sec 1000 MHz: 0 sec 900 MHz: 0 sec 800 MHz: 0 sec 700 MHz: 0 sec 600 MHz: 0 sec 500 MHz: 0 sec 400 MHz: 5.80 sec (the 6 seconds on 400 MHz are not result of throttling but me manually switching back to performance cpufreq governor once the real benchmark run started). Full output where you can see how long it took to cool down from 80°C to 60°C: https://pastebin.com/raw/1DDt8yGk
 
Now with copper shim instead of thermal pad.
 
Problem N° 2: now it's impossible for the 'pre-heat' run to get above 80°C. I would have to wait endlessly for this so I stopped and ran 'sbc-bench.sh -T 78 ; sbc-bench.sh -t 60' instead to only wait until temperature exceeds 78°C. Full output: https://pastebin.com/raw/a0vmQJ0b
 
No throttling happened and temperature remained below 80°C. Again it's obvious that thermal pads simply suck when it's about efficient heat dissipation. But I've to admit that I've no idea whether the contact area now with my copper shim is sufficient or thermal pads are the recommended way since with my copper shim now only the very small die area and the copper shim have contact while the area around not.
 
@mindee can you please shed some light?
 
Edit: haha, today I realized that I ran with just 4 CPU cores active yesterday when I made my tests due to 'maxcpus=4' set in /boot/armbianEnv.txt (to test for swap efficiency of various approaches). Doesn't change anything wrt thermal conductivity but of course now with all 8 CPU cores active NanoPi Fire3 starts to throttle severely when running heavy stuff but at least with copper shim clockspeeds are much higher compared to thermal pad.

Confirmed, from memory I just added a line with "1600000 1250000". Mine is ultra-stable even with 8 cores at full speed. It happens to throttle a little bit from time to time because the heat cannot escape easily from the cardboard enclosure, but that's all. From what I remember from the datasheet, the chip is designed to run at 1.6 GHz, that's why I picked this frequency.
I also modified the thermal triple points because I don't want the machine to throttle quickly, I seeked the limits on mine and set the points slightly below. I can upload the file later if some want it. It's just that it's possible that my temp limits might cause issues to others so we need to be cautious and I don't want people to randomly download the file without reading the context, then complain about this board's stability when using armbian...
 

Hi @cmoski, in case it is helpful to you:  If you are using the "nanopifire3" board configuration ("next" target), you can build the kernel, specifying the "CREATE_PATCHES=yes" option, and then modify the generated DT in "cache/sources/linux-4.14.y/arch/arm64/boot/dts/nexell/s5p6818-nanopi-fire3.dts".  Look for "dvfs-tables" in this DT file and edit/add the higher frequency:
dvfs:dynamic-freq@bb000 { supply_name = "vdd_arm_spu"; supply_optional = "vdd_arm_axp"; vdd_arm_spu-supply = <&VCC1P1_ARM_SPU>; vdd_arm_axp-supply = <&VCC1P1_ARM_PMIC>; status = "okay"; dvfs-tables = < 1400000 1200000 1300000 1140000 1200000 1100000 1100000 1040000 1000000 1040000 900000 1000000 800000 1000000 700000 980000 600000 980000 500000 940000 400000 940000>; }; In this table the first column is the frequency, and the second is the voltage provided by the SPU1705 regulator for that frequency.  Note that the maximum voltage that this regulator can output is 1.265v (please see ".../drivers/regulator/spu1705.c" for details).
 
My Fire3 could run fine at 1.5GHz using 1.265v, but 1.6GHz was too unstable (random crashes).  The original FriendlyELEC kernel tree sets the maximum to 1.4GHz at 1.2v, so this is what I brought over to Armbian.
 
I hope this helps...!