dolphs

First attempt (5.5-rc2), thanks to @megi who added rc2 to the 5.5-branch This build resulted in compile errors at once, which was to be expected. Just reporting here in case DEV will be switched to 5.5 this month. The log attached holds "duplicate_label" as "well duplicate_node_names"-errors. compilation.log

check 1/ kernel settings, eg: net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 87380 16777216 net.ipv4.tcp_fastopen = 3 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_slow_start_after_idle = 0 net.ipv4.tcp_timestamps = 0 2/ openvpn settings, eg; sndbuf 393216 rcvbuf 393216 push "sndbuf 393216" push "rcvbuf 393216" comp-lzo no #No need for streaming fast-io #Optimize I/O writes tls-version-min 1.2 remote-cert-tls client cipher AES-128-CBC ncp-disable auth SHA256 auth-nocache both ends have h5 (neo2 lts) currently and get upload/download of >100Mbit over VPN tunnel BTW kernel 5.3.9 shows on this board lower values so you should easily get 100Mbit openssl speed -evp aes-128-cbc -elapsed :~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 12715522 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 10201155 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 5342908 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1919464 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 274635 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 138772 aes-128-cbc's in 3.00s OpenSSL 1.1.1a 20 Nov 2018 built on: Thu Nov 22 18:40:54 2018 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-d3BJKw/openssl-1.1.1a=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 67816.12k 217624.64k 455928.15k 655177.05k 749936.64k 757880.15k

agreed, was just following the Jira stories and noticed AR-86 is not fully solved, just wanted to report back and that is it. So I do not want to put any rush on this, but at least we know now it is not fully solved yet. As said once I see either branch or kernel being updated will spin up another test drive. cheers for your efforts as you know it is appreciated!

in which I can contribute to test, as I owe the "orangepioneplus" ( pihole and ovpn server ) as well a spare, so excellent for testing purposes Yet as we unfortunately can see it is not showing 1,8 which I reported also 5 December: root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.4.2-sunxi64 System load: 0.27 0.24 0.10 Up time: 2 min Memory usage: 7 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 4% of 15G root@orangepioneplus:~# cpufreq-info |grep cpufreq cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) driver: cpufreq-dt available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil cpufreq stats: 480 MHz:91.69%, 720 MHz:0.53%, 816 MHz:0.02%, 888 MHz:0.25%, 1.08 GHz:0.28%, 1.32 GHz:0.48%, 1.49 GHz:6.74% (147) Will give it another shot once @megi has 5.4.3 incorporated in orangepi-5.4 branch, both default and with the " Allwinner nvmem based SUN50I CPUFreq " driver

noticed current dev build ( default kernel ) takes still 5.4.2, would like to try 5.4.3 to see if the this generic driver takes clock speedback to 1,8GHz ( currently 1.5 ) on the orangepioneplus. Not sure if the newer driver ( Alwinner CPUFreq ) is working now, but in 5.4.3 kernel updates has been made to the Generic driver as far I read the ChangeLogs. imho AR-86 is not closed yet, it works with a workaround unless it has been confirmed the Generic driver is the one to use ( though it should be the SUN50I CPUFreq driver imho? )

While 5.4.y is not in ( sunxi64_common.inc ) current yet, at this time of writing I like to explore " KERNELBRANCH="branch:orange-pi-5.5" ". Except for just updating to this branch, I noticed it is just too early as megous github branch is not prepared yet for 5.5-RC1. I am curious to see if any of these have been applied already and what new fun stuff needs to be considered in the kernel .config

@yoq - thanks for this , currently have an OPiZero LTS on its way , perhaps following link is interesting material too rgd iwd

Still exploring kernel 5.4, little bit out of scope as I am tuning the orangepioneplus board to my needs ( .config ) and no need for WiFi or Bluetooth Thus how to disable following wifi drivers that are added to the kernel ( as well wireguard ), [ o.k. ] Adding [ WireGuard tag:0.0.20190702 ] [ o.k. ] Checking git sources [ wireguard 0.0.20190702 ] [ .... ] Up to date [ o.k. ] Patching WireGuard [ Applying workaround for headers compilation ] [ o.k. ] Adding [ Wireless drivers for Realtek 8811, 8812, 8814 and 8821 chipsets branch:v5.2.20 ] [ o.k. ] Checking git sources [ rtl8812au v5.2.20 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 8188EU 8188EUS and 8188ETV chipsets branch:v5.3.9 ] [ o.k. ] Checking git sources [ rtl8188eu v5.3.9 ] [ .... ] Up to date [ o.k. ] Adding [ Wireless drivers for Realtek 88x2bu chipsets branch:master ] [ o.k. ] Checking git sources [ rtl88x2bu master ] Did read it somewhere but I forgot, one to guide me please? At least it is not here unless I am overlooking stuff TiA!

