Edited by bronco at 2015-11-21 18:34

I had a look into Allwinner's H3 SDK today:

In the tools/pack/chips/sun8iw7p1/configs/ folder there are a couple of settings available but they all are identical more or less. As an example:

h3-dolphin-p1.fex: http://pastebin.com/WgpwUyyA
h3-dolphin-perf.fex: http://pastebin.com/dtjpmDKs

They share the following settings and the only noticeable difference is pmuic_type 2 vs. 0 (pmuic_type:0:none, 1:gpio, 2:i2c -- the Orange Pi's SY8106A is connected via I2C therefore 2 applies)


The fex files used with the H3 based Orange Pis differ as follows (taken from orange_pi_pc.fex):


Based on this it's obvious:

• H3's recommended maximum frequency is 1.200 MHz
• Anything exceeding that is for OTT box manufacturers to fool customers (to provide higher Antutu scores)
• The 672 MHz DRAM frequency as well as the 1.53 GHz used with Orange Pis can be called overclocking by default
• These settings lead to unnecessarily high consumption and temperatures
  

The H3 is just another incarnation of the same old boring ultra-slow Cortex-A7 design Allwinner uses since years combined with a Mali400MP2 GPU. Neither the A20 (dual-core A7 with Mali) nor the A31s (quad-core A7 with PowerVR) suffered from the heat problems the forums here are full of. They're both manufactured in the older 40nm process whereas H3 is already 28nm. Both are able to run without any heatsink when sane dvfs settings are used unless overclocked or constantly operated under full load (BTDT).

That's what dvfs is for: Defining different operating points to let the SoC being fed with less voltage when it's idle. There's no need for heatsinks and fan when you define dvfs settings correctly unless you really want to use an overclocked chip that even consumes too much energy and overheats when idle (that's the result of the dvfs table entries containing only 2 operating points and being both on the upper limit or let's better say exceeding the recommended limit already).

For now I'm both done and convinced that the H3 is a wonderful SoC that doesn't suffer from heat problems 'by design'. Fortunately these problems are 'handmade'.

When my Orange Pi PCs arrive (I ordered two to be able to fry one -- I'll try to feed the SY8106A with 12V since according to the datasheet it's possible to provide up to 18V) I'll get back to you with an H3 RPi-Monitor template, conservative settings (based on these settings as a first try) and measurements.

Isn't dram in the OPI rated for 1600MT (so 800Mhz) ?

So its really memory controller, that is overclocked here, not the dram itself.

Edited by hojnikb at 2015-11-21 20:44

Btw, could it be possible to define a "turbo boost" type of deal, that would only clock one or two cores at above 1.2Ghz, but only for a short while...That way you would still have some extra performance, but would probobly not heat as much.

Edited by bronco at 2015-11-21 21:52

Correct, this type of DRAM is used: http://linux-sunxi.org/DDR3#K4B4G1646Q-HYK0

Regarding memory controller and 'turbo boost' and so on... you buy Allwinner chips not since you want performance. You buy them because they're dirt-cheap. Especially SoCs with aging Cortex-A7 cores (rather sooner than later the consumer demand for these type of SoCs will drop since consumers then all need '64 bit' the same way they demand now 'octa core' and 'quad core' even when the SoC will be slower than a dual-core machine -- it's 'marketing for morons' that completely drives this market segment)

Especially the H3 is dirt-cheap and enables OTT box manufacturers to produce dirt-cheap TV boxes (why not tablets also? Because there's no PMU with the H3, therefore no charging capabilities, that's why all attempts to use H3 based Orange Pis for mobile applications are just weird, better use the A20 based instead, the A20 is superiour to the H3 in terms of features and maybe also singe-core performance). The H3 contains the well known outdated Mali400MP2 GPU (therefore we see now things happen here that happend over at LeMaker's forums last year with the A20) and also an integrated 100 MBit Ethernet PHY further decreasing costs to build a system around the H3.

There's no such thing like turbo mode. You can adjust some clock speeds (and have to take care since some components share the same clock sources so by increasing some value here the clockspeed somewhere else might actually decrease since another divider will be automagically chosen and so on) and you should always keep an eye on consumption (unfortunately not that easy with the H3 since unlike other Allwinner SoCs that feature a PMU that can be queried through sysfs there's nothing comparable here -- you have to use internal temperatures without a fan as indicator how much energy you waste).

And the problem the H3 users are currently suffering from doesn't happen when the H3 is under full load. It seems idle consumption is the real problem. I'm already preparing an RPi-Monitor template for the H3 to play with. In case anyone's interested I can share it here together with short instructions. Will take you 5 minutes maximum and gives you the ability to visualize what's going on. Eg. decreasing DRAM frequency from 672 to 480 (echo 480000 >/sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq) and let RPi-Monitor plot a nice graph regarding the SoC's temperature... Just an assumption that it works that way -- still waiting for my Oranges to arrive.

BTW: It also depends on the use case you're after. Since on ultra-cheap SoCs like Allwinner's everything seems to interact with anything else you might think about running an SBC based 'server' headlessly not since less running services are better but since GPU and CPU also have to share memory bandwidth: http://linux-sunxi.org/Optimizin ... ution_graphics_mode (no idea wether that applies to the H3 as well but since one of the keys to produce dirt-cheap chips is to re-use everything instead of re-inventing the wheel I would suspect the H3 suffers from the same issue -- to be confirmed)

If I adjust the .fex file and reboot, will the changes apply?  or is the .fex file just a residual from which uImage was built?

Also, does adjusting /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq have any effect on voltages?  From above, it looks like using the .fex that ships with the device, that scaling to 1Ghz would have the same effect as scaling to 1.2Ghz.  eg.  1.3v either way.

Assuming all this is true, wouldn't it be best to create a complete correct dvfs table that includes overclocked values such as 1536, 1296 frequencies, and then adjust scaling_max_freq at boot to whatever you feel comfortable with based on needs and cooling?