You're spot on. rk3328 also has non-trivial throttling. Maybe rk3288 throttles a bit more since it has higher clocks. I saw the same on mine when pushing four cores to the limit. I would assert everyone is about the same on this form factor. So some people install a fan but that breaks the beautify of this FF.
On my build, I push up the thermal threshold by 5 degree C at 75. It delays throttle process and give it a bit more time to stay closer to 85 degree C where throttle starts. This is like black magic and keeps the SoC spending more time between 80 and 85 C and overall better performance. I saw the Rock64 kernel is very aggressive on this but their numbers don't work out nicely for my board. Perhaps give it a try and find the sweet spot in your DTS file.
The 3288 is just overkill in this form factor - maybe for Chromebook/Chromebox or Android Set Top box where one can have a better thermal solution... as it stands now, once the throttling starts, even at 600MHz it can't shed heat fast enough, and basically gets heat soaked... Part of the challenge is that all four cores are locked together in the time domain - so if one core turbos up to max speed, they all do, even if they're idle... and being big cores (like the A9/A15), look at the thermal solutions on most Router/AP's like Asus, Netgear, Linksys and the like - big honking heatsinks there.
Going to a bigger heat sink on the Tinker - one starts running into clearance issues everywhere on the board - between the GPIO connector, the display and camera connectors, and at least one capacitor, there's just not a lot of room for a passive solution - so active cooling with a fan is really the only option, or just live with the throttling on this board.
I've done some prelim exploration on the DFVS settings, but the Armbian folks have sorted out what is probably the best compromise for the 3288 - even there though - if one sets the governor to "performance", it idles at 70C with the stock 1.8GHz clocks... "ondemand" helps out there, and no real impact to performance.
From cpufreq-info (part of cpufrequtils package) - here's the armbian curves for the Tinkerboard - I'll have to check what they're doing with the
MiQi board, but I suspect it's similar..
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
Changing topic a bit - have you had a chance to play around with the crypto stuff on the 3328 in ARMv8 mode?
The 3328 does support the Cortex-A53 crypto extensions (unlike the Pi3 line), so might be interesting to compare the ARM stuff against the dedicated crypto blocks on the 3328.
