Jump to content

Recommended Posts

Posted

is it normal?

 

 

armbian@orangepizeroplus2:~$ sudo armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.

17:49:19: 1152MHz  0.45   4%   0%   1%   0%   2%   0% 23.2蚓  0/8
17:49:24: 1152MHz  0.42   0%   0%   0%   0%   0%   0% 23.2蚓  0/8
17:49:29: 1152MHz  0.38   0%   0%   0%   0%   0%   0% 23.4蚓  0/8
17:49:34: 1152MHz  0.35   0%   0%   0%   0%   0%   0% 23.5蚓  0/8
17:49:39: 1152MHz  0.32   0%   0%   0%   0%   0%   0% 23.6蚓  0/8

 

 

/etc/default/cpufrequtils

# WARNING: this file will be replaced on board support package (linux-root-...)
upgrade
ENABLE=true
MIN_SPEED=240000
MAX_SPEED=1200000
GOVERNOR=ondemand

Posted
56 minutes ago, StephenW said:

is it normal?


Yes.

Considering "All currently available OS images for H5 boards are experimental".  Not everything is working properly, but you can use them ...

Posted

No, I can't. e.g. if i run "sudo cpufreq-set -r -g performance" there's no change in /etc/default/cpufrequtils.

Yet I can change /etc/default/cpufrequtils directly. After reboot, it runs with the desired frequency. But still for ondemand, the CPU speed does not seemed to scale up/down according to the loads.

 

Posted
9 hours ago, Igor said:


Yes.

Considering "All currently available OS images for H5 boards are experimental".  Not everything is working properly, but you can use them ...

OK no problem, I understand. Thanks Igor.

 

What I'm trying to do is to lower the CPU clock and see if that would solve the instability problem (I posted in H3 section about using the OPi Zero 2+ with the TFT screen).

When I boot with armbian, I see the CPU's keeping at 1152Mhz. When I use the linux image provided by OPi,  it's at around 10xx Mhz and it goes up and down.

I'm thinking may be the static CPU cycle may have caused the unexpected reboots. I'll let you know the result.  

So far I put it at 408Mhz, Idle, and so far still running after 10 hours .. i will leave it on for another couple of days.

Posted

After leaving the system running at 960mHz for a couple of days there’re no more sudden reboots. Looks like the H5 does not want to always run at 1152mHz... I inspect the cpu stats and it appears the driver did attempt to step down to 480mhz . From the stat, it looks like the CPU did stepped down, but stepped up again in a very short while under the ondemand governor. And the cpu_cur_freq it’s always reported the top speed (i.e. 960mhz)

 

 

I notice the H5 CPU freq table is not the same as the stocked Ubuntu image from Sunxi. I can try to patch it but I have to be honest I am quite new to Linux kernel patching and developments. Yet I will try and see if I can modify the dtsi file and rebuild the kernel.

 

the image from orangepi is running in interactive governor, where armbian does not have it.

 

Yet I also notice sunxi have their own CPU

freq driver for the H5. the armbian driver is cpufreq-dt. I can try to change the driver and rebuild but I’m not sure if that would make the stepping working. 

 

Anyway let me know what I can try and test to get the armbian better with the H5

Posted

Which kernel versions are you using at the moment? linux-sunxi is only working on the mainlining of sunxi devices, legacy kernel stuff from the BSP is not supported by them...

Posted
On 3. 3. 2018 at 3:56 AM, StephenW said:

the image from orangepi is running in interactive governor, where armbian does not have it.


You are wasting time to compare all this. A modern kernel support for Allwinner is basically written from scratch (by a community) and DVFS part will be completely reworked I heard. There is no solution at the moment - you already find a workaround and that's it. A few months ago there was no DVFS, no video output, no ... and few months will pass that these things actually reach upstream kernel builds and become stable.

 

We don't support H5 since it's still labeled development. Supporting things in motion is not possible/stupid/extremely costly.

Posted
19 minutes ago, Igor said:


You are wasting time to compare all this. A modern kernel support for Allwinner is basically written from scratch (by a community) and DVFS part will be completely reworked I heard. There is no solution at the moment - you already find a workaround and that's it. A few months ago there was no DVFS, no video output, no ... and few months will pass that these things actually reach upstream kernel builds and become stable.

 

We don't support H5 since it's still labeled development. Supporting things in motion is not possible/stupid/extremely costly.

 

OK no problem, understand. I'll keep the clock running at 960mHz... Thank you

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines