sfx2000

Because they don't have to - they have a working solution that works for their objectives... For now... They're going to do what they're going to do... because they can afford to do so... "Only Nixon could go to China" - one must understand the dynamics of the time... and of the current dynamics with Broadcom/Cypress and ex-Avago - the Broadcom chip is convenient for them as long as they don't need to spend so much... until they need to - and for Broadcom/Avago, it might not be worth it for them. The VC4 based chips are close to end of development - the VC4 is 32bit only, maxed out at 1GB RAM, and is stuck on a 40nm process dictated by the layout of the VC4... Going to 28nm is a new tape out for VC4, and Broadcom likely isn't willing to go there for an old VPU when VC5 is the future... Don't get me wrong - RPi and Broadcom have done well to get a lot of mileage out of a basic VC4 chip - where they are right now - Cortex-A53 at 40nm is about as fast as it can go at 1.4GHz, and turbo'ing VC4 to 400MHz from 250MHz... Not so much different than Apple going to x86 after being heavily invested in PowerPC until it basically stopped being competitive... and that's where RPi and the VC4 chip is right now, they've run out of room... So perhaps a hard cutover - they can port their platform over to RISC-V, and look like a strong player...

RPi is going to do what they see as best for their overall objectives.... Their current platform is at the best end of what they can do with the broadcom VC4 - no further headroom for them. With 33M plus devices sold, one can assume they have some resources to choose their next steps - ARM or RISC-V....

Not Snapdragon... Think RISC-V for the Pi folks... https://riscv.org/membership/4531/raspberry-pi/ They've been clear that the recent releases for the Broadcom VC4 is pretty much done... Just saying...

HInt - pick WPA2 or WPA - don't do mixed...

With BPI-R2 - keep an eye on what's going on with OpenWRT-Master - fair number of changes going on within MT76... That target is under active dev there...

Hehe - and I'm looking at MIP24Kc boards recently, specially QCA9331/9531... as most of the hard work there has already been done getting things up and running...

Gah - realtek wifi...