Actually it is interesting finding these under " CPU Frequency scaling " kernel config options <M> Generic DT based cpufreq driver <M> Allwinner nvmem based SUN50I CPUFreq driver This last option should " add the nvmem based CPUFreq driver for Allwinner dule capable h6 SoC. ", thus also for the orangepioneplus imho Wonder if this is a driver issue in current kernel and if this has been fixed meanwhile in 5.4.2 ? The first driver gives result as indicated 27 Nov already, the " sun50i-cpufreq-nvmem " fails on this board so far....

try here though board is not yet listed, perhaps can be based though on "orangepi-rk3399" dev kernel ( 5.4.x )

Are you using kernel 5.3 by any chance? seems to be related to this topic

we're talking about the OPi Zero LTS here? Could you try kernel 5.4.x instead of 5.3.x please ? [ ./compile.sh BOARD=orangepizero BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ]

WIP - similar here and has been issued to Jira AR-86 If you open .config ( update KERNEL ), this part needs to be updated: * * CPU frequency scaling drivers * Generic DT based cpufreq driver (CPUFREQ_DT) [M/n/y/?] m Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) [N/m/y/?] (NEW) y SCPI based CPUfreq driver (ARM_SCPI_CPUFREQ) [M/n/y/?] m SCMI based CPUfreq driver (ARM_SCMI_CPUFREQ) [N/m/y/?] n CPU frequency scaling driver for Freescale QorIQ SoCs (QORIQ_CPUFREQ) [N/m/y/?] n Sadly that brings partly joy as 1,5GHz is currently max speed

@megi lovely, cheers for that - fresh off the presses: "Armbian_19.11.3_Orangepioneplus_buster_dev_5.4.1_minimal.img" ( default .config settings )

@megi - Hi megi - Would it be possible to bump ( tag ) orange-pi-5.4 to 5.4.1 please instead of 5-4.0RC8? thanks for your time

- [x] HDMI -> no need ( ssh and http enough ) Those caught my interest: - [v] better voltage regulation -> that was my hunch but trying to verify how H2+ is nowadays ( kernel 5.3/ 5.4 ) - [v] full H3 instead of H2+ - [v] no broken by-design WiFi chip -> OPi One does not have WiFi imho Zero LTS hopefully has no longer that "heat" problem , LTS states: " low running temperature and low power consumption. ", but I dunno. Though I was not aware of crappy WiFi (xr819?), is mandatory though as I dont have cables in the meter cupboard, unless I'd use a HomePlug Except for that have older H5 ( first Neo2 series ), but without WiFi and H2+ was the missing piece I did not have stocked ;-), thus consider this more like a little "funny" project and might swap the board sooner or later, only stuff on there would be armbian ( buster ) with domoticz thanks!

Can one verify with kernel 5.4 how things go in terms of temperature, please? I'm about to go ahead an purchase one ( see also here ), but not sure if that would resist without heatsink in my meter cupboard ... cheers

How are we doing at this moment, referring to the newer OPi Zero LTS It states " low running temperature and low power consumption. ", but ... ... ? Anyway my goal is to run domoticz, which will be connected to my smart meter in the meter cupboard

