@lex

thermal-zones { cpu_thermal: cpu_thermal { polling-delay-passive = <330>; polling-delay = <1000>; thermal-sensors = <&ths 0>; trips { cpu_hot_trip: cpu-warm { temperature = <75000>; hysteresis = <2000>; type = "passive"; }; cpu_very_hot_trip: cpu-very-hot { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; cooling-maps { cpu-warm-limit { trip = <&cpu_hot_trip>; cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; }; }; }; };

Yes. Try to add a gw to ppp0, something like: route add default gw {IP-ADDRESS} {INTERFACE-NAME} Not sure is the best way ( i am not sysadmin), it should be automagically done by some package. route add default gw 10.64.64.64 ppp0

route can reveal something, post the result of route from duo and from rpi.

I would suggest you work on the legacy kernel 3.4.112 , that would be a boost. Any plans on that?

Not that i know of, I don't think there is a need to port gc2035 when ov5640 is a better choice. IMHO. Maybe wens have something working.

OrangePi One Plus BSP 4.9, kernel 4.9.56 stock for analisys. Here is DRAM initialization in use (hope is what you meant): [271]PMU: AXP806 [275]set pll start [278]set pll end [279]rtc[0] value = 0x00000000 [282]rtc[1] value = 0x00000000 [285]rtc[2] value = 0x00000000 [288]rtc[3] value = 0x00000000 [292]rtc[4] value = 0x00000000 [295]rtc[5] value = 0x00000000 [298]DRAM VERSION IS V2_5 [300]PMU:Set DDR Vol 1200mV OK. [304]PMU:Set DDR Vol 1200mV OK. [314]BYTE0 GATE ERRO IS = 00000002 [318]BYTE1 GATE ERRO IS = 00000002 [321]BYTE2 GATE ERRO IS = 00000002 [324]BYTE3 GATE ERRO IS = 00000002 [336]DRAM CLK =744 MHZ [338]DRAM Type =7 (3:DDR3,4:DDR4,6:LPDDR2,7:LPDDR3) [343]DRAM zq value: 003b3bfb [350]IPRD=006f006e--PGCR0=00000f5d--PLL=b0003d00 [354]DRAM SIZE =1024 M,para1 = 000030fa,para2 = 04000000 [366]DRAM simple test OK. [369]dram size =1024 tinymembench, running first time with interactive governor: CPU: Running subsequent tinymembench with performance governor: CPU: Things you should consider in your analysis that could favor some results or not. * axp806 not detected by kernel [ 0.431724] [axp806] chip id not detect 0xff ! [ 1.496996] input: axp80x-powerkey as /devices/platform/soc/pmu0/axp80x-powerkey/input/input0 [ 4.925539] axp80x_aldo1: unsupportable voltage range: 858992688-3300000uV * eth not functional [ 0.816207] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:csi0 [ 0.824909] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdc0 [ 0.833599] sun50iw6p1-pinctrl pio: expect_func as:gmac0, but muxsel(5) is func:mdio0 [ 0.843450] gmac-power2: NULL [ 11.600421] libphy: gmac0: probed And the usual: I am pretty sure it runs at 1.8 GHz: CPU1 freq : 1800 MHz CPU2 freq : 1800 MHz CPU3 freq : 1800 MHz CPU4 freq : 1800 MHz CPU count : 4 Governor : performance SOC Temp : 55 C Next time i get results from 3.10...

I am running @Icenowy kernel, 1.5 GHz, 3.10.65 with some minor modification and 4.4.y 4.9.y without ethernet and axp805/6 not recognized . I will run tinymembench possibly tomoorow (lack of time)...

You should ensure: a) Your sensor has the pins 180 reversed. discussed at the beginning of this thread, b) twi2 is disabled, so the board can talk to the sensor via CSI, c) the correct pin enabled for your u-boot version, read this thread, if everything else fails you should try with Android to make sure your sensor is still working, maybe you try with another sensor. Good luck

