Jump to content

Armbian for OrangePi PC2, AllWinner H5


Christos

Recommended Posts

But now according to armbian monitor cpu clock is almost always 1296 Mhz. Even if system load is 0.01. Is it normal ? As far as i remember system was auto downclocked without load.

 

Are you using the default schedutil governor ?

 

I am using my PC2 started from 170215 build, the behavior of schedutil governor was strange. It ramp up to 1296MHz when idle, but it went down to 480MHz under light load (e.g. apt-get update).  Sometimes, after some loading, it became more normal - More 480MHz and less 1296MHz.

 

Then, I changed the governor to ondemand. ondemand is "lazy" by default, and needs tuning to make it responsive :

	echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
	echo 50880 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

I am happy with the ondemand governor and have not tried schedutil again.

Link to comment
Share on other sites

@edupv, thanks.

 

Well, looks like "brand new" governor - schedutil is used and it somehow confuses me.

When I switch to "ondemand" or "conservative" the results are as expected.

 

Manual says: "This governor makes decisions based on the utilization data provided by the scheduler. It sets the CPU frequency to be proportional to the utilization/capacity ratio coming from the scheduler. If the utilization is frequency-invariant, the new frequency is also proportional to the maximum available frequency. If that is not the case, it is proportional to the current frequency of the CPU. The frequency tipping point is at utilization/capacity equal to 80% in both cases."

 

Sounds somehow like extraterrestrial language for me, so I'd better stick to some "old school" governors :).

Link to comment
Share on other sites

I am happy with the ondemand governor and have not tried schedutil again.

 

The purpose of Armbian team providing OS images with dev kernel was to enable users to provide valuable feedback ('contributing users'). One of the areas of interest is performance behaviour (DVFS and also cpufreq stuff). 'Ondemand' is considered broken by kernel guys, schedutil is an attempt to fix this. If for whatever reasons this somehow works strangely (on ARM? On ARM64? With latest kernel?) then this is worth investigation and a report upstream.

 