ta! , uhm right, I just quickly kicked off another build with " KERNEL_CONFIGURE=yes " and except many new features not configured yet I found these disabled: "PSCI CPU idle Driver (ARM_PSCI_CPUIDLE) [N/y/?] (NEW)" , "Allwinner nvmem based SUN50I CPUFreq driver (ARM_ALLWINNER_SUN50I_CPUFREQ_NVMEM) [N/m/y/?] (NEW) ", Optional and out of this scope, but nice have "exFAT fs support (EXFAT_FS) [N/m/y/?] (NEW) ", Set the last two to enabled [Y] and will compile it, once back home I can flash and see what happened ... Thus basically when new default ".config' is ready for commit, let's not forget to include these please ( and many others I missed out at quick glance ) . thanks UPDATE1: 1,5GHz currently max? [ driver: cpufreq-dt ] <snip snip> analyzing CPU 3: 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: 244 us. hardware limits: 480 MHz - 1.49 GHz available frequency steps: 480 MHz, 720 MHz, 816 MHz, 888 MHz, 1.08 GHz, 1.32 GHz, 1.49 GHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 480 MHz and 1.49 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 480 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:67.14%, 720 MHz:1.34%, 816 MHz:0.01%, 888 MHz:0.05%, 1.08 GHz:0.15%, 1.32 GHz:0.08%, 1.49 GHz:31.23% (84) UPDATE2: Checked /etc/default/cpufrequtils which shows ( as expected MAX_SPEED=1810000 ): ENABLE=true MIN_SPEED=480000 MAX_SPEED=1810000 GOVERNOR=ondemand But is it required to enable a flag to " /boot/armbianEnv.txt "in order to get 1.81Ghz back? I do recall, with NEO2 v1.1 board, in past something similar happened and it was needed to add the option " overlays " which is in this version currently missing: root@orangepioneplus:~# cat /boot/armbianEnv.txt verbosity=1 console=both overlay_prefix=sun50i-h6 rootdev=UUID=d1e21321-c4f1-407b-9903-d825f76d9e25 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Files listed in overlays rgd H6 ( for NEO2 the option is "sun50i-h5-cpu-clock-1.3GHz-1.3v.dtbo" ): root@orangepioneplus:/boot/dtb/allwinner/overlay# ls -la *h6* -rw-r--r-- 1 root root 4161 Nov 27 16:06 sun50i-h6-fixup.scr -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c0.dtbo -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c1.dtbo -rw-r--r-- 1 root root 374 Nov 27 16:06 sun50i-h6-i2c2.dtbo -rw-r--r-- 1 root root 268 Nov 27 16:06 sun50i-h6-ruart.dtbo -rw-r--r-- 1 root root 1177 Nov 27 16:06 sun50i-h6-spi-add-cs1.dtbo -rw-r--r-- 1 root root 804 Nov 27 16:06 sun50i-h6-spi-jedec-nor.dtbo -rw-r--r-- 1 root root 645 Nov 27 16:06 sun50i-h6-spi-spidev1.dtbo -rw-r--r-- 1 root root 780 Nov 27 16:06 sun50i-h6-spi-spidev.dtbo -rw-r--r-- 1 root root 502 Nov 27 16:06 sun50i-h6-uart1.dtbo -rw-r--r-- 1 root root 790 Nov 27 16:06 sun50i-h6-uart2.dtbo -rw-r--r-- 1 root root 790 Nov 27 16:06 sun50i-h6-uart3.dtbo -rw-r--r-- 1 root root 773 Nov 27 16:06 sun50i-h6-w1-gpio.dtbo

understood martinayotte, loiter for a while taking your rest! Meanwhile booted the dev image built - just sharing some info for the ones that are interested. One thing that immediately caught my attention it appears CPUFreq is still WIP ? Most likely this a .config kernel thingie, which simply needs to be enabled or more work to do ? root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian Buster with Linux 5.4.0-rc8-sunxi64 System load: 1.44 0.56 0.22 Up time: 4 min Memory usage: 12 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 11% of 7.1G Last login: Wed Nov 27 02:34:54 2019 from 192.168.10.98 root@orangepioneplus:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.