FYI, Orange Pi One Plus ethernet Gbit is already working on mainline kernel. Thanks to Jagan Teki and Icenowy for their work! ./iperf3 -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 [ 4] local 192.168.254.253 port 32808 connected to 192.168.254.100 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 112 MBytes 942 Mbits/sec 0 112 KBytes [ 4] 1.00-2.00 sec 112 MBytes 941 Mbits/sec 0 119 KBytes [ 4] 2.00-3.00 sec 112 MBytes 941 Mbits/sec 0 119 KBytes [ 4] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 119 KBytes [ 4] 4.00-5.00 sec 112 MBytes 941 Mbits/sec 0 119 KBytes [ 4] 5.00-6.00 sec 112 MBytes 941 Mbits/sec 0 119 KBytes [ 4] 6.00-7.00 sec 112 MBytes 942 Mbits/sec 0 202 KBytes [ 4] 7.00-8.00 sec 112 MBytes 942 Mbits/sec 0 202 KBytes [ 4] 8.00-9.00 sec 112 MBytes 941 Mbits/sec 0 202 KBytes [ 4] 9.00-10.00 sec 112 MBytes 942 Mbits/sec 0 202 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver iperf Done. ./iperf3 -R -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 Reverse mode, remote host 192.168.254.100 is sending [ 4] local 192.168.254.253 port 32816 connected to 192.168.254.100 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 107 MBytes 895 Mbits/sec [ 4] 1.00-2.00 sec 107 MBytes 896 Mbits/sec [ 4] 2.00-3.00 sec 106 MBytes 892 Mbits/sec [ 4] 3.00-4.00 sec 106 MBytes 890 Mbits/sec [ 4] 4.00-5.00 sec 106 MBytes 893 Mbits/sec [ 4] 5.00-6.00 sec 107 MBytes 894 Mbits/sec [ 4] 6.00-7.00 sec 106 MBytes 889 Mbits/sec [ 4] 7.00-8.00 sec 107 MBytes 894 Mbits/sec [ 4] 8.00-9.00 sec 106 MBytes 891 Mbits/sec [ 4] 9.00-10.00 sec 106 MBytes 892 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.04 GBytes 893 Mbits/sec 4257 sender [ 4] 0.00-10.00 sec 1.04 GBytes 893 Mbits/sec receiver iperf Done.

If you don't mind, i throw some numbers here grabbed from Opi One Plus so we all can compare to PineH64. I am interested in seeing how Opi stacks up against PineH64 and how it could be improved. This is @Icenowy kernel. No patch applied to save my only one Opi H6. I forgot or missed how to enable Crypto, still learning how to turn this little beast ON... Maybe @Igor or @zador.blood.stained has a better kernel config. There is still some timitations on Opi, that's what i could get for the momment. 7z b sysbench: cpu-freq: tinymembench

edit: sorry, should be SPI.

Please, check some post above about u-boot or sunxi-pio to set manually the pin. Check if you have /dev/video0.

Realtek specification: * 150Mbps receive PHY rate and 150Mbps transmit PHY rate using 40MHz bandwidth That's what you mean by HT40 then. The latency is very low, i feel like i am using FastEthernet.

