sfx2000

root@mips24k:~# find /lib/modules/|fgrep -i tables /lib/modules/5.4.51/ip6_tables.ko /lib/modules/5.4.51/ip_tables.ko /lib/modules/5.4.51/nf_tables.ko /lib/modules/5.4.51/nf_tables_set.ko /lib/modules/5.4.51/x_tables.ko everything here seems to be fine...

Android is it's own space, and out of scope of with Armbian support...

>> Yep the Espressobin is not optimal for routing / switching. mixed feelings here - espressobin includes topaz... which is really the limit... MV3720 is fast enough - across BR-LAN on a specific design, it's fast enough.

With CESA - many assumptions based on Armada 38x - where things in scope looked very good on ARM-V7A - both the Marvell cores and the later ARM-a9's... Armada is mixed up here... let's just say that 38x has massive bandwidth inside the chip - MV3720/Mochi doesn't... MV3720 - always a tradeoff - more CPU and throughput, or offload to the CESA units, which is probably similar to other "off-loads" for dedicated accelerators Personally - I would not recommend CESA here,,, I would recommend core here as the is CPU/MEM, and CESA is limited, and so is the bus within the chip itself.

Hehe - when the sensor is not connected... On my current project - old code fitted on to a new SOC - it always reports -273C for temp

While I'd like to give a foxing clever response... I'm not seeing a way to do what you're asking - it's late in the day for me, so I'm sure someone will find a solution perhaps.. GPIO's are assigned by uboot/device tree/DT overlay on boot

Not a big fan of Snaps on embedded devices... old versions tend to stick around, and will fill up your file system... Trying hard to avoid the whole Mint/Ubuntu SNAP discussion here...

Interesting board perhaps as it continues the NEO footprint - probably not compatible with the hats/housing, but makes up with other interesting bits... USB-C for power only - IIRC, the Neo/Neo2 was uUSB with OTG, so win some, lose some 1GB/2GB DDR4, and two banks of it - that's nice CPU/DDR4 mounted on the bottom of the board, very nice to get some heat out in a metal case. USB3 - very nice... Downsides... Rockchip - maybe for some, not for others, but it'll be a learning curve for NEO folks used to AW H3/H FAN connector - not sure if this is a good thing? or does the Rockchip need some thermal assistance

Check your terminal settings - 115200-8-N-1 usually works, and you might need to disable flow control.

Are you doing USB-OTG on that board for console?

Add this extraargs=net.ifnames=0 to /boot/armbianEnv.txt Some WiFi routers have problems with this... and some WiFi drivers as well...

@5kft and I did a fair amount of testing for the recent uboot update for NanoPI Neo2 (H5) with the following stress test... openssl speed -multi 4 WIth the schedutil governor. and keeping NanoPi Neo to 1008, it's stable No, it's a hardware issue with overclocking on both CPU and DRAM timing - it was on FriendlyArm NanoPI NEO2... OrangePi Zero Plus - same chipset and NanoPi NEO2, and perhaps not the same level of quality... Here's NanoPi NEO2 on H5 throttling under load... 18:35:37: 1008MHz 4.00 100% 0% 99% 0% 0% 0% 69.7°C 0/4 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 18:35:42: 960MHz 4.00 100% 0% 99% 0% 0% 0% 75.2°C 1/4 18:35:47: 960MHz 4.15 100% 0% 99% 0% 0% 0% 73.6°C 1/4 18:35:52: 816MHz 4.13 100% 0% 99% 0% 0% 0% 75.0°C 2/4 18:35:58: 816MHz 4.12 100% 0% 99% 0% 0% 0% 67.8°C 1/4 18:36:03: 960MHz 4.11 100% 0% 99% 0% 0% 0% 74.5°C 1/4 18:36:08: 960MHz 4.10 100% 0% 99% 0% 0% 0% 74.0°C 1/4 18:36:13: 816MHz 4.10 100% 0% 99% 0% 0% 0% 75.3°C 2/4 18:36:18: 960MHz 4.09 100% 0% 99% 0% 0% 0% 67.6°C 1/4 18:36:23: 960MHz 4.08 100% 0% 99% 0% 0% 0% 74.3°C 1/4 18:36:28: 960MHz 4.07 100% 0% 99% 0% 0% 0% 67.3°C 1/4 18:36:33: 960MHz 4.07 100% 0% 99% 0% 0% 0% 73.9°C 1/4 18:36:38: 960MHz 4.06 100% 0% 99% 0% 0% 0% 74.7°C 1/4 18:36:43: 960MHz 4.06 100% 0% 99% 0% 0% 0% 73.6°C 1/4 18:36:49: 960MHz 4.05 100% 0% 99% 0% 0% 0% 75.8°C 2/4 18:36:54: 1008MHz 4.05 100% 0% 99% 0% 0% 0% 73.4°C 0/4 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 18:36:59: 960MHz 4.04 100% 0% 99% 0% 0% 0% 75.0°C 1/4 18:37:04: 960MHz 4.04 100% 0% 99% 0% 0% 0% 74.0°C 1/4 18:37:09: 960MHz 4.04 100% 0% 99% 0% 0% 0% 74.6°C 1/4 18:37:14: 960MHz 4.03 100% 0% 99% 0% 0% 0% 70.6°C 1/4 18:37:19: 816MHz 4.03 100% 0% 99% 0% 0% 0% 75.3°C 2/4 18:37:24: 816MHz 4.03 100% 0% 99% 0% 0% 0% 76.2°C 2/4 18:37:29: 960MHz 4.02 100% 0% 99% 0% 0% 0% 67.6°C 1/4