cheers both - final attempt for today, which actually appers to be third time " lucky " : git clone --depth 1 https://github.com/armbian/build armbian cd armbinan ./compile.sh BOARD=orangepioneplus BRANCH=dev <snip snip>... ... # same parameters as shown in previous post [ o.k. ] Checking git sources [ u-boot v2019.10 ] # nice! :-) [ o.k. ] Checking git sources [ linux-mainline orange-pi-5.4 ] # good stuff! now megi to merge things for 5.4 final, so no more KERNELRELEASE=5.4.0-rc8-sunxi64 :-) <snip snip> Well hats off to youse guys, seems following DEV image has been built : Armbian_19.11.3_Orangepioneplus_buster_dev_5.4.0-rc8_minimal.img Grepping on logs shows tons of warnings so will exclude these, ERRORS however compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0" compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-a64-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0" compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0" compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h5-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0" compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:20.11-25.6: Warning (spi_bus_reg): /fragment@1/__overlay__/spidev: SPI bus unit address format error, expected "0" compilation.log:arch/arm64/boot/dts/allwinner/overlay/sun50i-h6-spi-spidev.dts:34.11-39.6: Warning (spi_bus_reg): /fragment@2/__overlay__/spidev: SPI bus unit address format error, expected "0" output.log:Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] 0080-rtl8723bs-disable-error-message-about-failure-to-all.patch info patching.log:Processing file /home/dolphs/armbian/patch/kernel/sunxi-dev/0080-rtl8723bs-disable-error-message-about-failure-to-all.patch So it is really getting there chaps, well done! Now where is 5.5-rc1 next ;-) nite nite

Hi, ok just lit up my dev environment and tried to build from scratch ( removing armbian directory and check out again ) Current orangepione plus status building with: ./compile.sh BOARD=orangepioneplus BRANCH=dev RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=yes <snip snip> oot-nodtb.bin 0x4a000000 $start $end scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-beelink-gs1.dtb' failed scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-orangepi-lite2.dtb' failed scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb' failed scripts/Makefile.lib:308: recipe for target 'arch/arm/dts/sun50i-h6-pine-h64.dtb' failed dts/Makefile:38: recipe for target 'arch-dtbs' failed Makefile:1061: recipe for target 'dts/dt.dtb' failed [ error ] ERROR in function compile_uboot [ compilation.sh:204 ] [ error ] U-boot compilation failed [ o.k. ] Process terminated :~/armbian/output/debug$ grep ERROR output.log Displaying message: ERROR in function compile_uboot compilation.sh:204 err :~/armbian/output/debug$ grep failed output.log Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add-h6-syscon+emac.patch failed wrn Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] add-orangepi3.patch failed wrn Displaying message: * [\e[32ml\e[0m][\e[32mc\e[0m] fix-u-boot-H6-reset.patch failed wrn Displaying message: U-boot compilation failed err :~/armbian/output/debug$ grep ERROR compilation.log arch/arm/dts/sun50i-h6-beelink-gs1.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-beelink-gs1.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-orangepi-lite2.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-orangepi-lite2.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-orangepi-one-plus.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output) arch/arm/dts/sun50i-h6-pine-h64.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name arch/arm/dts/sun50i-h6-pine-h64.dtb: ERROR (duplicate_node_names): /soc: Duplicate node name ERROR: Input tree has errors, aborting (use -f to force output)

thanks - built with orangepi-5.4 (rc8) but still get the dts duplicate_node_names errors as back then, suppose 5.4 will not be ready for building till megi merged to official? [ ./compile.sh BOARD=orangepioneplus BRANCH=current RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=yes ] #updated " sunxi64_common.inc " to " KERNELBRANCH="branch:orange-pi-5.4" " output.log <snip snip> Displaying message: Compiling dev kernel 5.4.0-rc8 info Displaying message: Compiler version aarch64-linux-gnu-gcc 8.3.0 info Displaying message: Using kernel config file config/kernel/linux-sunxi64-dev.config info Displaying message: ERROR in function compile_kernel compilation.sh:382 err Displaying message: Kernel was not built @host err grep ERROR compilation.log arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:735.21-747.5: ERROR (duplicate_node_names): /soc/i2c@5002000: Duplicate node name arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:749.21-761.5: ERROR (duplicate_node_names): /soc/i2c@5002400: Duplicate node name arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:763.21-775.5: ERROR (duplicate_node_names): /soc/i2c@5002800: Duplicate node name arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:1205.18-1213.5: ERROR (duplicate_node_names): /soc/ir@7040000: Duplicate node name thanks for efforts, will stay tuned!

and there it is ... so " dev " will be 5.5 ( once available ) and " current " will be based on 5.4.x soon ( once ayufan rgd RK3399 and rgd H6 megi got their code tagged ), Interesting two months coming up.

Barrel connected or "USB OTG" power supply, also is it 5v 2 or 3ampere that is connected? I tried a 5v 2ampere USB OTG as well the barrel ( 5v 3a) but unable to get it stable, perhaps 5.3.12 ( looks like "next" is being compiled with that version )