Making some progress - bit of a performance hit at the moment, but have been clawing much of it back...
Current objective with the power/temp situation - pretty much concede that at 1.8GHz, the rk3288 is going to always be throttling, so the next step is to give it more range, as throttling is a passive cooler in it's own right.
Current Armbian has idle close to 70C, with the clocks for cpu/mem, along with governors for cpu and io - and 70C is where we start throttling, so the least amount of activity there is going to the wall already.
All the core clocks are still locked together on a hw basis, can control via SW, but it's global - still looking at docs and code to see if we can break that out into individual core clocks - might not be possible.
This is where Armbian is now - min clock is 600MHz, max clock is 1800MHz - this is all set in uboot..
Code:
driver: cpufreq-dt
CPUs which run at the same hardware frequency: 0 1 2 3
CPUs which need to have their frequency coordinated by software: 0 1 2 3
maximum transition latency: 136 us.
hardware limits: 600 MHz - 1.80 GHz
available frequency steps: 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.51 GHz, 1.61 GHz, 1.70 GHz, 1.80 GHz
available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil
With the stock HS provided by Asus, it's not bad... but it's got a hysteresis all it's own - it's going to absorb heat from the CPU and radiate it out at a given rate, and with the Armbian clocks, min freq at 600 under load, the CPU is going to keep putting heat into it - the HS can only remove so much
Pretty much got all the performance back, some stability issues* at the moment using the Armbian uBoot and Device Tree, so time to set up an Ubuntu 16.04 image and do the kernel rebuild and put the stock Rockchip configuration items back in as Rockchip and Linaro pushed in a lot of updates back in June 2018 which Armbian might not have picked up...
* stability - yes, we're crashing threads, this happens when playing around with dvfs primitives
While I'm at it, might as well check on the rest of the crypto stuff for cryptodev and AF ALG while I'm in there - then we can tweak openssl to turn on those engines for userland once I get the power/temp sorted...
Good resources of info on the rk3288
- The ChromiumOS git - lot of good info there, as many ChromeBooks run this chip, board level stuff has been helpful, and might as well fast follow Google there
- The Rockchip Wiki and Docs - the Wiki has the best info, and note that TinkerBoard is a fully supported platform now in mainline with 4.14.67, which the the kernel I'm working with here
- The ARM ARM - the ARM Architecture Reference Manual, and there is a great tool for any ARM chip -ensure that it's current (can't share, but there's many copies on the web, so it's easy to get, just make sure it covers the core that's being worked with) - with rk3288, treat it like A12, as that's what it really is, the A17 intrinsics complicate things by assuming it can be big.LITTLE, which the rk3288 is not...
- byte-unixbench - perhaps not the best benchmark these days, but it's still a good load tester to push a lot of work into a processor - look at the options in the .Run file to focus things and save time perhaps - but once there, if tweaking the make file, not looking to improve numbers in the benchmark, but see what impact changes on kernel/dtree/uboot can offer...