You need to do a bit more... sudo apt-get install vlan load kernel module sudo modprobe 8021q Create a new interface that is a member of a specific VLAN, VLAN id 100 Use the physical interface eth0 in this example. This command will add an additional interface next to the interfaces which have been configured already sudo vconfig add eth0 100 Assign an address to the new interface. sudo ip addr add 10.0.0.1/24 dev eth0.100 To make this setup permanent. Add the module to the kernel on boot sudo su -c 'echo "8021q" >> /etc/modules' Create the interface and make it available when the system boots. Add the following lines to /etc/network/interfaces auto eth0.100 iface eth0.100 inet dhcp vlan-raw-device eth0

Hit the easy button and install OpenWRT Done and done - solves your problem. Move on to other interesting things with your homelab.

** Network Manager CLI ** use NMCLI $ nmcli device status DEVICE TYPE STATE CONNECTION enp1s0 ethernet connected Wired connection 1 wlp2s0 wifi disconnected -- lo loopback unmanaged -- to check radio $ nmcli radio WIFI-HW WIFI WWAN-HW WWAN enabled enabled enabled enabled Let's see what's out there... scan for AP's $ nmcli dev wifi list SSID MODE CHAN RATE SIGNAL BARS SECURITY MYSSID Infra 11 54 Mbit/s 100 ▂▄▆█ WPA2 MYSSID Infra 132 54 Mbit/s 100 ▂▄▆█ WPA2 SOMEOTHERSSID Infra 52 54 Mbit/s 49 ▂▄__ WPA2 MYSSID Infra 149 54 Mbit/s 45 ▂▄__ WPA2 MYSSID Infra 11 54 Mbit/s 42 ▂▄__ WPA2 SOMEOTHERSSID Infra 1 54 Mbit/s 27 ▂___ WPA2 Now, let's connect to WiFi (note, one must be root or sudo access) Connecting to an open AP $ nmcli device wifi connect <SSID|BSSID> For a password protected AP, see below $ nmcli device wifi connect <SSID|BSSID> password <password> Cool, eh? To set up a device as an AP - this assumes that WLAN0 is the wireless interface... $ nmcli dev wifi hotspot ifname wlan0 <SSID> password "<password>" Cool, eh?

In personal experience - it's generally doable... and it's really the makefiles for externals like device drivers that are the devils to be solved. In any event - cross-builds produce the same performance as native - ARM on X86, MIPS on ARM, ARM on ARM... For most folks - LEDE/OpenWRT has solved that particular problem...

Interesting... Ethernet - realtime capable, e.g. support EtherCAP, ProfiNET, EtherNET/IP, IEEE 1588? PTP support on the MAC's? The MAC's - are they hard or soft on the Real Time side (if they even support this) I don't see bus support for standard buses like SAE J1939, CANOPEN, DeviceNet - at least not declared? Any support for Housing/Cases that support DIN mounting? UART support - I don't see defined UART's, so does one have to bit-bang this? Would be curious to know how/why this is considered Industrial? Personally - I don't even see this as being safe for Robotics even, much less anything that needs real-time support on the interfaces.

@5kft Saw the uboot update pushed out - folks can blame me for the performance hit perhaps as part of this thread. @Igor Which one was released - 408MHz was stable under testing... sfx@blaster:~/nano2_uboots$ ll total 544 -rw-r--r-- 1 sfx sfx 275264 Jun 17 20:08 linux-u-boot-current-nanopineo2_20.05.0-trunk_arm64.deb -rw-r--r-- 1 sfx sfx 275372 Jun 17 20:08 linux-u-boot-current-nanopineo2_408_MHz_20.05.0-trunk_arm64.deb Best regards... Up to my knees with other stuff standing on my head - which means means the inverse

Same here - FA has done a few variants of the NEO form factor that are very useful for projects...

Allwinner will continue to make chips of any variant as long as there is a minimum order quantity (MOQ) commitment upfront with cash to spin up the fab... Might take a volume commitment - they will definitely make that happen, if the volume is enough to be profitable... Olimex went thru this exercise with the Allwinner T2/A20 chip... Just takes the money to make it happen...

Maybe in his design - but SPI can support multiple slaves... only one master of course... Here's a couple of different topologies using SPI and multiple slaves - I did something similar a few years back with SPI-NOR and SPI-NAND for expansion... there, each devices was and MTD device, using UBI and formatting with UBIFS - bootloader, kernel, rootfs on the NOR, storage on the NAND I've seen crazy stuff on SPI - everything from MUX's to Switches, to doing a Serial-Parallel converter...

That's a partial - it's not an MSM/APQ chip... and it's not CDMA/EVDO CPU implementer being 0x51 is a good hint though...

Fun stuff - and something that's kept me offline/busy for the last few weeks... # uname -a Linux blaster 3.4.0 #1 PREEMPT Wed May 13 14:43:07 PDT 2020 armv7l GNU/Linux # cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS : 586.13 Features : swp half thumb fastmult vfp edsp neon vfpv3 tls CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x1 CPU part : 0x00f CPU revision : 2 Hint - it's old enough not to have a device-tree... actually, in CPU years, it's old enough to vote/drink, and in dog-years, it's probably dead. I'll sent $20USD and a possible job offer if you can ID the specific chip... No @Igor, you don't get to play here

At first glance - this looks like a driver issue...

FWIW - WG performance on Cortex-A7 - you'll be lucky to get 200 Mbps - this is based on experience with Qualcomm IPQ4028 w/QSDK - runs a bit slower on the CPU's -- 717MHz, but much better internals for network items compared to H3