edupv Posted February 22, 2017 Posted February 22, 2017 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. 1 Quote
znoxx Posted February 22, 2017 Posted February 22, 2017 @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 . 0 Quote
dekip Posted February 22, 2017 Posted February 22, 2017 Since my board is on it's way, and as i am new in all this, i would like to know what touch display (3.5-5 inches) would you recommend? Some points to tutorials would be nice. 0 Quote
tkaiser Posted February 23, 2017 Posted February 23, 2017 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 0 Quote
edupv Posted February 23, 2017 Posted February 23, 2017 @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:~# 0 Quote
KelLiN_BY Posted February 26, 2017 Posted February 26, 2017 Is the new github repository mali 450 may be usefull ? https://github.com/OrangePiLibra/OrangePi_GPU 0 Quote
zador.blood.stained Posted February 26, 2017 Posted February 26, 2017 Is the new github repository mali 450 may be usefull ? https://github.com/OrangePiLibra/OrangePi_GPU No No license Currently may be useful only on legacy kernel, which we don't work on 0 Quote
Remus Cursaru Posted March 6, 2017 Posted March 6, 2017 Thank you guys for all the effort put into this, you are awesome. Will it support one-wire protocol? At the moment I cannot find neither the w1-gpio/therm modules nor the /sys/bus/w1 directory. Or am I doing it wrong? 0 Quote
martinayotte Posted March 6, 2017 Posted March 6, 2017 In older 4.9.x H5 build, the W1 drivers were there. But they have been forgotten in 4.10.x, so I've added them few minutes ago and my build is on-going. So, you will be able to try it in next nightly builds. 0 Quote
deviant Posted March 11, 2017 Posted March 11, 2017 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. 0 Quote
martinayotte Posted March 11, 2017 Posted March 11, 2017 FDTI/CH341/PL2303 have been added for next mainline nightly build 2 Quote
Phillip Close Posted March 12, 2017 Posted March 12, 2017 I need to get my t230 dvb stick to work it needs the i2c_mux enable please can you help 0 Quote
martinayotte Posted March 13, 2017 Posted March 13, 2017 The CONFIG_I2C_MUX is already present. Maybe it requires something else ... 0 Quote
Phillip Close Posted March 13, 2017 Posted March 13, 2017 lsusb see the device but wont load the .fw files in lib\firmware sl2168 40 dmesg says config 1 interface 0 altsetting 0 bulk endpoint 0x86 has invalid maxpacket 188 please can anyone help 0 Quote
Phillip Close Posted March 13, 2017 Posted March 13, 2017 Yes .sl2168 40 .fw are in the lib/firmware folder. I cannot install v4l 0 Quote
pec Posted March 13, 2017 Posted March 13, 2017 DVB modules are not enabled in current kernel config. For t230 you need CONFIG_DVB_USB_CXUSB. 0 Quote
Phillip Close Posted March 13, 2017 Posted March 13, 2017 Oh damn it so how can I enabled it. Or is it just wait and see when it gets enable in a update 0 Quote
pec Posted March 15, 2017 Posted March 15, 2017 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. 0 Quote
Phillip Close Posted March 15, 2017 Posted March 15, 2017 Please could you send me a .img if possible. I have been trying for a week now all I can make it do is crash lol or a patch With thanks Phill 0 Quote
Phillip Close Posted March 20, 2017 Posted March 20, 2017 Ok I have done 3 version oh the kernel but sill no dvb support for the t230 dvb stick please tell me what to enable when using the tool in the document lol and my kernel seam to be 3.2 gig img lol 0 Quote
edupv Posted March 21, 2017 Posted March 21, 2017 22 hours ago, Phillip Close said: Ok I have done 3 version oh the kernel but sill no dvb support for the t230 dvb stick please tell me what to enable when using the tool in the document lol and my kernel seam to be 3.2 gig img lol Please try this : https://github.com/igorpecovnik/lib 0 Quote
Bruno George de Moraes Posted March 23, 2017 Posted March 23, 2017 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 0 Quote
hojnikb Posted March 24, 2017 Posted March 24, 2017 1.24V seems awfully low for h5@1.37Ghz. Did you check if that was actually the frequency, while testing ? in my experience, such high frequencies need forced cooling to stay below 75C 0 Quote
Bruno George de Moraes Posted March 24, 2017 Posted March 24, 2017 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 0 Quote
hojnikb Posted March 24, 2017 Posted March 24, 2017 try this with modded dts https://github.com/ehoutsma/StabilityTester 0 Quote
Bruno George de Moraes Posted March 26, 2017 Posted March 26, 2017 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 0 Quote
hojnikb Posted March 27, 2017 Posted March 27, 2017 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. 0 Quote
hojnikb Posted March 27, 2017 Posted March 27, 2017 Just FYI, if anyone uses PC2 as a web browsing device/kiosk , 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 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. 0 Quote
Recommended Posts
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.