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?

 

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.

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.

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?

 

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

Just noticed this myself on my Tinkerboard.  Glad to see you guys are already on it.  Thanks!

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?

 

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.

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.

 

59 minutes ago, ginggs said:

I don't see any changes for 19.11.8 there.

In that case, no changes were officially made.

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).

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.

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

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 !