Yes, no output. Some info about the driver: [ 5.022350] sunxi-wlan wlan: request pincrtl handle for device [wlan] failed [ 11.183079] RTL871X: module init start [ 11.193853] RTL871X: rtl8189es v4.3.18.2_17395.20160422 [ 11.233801] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=34:c3:d2:13:f1:f0 [ 11.261003] RTL871X: rtw_ndev_init(wlan1) if2 mac_addr=36:c3:d2:13:f1:f0 [ 11.281960] RTL871X: module init ret=0 [ 17.910300] ==> rtl8188e_iol_efuse_patch [ 42.961808] RTL871X: rtw_set_802_11_connect(wlan0) fw_state=0x00000008 [ 42.982709] RTL871X: start auth [ 42.984750] RTL871X: auth success, start assoc [ 42.990625] RTL871X: rtw_cfg80211_indicate_connect(wlan0) BSS not found !! [ 42.990665] RTL871X: assoc success [ 43.088327] RTL871X: recv eapol packet [ 43.091242] RTL871X: send eapol packet [ 43.096784] RTL871X: recv eapol packet [ 43.097412] RTL871X: send eapol packet [ 43.098075] RTL871X: set pairwise key camid:4, addr:18:d6:c7:35:eb:8f, kid:0, type:AES [ 43.099175] RTL871X: set group key camid:5, addr:18:d6:c7:35:eb:8f, kid:2, type:TKIP using kernel.org iw commands: Connected to 18:d6:c7:35:eb:8f (on wlan0) SSID: foxy freq: 2462 signal: -53 dBm tx bitrate: 150.0 MBit/s Wiphy phy1 max # scan SSIDs: 9 max scan IEs length: 2304 bytes Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * P2P-client * P2P-GO Band 1: Capabilities: 0x1962 HT20/HT40 Static SM Power Save RX HT20 SGI RX HT40 SGI RX STBC 1-stream Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 16 usec (0x07) HT TX/RX MCS rate indexes supported: 0-7 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps * 5.5 Mbps * 11.0 Mbps * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) (no IR) * 2472 MHz [13] (20.0 dBm) (no IR) * 2484 MHz [14] (disabled) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * set_bss * join_ibss * set_pmksa * del_pmksa * flush_pmksa * remain_on_channel * frame * set_channel * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 WoWLAN support: * wake up on anything (device continues operating normally) software interface modes (can always be added): interface combinations are not supported Device supports scan flush. Wiphy phy0 max # scan SSIDs: 9 max scan IEs length: 2304 bytes Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) Available Antennas: TX 0 RX 0 Supported interface modes: * IBSS * managed * AP * P2P-client * P2P-GO Band 1: Capabilities: 0x1962 HT20/HT40 Static SM Power Save RX HT20 SGI RX HT40 SGI RX STBC 1-stream Max AMSDU length: 7935 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 16 usec (0x07) HT TX/RX MCS rate indexes supported: 0-7 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps * 5.5 Mbps * 11.0 Mbps * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) (no IR) * 2472 MHz [13] (20.0 dBm) (no IR) * 2484 MHz [14] (disabled) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * set_bss * join_ibss * set_pmksa * del_pmksa * flush_pmksa * remain_on_channel * frame * set_channel * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 WoWLAN support: * wake up on anything (device continues operating normally) software interface modes (can always be added): interface combinations are not supported Device supports scan flush. Yes, noticed already, dropped ~20%