Unfortunately it seems with our dev kernel OS images we only attract a different kind of people ('consumer users') not interested in improving things but just let their cheap device work somehow :(

Link to comment
Share on other sites

@tkaiser

 

The situation happened in Armbian_5.26.170215_Orangepipc2_Ubuntu_xenial_dev_4.10.0.

 

I upgrade my system by apt-get everyday, so I think my system is uptoday now. Here is the result I just tested. My PC2 was idle during the test  :

root@orangepipc2:~# armbianmonitor -m     # <== using ondemand 
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
01:10:15:  480MHz  0.10   3%   1%   1%   0%   0%   0% 23.6°C
01:10:20:  480MHz  0.09   3%   1%   1%   0%   0%   0% 23.8°C
01:10:25:  480MHz  0.08   3%   1%   1%   0%   0%   0% 23.5°C
01:10:30:  480MHz  0.08   3%   1%   1%   0%   0%   0% 23.9°C
01:10:35:  480MHz  0.07   3%   1%   1%   0%   0%   0% 24.2°C
01:10:40:  480MHz  0.06   3%   1%   1%   0%   0%   0% 26.2°C
01:10:45:  480MHz  0.06   3%   1%   1%   0%   0%   0% 24.9°C
01:10:50:  480MHz  0.05   3%   1%   1%   0%   0%   0% 24.2°C
01:10:55:  480MHz  0.05   3%   1%   1%   0%   0%   0% 24.8°C
01:11:00:  480MHz  0.05   3%   1%   1%   0%   0%   0% 23.6°C^C
root@orangepipc2:~# echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
root@orangepipc2:~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
01:11:28: 1296MHz  0.03   2%   1%   1%   0%   0%   0% 28.0°C
01:11:33: 1296MHz  0.02   2%   1%   1%   0%   0%   0% 29.0°C
01:11:38: 1296MHz  0.02   2%   1%   1%   0%   0%   0% 29.0°C
01:11:43: 1296MHz  0.02   2%   1%   0%   0%   0%   0% 29.0°C
01:11:48: 1296MHz  0.02   2%   1%   0%   0%   0%   0% 29.1°C
01:11:53:  480MHz  0.02   2%   1%   0%   0%   0%   0% 24.8°C
01:11:58: 1296MHz  0.02   2%   1%   0%   0%   0%   0% 29.1°C
01:12:03: 1296MHz  0.01   2%   1%   0%   0%   0%   0% 30.0°C
01:12:08: 1296MHz  0.01   2%   1%   0%   0%   0%   0% 30.5°C
01:12:13: 1296MHz  0.01   2%   1%   0%   0%   0%   0% 30.5°C
01:12:18: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 28.9°C
01:12:23: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 31.8°C
01:12:28: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 31.3°C
01:12:33: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 31.6°C
01:12:38: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 31.0°C
01:12:43: 1296MHz  0.01   2%   0%   0%   0%   0%   0% 32.3°C
01:12:49: 1296MHz  0.00   2%   0%   0%   0%   0%   0% 30.6°C
01:12:54: 1296MHz  0.00   2%   0%   0%   0%   0%   0% 32.2°C^C
root@orangepipc2:~#
Link to comment
Share on other sites

Hi,

Today I change to armbian becaus the old ubuntu image from orangepi put me into some troubles.

 

I tried to get serial communication over USB. Somehow ftdi_sio is missing. Can you add this to a build?

Sorry I'm absolutly new to this.

 

Thanks for your great work.

Link to comment
Share on other sites

On 3/13/2017 at 10:15 PM, Phillip Close said:

Oh damn it so how can I enabled it.

Or is it just wait and see when it gets enable in a update

You can also compile linux kernel yourself (it is not that hard, see https://docs.armbian.com Developer Guide section), I can confirm that this DVB module is working fine with PC2.

Link to comment
Share on other sites

So still in the 5.25;

 

The included tool crash/freeze  if:  stress --vm 3

I think the above is related to these error logs in dmesg:

[  282.381142] mpv[1665]: unhandled level 0 translation fault (11) at 0xfeff9cff74d0, esr 0x92000004
[  306.562890] mpv[1617]: unhandled level 2 translation fault (11) at 0xaaaaecf81400, esr 0x92000006
[  708.407845] armbianmonitor[3698]: unhandled level 1 translation fault (11) at 0x10041d980, esr 0x82000005
[  713.432377] armbianmonitor[3705]: unhandled level 1 translation fault (11) at 0x10041d980, esr 0x82000005
[  860.847920] mpv[4425]: unhandled level 2 translation fault (11) at 0xaaaaf04fcfe8, esr 0x92000006
[ 1189.200090] armbianmonitor[6270]: unhandled level 1 translation fault (11) at 0x12839da90, esr 0x92000005
[ 1189.880690] mpv/ao[5422]: unhandled level 0 translation fault (11) at 0x00000009, esr 0x92000004

[  253.588471] BUG: Bad rss-counter state mm:ffff80003b80ce00 idx:1 val:2
[  253.595109] BUG: non-zero nr_ptes on freeing mm: 1
[  380.051367] stress[1203]: unhandled level 2 translation fault (11) at 0xffffa10ce0b4, esr 0x92000006
[  408.767189] mpv[2546]: unhandled level 2 translation fault (11) at 0xaaaae1c921dc, esr 0x92000006
[  431.082334] mpv[2713]: unhandled level 2 translation fault (11) at 0xfffffd84e2d5, esr 0x92000006
[  602.551225] mpv/ao[3497]: unhandled level 2 translation fault (11) at 0xaaaaac7b63d0, esr 0x92000006
[  814.051776] mpv[4892]: unhandled level 2 translation fault (11) at 0xaaaad8995250, esr 0x92000006
[  855.928167] mpv[5156]: unhandled level 2 translation fault (11) at 0xffff403ca297, esr 0x92000006
[  855.930359] mpv[5158]: unhandled level 2 translation fault (11) at 0xffffc0b4a2c6, esr 0x92000006
[  855.930366] mpv[5155]: unhandled level 2 translation fault (11) at 0xfffff23ca2ca, esr 0x92000006
Linux kernel comment: "If the address is in kernel space (>= TASK_SIZE), then we are probably faulting in the vmalloc() area."

Its is reproducible if i try to decode two 1080p files at the same time...   (one of the instances will crash)

 

NO cpu sleep:  cat  /sys/kernel/debug/suspend_stats  is empty.  Also confirmed by /sys/kernel/debug/opp/cpu#/OPP:*/ suspend = N

I will try to create a correct DTB structure for these based on the latest presentation in Linux Plumbers. 

 

I ve done a bit of undervolt testing with my board to add info about the quality of the fab.

for me the stabilityTest script failed to run because of excessive temps in a older image, so its is the motivation to try undervolt! For these i only used the included "stress tool",  mpv and tweaking of ambient temperature (sensitive to low temps: works at 30C cool it down to 20C and see it crashing).

Quote

240mhz @ 860mV  |  1368mhz @ 1240mV;    960mhz@1020mV is the most stable even running ok at 17C

Of course more testing is needed but  throttle kicks at 70C and a cannot go above 76C even without heatsink or fan!  Later will try the stability script again but the xhpl64 binary needs dependency;

 

H5_undervolt.dts

Link to comment
Share on other sites

Here, i dont have a Oscilloscope. But if that was the case were are the test points?    

Using openssl speed --multi 4 it completes all tests at 1440mhz@ 1270mV, (sudo cpufreq-info -w )  

at idle (0.7 load) brief worked at 1584mhz@1390mV

 

Any tips about how to confirm such results?

 

Also, the card registration error msg in dmesg went away as soon as i added the next-level-cache info on DT.

Quote

grep . /sys/devices/system/cpu/cpu*/cache/index*/*

 The above now is correctly populated.

H5_undervolt.dts

Link to comment
Share on other sites

So i had to increase  10 or 20mV (temps  >35C were also critical to how much residuals were left at each run of the script ), but the strange thing is that 1344mhz+ crash at 1.4v

  This reminds me of the i7 SIMD overclock drops , in which some bioses let you specify an two OPPs, and drop the GHz  when a simd instruction is used.    

Done testing stability:
Frequency: 120000	Voltage: 860000	 Success: 1	Result:        0.0048034
Frequency: 240000	Voltage: 870000	 Success: 1	Result:        0.0048034
Frequency: 480000	Voltage: 890000	 Success: 1	Result:        0.0048034
Frequency: 528000	Voltage: 890000	 Success: 1	Result:        0.0048034
Frequency: 648000	Voltage: 900000	 Success: 1	Result:        0.0048034
Frequency: 672000	Voltage: 910000	 Success: 1	Result:        0.0048034
Frequency: 720000	Voltage: 930000	 Success: 1	Result:        0.0048034
Frequency: 768000	Voltage: 950000	 Success: 1	Result:        0.0048034
Frequency: 792000	Voltage: 960000	 Success: 1	Result:        0.0048034
Frequency: 816000	Voltage: 970000	 Success: 1	Result:        0.0048034
Frequency: 864000	Voltage: 990000	 Success: 1	Result:        0.0048034
Frequency: 912000	Voltage: 1010000 Success: 1	Result:        0.0048034
Frequency: 936000	Voltage: 1020000 Success: 1	Result:        0.0048034
Frequency: 960000	Voltage: 1040000 Success: 1	Result:        0.0048034
Frequency: 1008000	Voltage: 1060000 Success: 1	Result:        0.0048034
Frequency: 1056000	Voltage: 1080000 Success: 1	Result:        0.0048034
Frequency: 1080000	Voltage: 1100000 Success: 1	Result:        0.0048034
Frequency: 1104000	Voltage: 1110000 Success: 1	Result:        0.0048034
Frequency: 1152000	Voltage: 1150000 Success: 1	Result:        0.0048034
Frequency: 1200000	Voltage: 1170000 Success: 1	Result:        0.0048034
Frequency: 1224000	Voltage: 1190000 Success: 1	Result:        0.0048034
Frequency: 1248000	Voltage: 1210000 Success: 1	Result:        0.0048034
Frequency: 1296000	Voltage: 1250000 Success: 1	Result:        0.0048034

OBS.:   some OPP were fluctuating based on too lower ambient temperature for example:

Frequency: 528000    Voltage: 890000    Success: 0    Result:        1.2494786
Frequency: 912000    Voltage: 1010000    Success: 0    Result:  1588658.6920996

but were never the same and increased mV doesnt matter.  so there much to discover and test;

This bench is nice but have some inplications and unexpected behaviors...

 

Later

Link to comment
Share on other sites

23 hours ago, Bruno George de Moraes said:

So i had to increase  10 or 20mV (temps  >35C were also critical to how much residuals were left at each run of the script ), but the strange thing is that 1344mhz+ crash at 1.4v

  This reminds me of the i7 SIMD overclock drops , in which some bioses let you specify an two OPPs, and drop the GHz  when a simd instruction is used.    


Done testing stability:
Frequency: 120000	Voltage: 860000	 Success: 1	Result:        0.0048034
Frequency: 240000	Voltage: 870000	 Success: 1	Result:        0.0048034
Frequency: 480000	Voltage: 890000	 Success: 1	Result:        0.0048034
Frequency: 528000	Voltage: 890000	 Success: 1	Result:        0.0048034
Frequency: 648000	Voltage: 900000	 Success: 1	Result:        0.0048034
Frequency: 672000	Voltage: 910000	 Success: 1	Result:        0.0048034
Frequency: 720000	Voltage: 930000	 Success: 1	Result:        0.0048034
Frequency: 768000	Voltage: 950000	 Success: 1	Result:        0.0048034
Frequency: 792000	Voltage: 960000	 Success: 1	Result:        0.0048034
Frequency: 816000	Voltage: 970000	 Success: 1	Result:        0.0048034
Frequency: 864000	Voltage: 990000	 Success: 1	Result:        0.0048034
Frequency: 912000	Voltage: 1010000 Success: 1	Result:        0.0048034
Frequency: 936000	Voltage: 1020000 Success: 1	Result:        0.0048034
Frequency: 960000	Voltage: 1040000 Success: 1	Result:        0.0048034
Frequency: 1008000	Voltage: 1060000 Success: 1	Result:        0.0048034
Frequency: 1056000	Voltage: 1080000 Success: 1	Result:        0.0048034
Frequency: 1080000	Voltage: 1100000 Success: 1	Result:        0.0048034
Frequency: 1104000	Voltage: 1110000 Success: 1	Result:        0.0048034
Frequency: 1152000	Voltage: 1150000 Success: 1	Result:        0.0048034
Frequency: 1200000	Voltage: 1170000 Success: 1	Result:        0.0048034
Frequency: 1224000	Voltage: 1190000 Success: 1	Result:        0.0048034
Frequency: 1248000	Voltage: 1210000 Success: 1	Result:        0.0048034
Frequency: 1296000	Voltage: 1250000 Success: 1	Result:        0.0048034

OBS.:   some OPP were fluctuating based on too lower ambient temperature for example:

Frequency: 528000    Voltage: 890000    Success: 0    Result:        1.2494786
Frequency: 912000    Voltage: 1010000    Success: 0    Result:  1588658.6920996

but were never the same and increased mV doesnt matter.  so there much to discover and test;

This bench is nice but have some inplications and unexpected behaviors...

 

Later


 

If 1.3G is stable at 1.25V, thats quite a bit of reduction. Could help with throttling.

 

How does one change this device tree file ? Any converting necessary or is just a text file ? I might give this a shot myself and do some power testing.

Link to comment
Share on other sites

Just FYI, if anyone uses PC2 as a web browsing device/kiosk :rolleyes:, i'd recommend using 32 bit armhf chromium instead of native arm64 one. Why you might ask ?

 

Well, for starters, armhf version seems to be much easier on the system ram (i'd regularly fill almost all of the 1GB ram just with a few tabs open).

Another reason is that armhf seems to be more regularly updated (v56, while arm64 is stuck at v53). Bonus point is also Octane V2 finishes without freezing :D

 

How you might go about this ? Well first you need to uninstall previous package with this

sudo apt-get remove chromium-browser

Then install armhf version

sudo apt-get install chromium-browser:armhf

 

When the package is installed, you need to do one final step. Add this to launch options


 

chromium-browser --no-sandbox --disable-infobars%U

For some reason, having sandbox enabled makes chromium crash when displaying anything.

 

I suspect security of the browser is compromised with the last step somewhat, so use with caution.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines