ginggs Posted December 28, 2019 Share Posted December 28, 2019 Armbianmonitor: http://ix.io/25Ix Hi! I seem to have the same problem described here: I have an Asus Tinkerboard, not the S version. Today I upgraded from the latest Asus TinkerOS image: 20190821-tinker-board-linaro-stretch-alip-v2.0.11.img to: Armbian_19.11.3.346_Tinkerboard_buster_current_5.3.15_minimal.img I notice that my maximum CPU frequency has dropped from 1.80GHz to 1.61GHz. cpufreq-info now reports: $ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 115 us. hardware limits: 126 MHz - 1.61 GHz ... and my cpufrequtils config is unmodified: $ cat /etc/default/cpufrequtils ENABLE=true MIN_SPEED=600000 MAX_SPEED=1900000 GOVERNOR=ondemand Whereas on TinkerOS, cpufreq-info reported: $ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 115 us. hardware limits: 126 MHz - 1.80 GHz ... Is this something I can change locally, or does something need to change in the Armbian image? Link to comment Share on other sites More sharing options...
Igor Posted December 28, 2019 Share Posted December 28, 2019 2 hours ago, ginggs said: Is this something I can change locally, or does something need to change in the Armbian image? You already find where things changes in a simple manner while for this you will need to dig into the code. Probably "just" higher frequencies were not find a way to modern kernel DT or someone throw them out by purpose to gain stability ... which is questionable if you power with microUSB. When you power properly, chip can run stable at 1.8 (for sure) 2.0 (good ones) ... Investigation is needed. Probably just this patch needs duplication on Tinkerboard. Link to comment Share on other sites More sharing options...
TonyMac32 Posted December 29, 2019 Share Posted December 29, 2019 On 12/28/2019 at 2:11 PM, Igor said: Probably "just" higher frequencies were not find a way to modern kernel DT Yes, this. So, there are several different RK3288's out there, the kernel supports them all as one. Only the RK3288C can do 1.8 GHz officially, and that is the one in the Tinker Board. Apparently the patch adding the opps has not been applied correctly. May I add that I believe this is being corrected upstream for the Tinker Board, I saw it mentioned on the mailing list. Link to comment Share on other sites More sharing options...
ginggs Posted December 29, 2019 Author Share Posted December 29, 2019 Thanks for yours answers. 1 hour ago, TonyMac32 said: May I add that I believe this is being corrected upstream for the Tinker Board, I saw it mentioned on the mailing list. Is that Linux or Asus upstream? Link to comment Share on other sites More sharing options...
TonyMac32 Posted December 29, 2019 Share Posted December 29, 2019 Mainline. I will look at the patch set later today and hopefully rectify the issue in our build system.Sent from my Pixel using Tapatalk Link to comment Share on other sites More sharing options...
Guest Posted January 1, 2020 Share Posted January 1, 2020 Just noticed this myself on my Tinkerboard. Glad to see you guys are already on it. Thanks! Link to comment Share on other sites More sharing options...
ginggs Posted January 16, 2020 Author Share Posted January 16, 2020 I recently received some updates via apt; armbian-firmware, linux-u-boot-tinkerboard-current, etc. all upgraded from 19.11.3.346 to 19.11.8. I don't see any change in CPU frequency. If the issue was fixed, would it be fixed for me by an apt update, or would I need to start from a new Armbian image? Link to comment Share on other sites More sharing options...
Igor Posted January 16, 2020 Share Posted January 16, 2020 10 minutes ago, ginggs said: If the issue was fixed, If its not here https://docs.armbian.com/Release_Changelog/ then it was not specifically fixed. Link to comment Share on other sites More sharing options...
ginggs Posted January 16, 2020 Author Share Posted January 16, 2020 9 minutes ago, Igor said: If its not here https://docs.armbian.com/Release_Changelog/ then it was not specifically fixed. I don't see any changes for 19.11.8 there. Link to comment Share on other sites More sharing options...
Igor Posted January 16, 2020 Share Posted January 16, 2020 59 minutes ago, ginggs said: I don't see any changes for 19.11.8 there. In that case, no changes were officially made. Link to comment Share on other sites More sharing options...
TonyMac32 Posted January 20, 2020 Share Posted January 20, 2020 This could have been like this for a while (since the restructure), a patch I had in the system disappeared it looks like, I reapplied for current kernel, added the MiQi turbo mode patch to the RK3288.dtsi so it can be used with any board where the user wishes (and cleans up our patch directory). Link to comment Share on other sites More sharing options...
Guest Posted February 21, 2020 Share Posted February 21, 2020 So just did an apt update and found there was a new kernel (5.4.20 / 20.02.1) and I had the option to set the max CPU speed at 1.8 ghz so it appears to be fixed. Link to comment Share on other sites More sharing options...
TonyMac32 Posted February 22, 2020 Share Posted February 22, 2020 So just did an apt update and found there was a new kernel (5.4.20 / 20.02.1) and I had the option to set the max CPU speed at 1.8 ghz so it appears to be fixed.Yes, I took care of it. Sent from my Pixel using Tapatalk Link to comment Share on other sites More sharing options...
ginggs Posted February 22, 2020 Author Share Posted February 22, 2020 I've just upgraded and cpufreq-info now reports: cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 132 us. hardware limits: 126 MHz - 1.80 GHz ... Thanks @TonyMac32 ! 1 Link to comment Share on other sites More sharing options...
Recommended Posts