I just came around with some theoretical wireless speeds (source: https://www.speedguide.net) 802.11b - 11 Mbps (2.4GHz) 802.11a - 54 Mbps (5 GHz) 802.11g - 54 Mbps (2.4GHz) 802.11n - 600 Mbps (2.4GHz and 5 GHz) - 150Mbps typical for network adapters, 300Mbps, 450Mbps, and 600Mbps speeds when bonding channels with some routers 802.11ac - 1300+Mbps (5 GHz) - newer standard that uses wider channels, QAM and spatial streams for higher throughput

Output: with another round of iperf3, 3M from AP, just some equipment turned on around. Small antenna * added info screen ubuntu@nanopi-a64:~/iperf/iperf/src$ iw wlan0 info Interface wlan0 ifindex 9 wdev 0x1 addr 34:c3:d2:13:f1:f0 ssid foxy type managed wiphy 0 ubuntu@nanopi-a64:~/iperf/iperf/src$ ubuntu@nanopi-a64:~/iperf/iperf/src$ ./iperf3 -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 [ 5] local 192.168.254.101 port 52448 connected to 192.168.254.100 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 5.82 MBytes 48.9 Mbits/sec 0 136 KBytes [ 5] 1.00-2.00 sec 8.10 MBytes 68.0 Mbits/sec 0 335 KBytes [ 5] 2.00-3.00 sec 10.9 MBytes 91.2 Mbits/sec 0 752 KBytes [ 5] 3.00-4.00 sec 10.5 MBytes 87.9 Mbits/sec 0 919 KBytes [ 5] 4.00-5.00 sec 10.4 MBytes 87.5 Mbits/sec 0 1.11 MBytes [ 5] 5.00-6.00 sec 10.1 MBytes 84.4 Mbits/sec 0 1.14 MBytes [ 5] 6.00-7.00 sec 10.5 MBytes 88.2 Mbits/sec 0 1.17 MBytes [ 5] 7.00-8.00 sec 10.6 MBytes 88.9 Mbits/sec 0 1.17 MBytes [ 5] 8.00-9.00 sec 11.2 MBytes 93.9 Mbits/sec 0 1.17 MBytes [ 5] 9.00-10.00 sec 10.1 MBytes 84.4 Mbits/sec 0 1.17 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 98.2 MBytes 82.3 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 98.1 MBytes 82.3 Mbits/sec receiver iperf Done. ubuntu@nanopi-a64:~/iperf/iperf/src$ ./iperf3 -R -c 192.168.254.100 Connecting to host 192.168.254.100, port 5201 Reverse mode, remote host 192.168.254.100 is sending [ 5] local 192.168.254.101 port 52452 connected to 192.168.254.100 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 5.80 MBytes 48.7 Mbits/sec [ 5] 1.00-2.00 sec 6.38 MBytes 53.6 Mbits/sec [ 5] 2.00-3.00 sec 6.75 MBytes 56.6 Mbits/sec [ 5] 3.00-4.00 sec 7.04 MBytes 59.0 Mbits/sec [ 5] 4.00-5.00 sec 7.05 MBytes 59.1 Mbits/sec [ 5] 5.00-6.00 sec 6.74 MBytes 56.5 Mbits/sec [ 5] 6.00-7.00 sec 6.68 MBytes 56.0 Mbits/sec [ 5] 7.00-8.00 sec 7.08 MBytes 59.4 Mbits/sec [ 5] 8.00-9.00 sec 7.34 MBytes 61.6 Mbits/sec [ 5] 9.00-10.00 sec 7.26 MBytes 60.9 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 69.0 MBytes 57.9 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 68.1 MBytes 57.1 Mbits/sec receiver iperf Done. ubuntu@nanopi-a64:~/iperf/iperf/src$ iwconfig gre0 no wireless extensions. lo no wireless extensions. wlan1 no wireless extensions. ifb1 no wireless extensions. wlan0 no wireless extensions. ifb0 no wireless extensions. bond0 no wireless extensions. tunl0 no wireless extensions. gretap0 no wireless extensions. eth0 no wireless extensions. ubuntu@nanopi-a64:~/iperf/iperf/src$ ifconfig eth0 Link encap:Ethernet HWaddr 36:c9:e3:f1:b8:05 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:172 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:172 errors:0 dropped:0 overruns:0 frame:0 TX packets:172 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:12678 (12.6 KB) TX bytes:12678 (12.6 KB) wlan0 Link encap:Ethernet HWaddr 34:c3:d2:13:f1:f0 inet addr:192.168.254.101 Bcast:192.168.255.255 Mask:255.255.0.0 inet6 addr: fe80::9038:9be2:fbab:3b4b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:219375 errors:0 dropped:1678 overruns:0 frame:0 TX packets:217636 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:235441182 (235.4 MB) TX bytes:228918541 (228.9 MB) wlan1 Link encap:Ethernet HWaddr 36:c3:d2:13:f1:f0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:45 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) ubuntu@nanopi-a64:~/iperf/iperf/src$

Sorry, moved to the wifi thread..

This is already working on 4.17.3. The question is what is "right way" . I think is necessary to measure the CPU voltage point for each CPU at peak times. Here is the 7z b after uptime for 22:30:00: 7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=C,Utf16=off,HugeFiles=on,64 bits,4 CPUs LE) LE CPU Freq: 794 1365 1363 1365 1365 1364 1365 1364 1364 RAM size: 1999 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 2113 328 626 2056 | 57763 395 1248 4928 23: 2089 331 643 2129 | 54905 392 1212 4751 24: 2056 332 667 2211 | 48069 356 1185 4220 25: 2009 331 692 2294 | 49941 390 1140 4445 ---------------------------------- | ------------------------------ Avr: 331 657 2172 | 383 1196 4586 Tot: 357 927 3379 Screenshot before the test (idle.png) Screenshot during the test (7zb.png ) Screenshot after the test (idle2.png) During the test: Every 2.0s: ../h5-monitor.sh nanopi-k1-plus: Sat Jun 30 21:05:16 2018 CPU1 freq : 1248 MHz CPU2 freq : 1248 MHz CPU3 freq : 1248 MHz CPU4 freq : 1248 MHz CPU5 count : 4 Governor : ondemand SOC Temp : 66 C Idle after the test: Every 2.0s: ../h5-monitor.sh nanopi-k1-plus: Sat Jun 30 21:12:23 2018 CPU1 freq : 648 MHz CPU2 freq : 648 MHz CPU3 freq : 936 MHz CPU4 freq : 1008 MHz CPU count : 4 Governor : ondemand SOC Temp : 38 C For whatever reason reading CPU freq in straight C always get the peak freq.