Quad Cortex-A7, 512MB DDR3L RAM, 16Mb SPI-NOR, and 8GB eMMC, 3 ports GBe - WiFI is 802.11 a/b/g/n/ac on ath10k (2 stream ath10k WiFi - so it's essentially an AC1300 class device supporting MU-MIMO) It's 12VDC@1.5A cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS : 26.81 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 5 Can do close to wirespeed on NAT... Iperf3 numbers Downlink [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 955 MBytes 801 Mbits/sec 3 sender [ 4] 0.00-10.00 sec 951 MBytes 798 Mbits/sec receiver Uplink [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 982 MBytes 824 Mbits/sec 13 sender [ 4] 0.00-10.00 sec 980 MBytes 822 Mbits/sec receiver Openssl Numbers openssl speed sha256 aes-128-cbc rsa2048 OpenSSL 1.0.2h 3 May 2016 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,2,long) aes(partial) blowfish(ptr) compiler: arm-openwrt-linux-uclibcgnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/home/han/item/open53/qsdk/staging_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/usr/include -I/home/han/item/open53/qsdk/staging_dir/target-arm_cortex-a7_uClibc-1.0.14_eabi/include -I/home/han/item/open53/qsdk/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi/usr/include -I/home/han/item/open53/qsdk/staging_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi/include -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -DTERMIOS -Os -pipe -march=armv7-a -mtune=cortex-a7 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -Wl,-z,now -Wl,-z,relro -fpic -I/home/han/item/open53/qsdk/package/libs/openssl/include -fomit-frame-pointer -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 9423.91k 9787.40k 9849.26k 9908.83k 9885.01k sha256 1446.98k 5034.50k 8936.88k 11096.75k 12000.32k sign verify sign/s verify/s rsa 2048 bits 0.083250s 0.002072s 12.0 482.7 Runs OpenWRT already - they're still sorting out some issues related to the QSDK and merging what they can... Might actually be a better board than EspressoBIN for routing purposes...

Gets to a certain point - and then perhaps a NUC is a better choice... NUC's can be cheap still - NUC5CPYH and it beats the pants off Tinker...

Irregardless of the candidate boards - you might want to look at your applications... PI3, no matter what others might mention, is good enough for a certain load, and all the other *Pi single board machines are going to be similar - if you're pushing a Pi3 that hard, not much more can be done... Hardware will only get you so far... Tinker has a lot of horsepower, as perhaps the NanoPI M4 - but might not solve your ask at the end of the day. That and the Rockchip mess that is with upstream...

Current Armbian - it does look like there's a fair amount of cleanup needed on device tree in general... whether it's a 1.0 or a 1.1 board... Just a quick look... haven't had to dive deeper in the h*ll that can be device tree... dtc -I dtb -O dts -f sun50i-h5-nanopi-neo2-v1.1.dtb -o sun50i-h5-nanopi-neo2-v1.1.dts sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@120000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@240000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@480000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@648000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@816000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@960000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1008000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1056000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1104000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1152000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1200000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1224000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1248000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1296000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1344000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (unit_address_vs_reg): Node /opp_table0/opp@1368000000 has a unit name, but no reg property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/eeprom@01c14000 simple-bus unit address format error, expected "1c14000" sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/sound missing or empty reg/ranges property sun50i-h5-nanopi-neo2-v1.1.dts: Warning (simple_bus_reg): Node /soc/gpu@1280000 simple-bus unit address format error, expected "1e80000" sun50i-h5-nanopi-neo2-v1.1.dts: Warning (thermal_sensors_property): thermal-sensors property size (4) too small for cell size 1 in /thermal-zones/cpu-thermal Similar errors show up with a v1.0 dtb... Which is reflected here... collected on a 1.1 board... [ 5.116035] cpu cpu0: Linked as a consumer to regulator.5 [ 5.116089] cpu cpu0: Dropping the link to regulator.5 [ 5.116246] cpu cpu0: Linked as a consumer to regulator.5 [ 5.116865] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.116874] cpu cpu0: _opp_add: OPP not supported by regulators (1056000000) [ 5.116980] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.116986] cpu cpu0: _opp_add: OPP not supported by regulators (1104000000) [ 5.117056] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.117062] cpu cpu0: _opp_add: OPP not supported by regulators (1152000000) [ 5.117159] core: _opp_supported_by_regulators: OPP minuV: 1320000 maxuV: 1320000, not supported by regulator [ 5.117166] cpu cpu0: _opp_add: OPP not supported by regulators (1200000000) [ 5.117234] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117240] cpu cpu0: _opp_add: OPP not supported by regulators (1224000000) [ 5.117346] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117352] cpu cpu0: _opp_add: OPP not supported by regulators (1248000000) [ 5.117420] core: _opp_supported_by_regulators: OPP minuV: 1340000 maxuV: 1340000, not supported by regulator [ 5.117426] cpu cpu0: _opp_add: OPP not supported by regulators (1296000000) [ 5.117525] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.117531] cpu cpu0: _opp_add: OPP not supported by regulators (1344000000) [ 5.117602] core: _opp_supported_by_regulators: OPP minuV: 1400000 maxuV: 1400000, not supported by regulator [ 5.117608] cpu cpu0: _opp_add: OPP not supported by regulators (1368000000) [ 5.139444] thermal thermal_zone1: binding zone cpu-thermal with cdev thermal-cpufreq-0 failed:-22 [ 5.192579] thermal thermal_zone0: failed to read out thermal zone (-110) [ 5.192639] OF: /thermal-zones/cpu-thermal: arguments longer than property [ 5.192654] thermal thermal_zone2: failed to read out thermal zone (-110) @5kft - might be an opportunity to do some basic cleanup there. Diffs between 1.0 and 1.1 follow... it doesn't seem to be much. diff sun50i-h5-nanopi-neo2.dts sun50i-h5-nanopi-neo2-v1.1.dts 1252c1252 < label = "nanopi:green:pwr"; --- > label = "nanopi:red:pwr"; 1258c1258 < label = "nanopi:blue:status"; --- > label = "nanopi:green:status"; 1291c1291 < regulator-max-microvolt = <0x10c8e0>; --- > regulator-max-microvolt = <0x13d620>; 1295c1295 < states = <0x10c8e0 0x0 0x10c8e0 0x1>; --- > states = <0x10c8e0 0x0 0x13d620 0x1>; Anyways - looks like Device Tree in general with Armbian needs some work on the NanoPi Neo2 period...

Patches are usually against a specific version, and there's a number of 1.1 releases...

In the future... cat sysctl.conf > sysctl.conf.bak

Lesson learned I suppose - one does not play lightly with OpenSSL/OpenSSH... I don't think it's a good idea to attempt to downgrade OpenSSL on ARMBIAN from the current - mostly because of how deep OpenSSL is in general, and things that use it.

That's an SDIO based interface, similar to what OPi has... So take a look at your DTS, and ensure that you have things sorted there..