It not a trivial thing but there it is:

I mean what tests you would do in order to make sure DVFS is indeed working, think of the any actual board that is supposed to have DVFS working.

How do you test it to make sure it is working as expected?

Maxime has fixed the driver, but that is a near miss, we need a proper mali450 blob version. I have mali450 r5p1 (600), i think maybe the amlogic blob r7p0 (800 or 900?) could work and i don't have any to test, otherwise, you get: ERROR in Mali driver: * Device driver API mismatch * Device driver API version: 900 * User space API version: 600 Error: eglInitialise failed!

with that configuration, you should have sun6i_csi as a module, when this module loads it creates the device node /dev/video0 but only if you have the end points for the correct sensor. Igor's patch is for ov5640 if you are trying to use gc2035 you need that driver. I think there is no gc2035 driver for mainline yet. If you have ov5640 then check if sun61_csi was built as a module and try to load it and check dmesg for some messages. * Update: And if you have the correct DT node you will not need to load the driver with modprobe, it should be loaded automagically on boot

Ok, Laurent pointed to your malii node for H5 but still same error: soc { mali: gpu@1e80000 { compatible = "allwinner,sun50i-h5-mali", "arm,mali-400"; reg = <0x01e80000 0x30000>; interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "gp", "gpmmu", "pmu", "pp", "pp0", "ppmmu0", "pp1", "ppmmu1", "pp2", "ppmmu2", "pp3", "ppmmu3"; clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>; clock-names = "bus", "core"; resets = <&ccu RST_BUS_GPU>; assigned-clocks = <&ccu CLK_GPU>; assigned-clock-rates = <384000000>; }; }; Maxime code does not have compatible "arm,mali-450" , then i changed it to be able to load mali.ko. Do you have mali working for H5? Or you have our own device driver instead of Maxime driver?

My try with mainline kernel 4.17.3 , mali DT bind seems wrong: [ 7.715811] mali: loading out-of-tree module taints kernel. [ 7.736417] Allwinner sunXi mali glue initialized [ 7.888305] Mali: ERR: /arm/ubuntu/h5/mainline/sunxi-mali/r8p1/src/devicedrv/mali/common/mali_pp.c [ 7.888314] mali_pp_reset_wait() 269 [ 7.888317] Mali PP: Failed to reset core Mali_PP0, rawstat: 0x00000000 [ 7.888330] Mali: ERR: /arm/ubuntu/h5/mainline/sunxi-mali/r8p1/src/devicedrv/mali/common/mali_kernel_core.c [ 7.888332] mali_parse_product_info() 178 [ 7.888399] Mali: ERR: /arm/ubuntu/h5/mainline/sunxi-mali/r8p1/src/devicedrv/mali/linux/mali_kernel_linux.c [ 7.888401] mali_probe() 606 [ 7.888403] mali_probe(): Failed to initialize Mali device driver. [ 7.888413] Mali: ERR: /arm/ubuntu/h5/mainline/sunxi-mali/r8p1/src/devicedrv/mali/linux/mali_devfreq.c [ 7.888415] mali_devfreq_term() 309 [ 7.888447] mali-utgard: probe of mali-utgard.0 failed with error -14 [ 7.888502] Mali: [ 7.888504] Mali device driver loaded I used the same node as H3: soc { mali: gpu@1c40000 { compatible = "allwinner,sun8i-h3-mali", "arm,mali-400"; reg = <0x01c40000 0x10000>; interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "gp", "gpmmu", "pp0", "ppmmu0", "pp1", "ppmmu1", "pmu"; clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>; clock-names = "bus", "core"; resets = <&ccu RST_BUS_GPU>; assigned-clocks = <&ccu CLK_GPU>; assigned-clock-rates = <384000000>; }; }; Any thoughts / ideas?