sfx2000

Add this
extraargs=net.ifnames=0 to /boot/armbianEnv.txt

Just noticed how small the M1 MacMini mainboard is... 
 
I'm surprised it even has a fan, they could have done a heat pipe to the housing, and that likely would have been "good enough"  - that's the nice thing about my MBAir-M1, no fans, it's dead silent.
 

Something to consider for your CI/CD pipeline...
 
https://www.servethehome.com/oracle-cloud-giving-away-ampere-arm-a1-instances-always-free/
 
There is always AWS, but that ain't free...

Running Ubuntu 20.04LTS on UTM on Macbook Air M1...
 
https://mac.getutm.app/
 

Atheros 9331 can do this all day long on 100-Base-T... 400MHz MIPS32
 
[SUM]   0.00-10.00  sec   102 MBytes  85.5 Mbits/sec              sender [SUM]   0.00-10.00  sec   101 MBytes  84.4 Mbits/sec                  receiver  
64MB RAM/16MB SPI-NOR - running OpenWRT
 
If you need a bit more horsepower to route traffic - MV3720 on Gigabit can do wire speed there...
 
Alternate for 1GB - QCA IPQ-40xx - I've got a IPQ-4019 board running QSDK (based on an older OpenWRT with QCA special sauce), and it can route actually better than the MV3720 - and that's a QuadCore Cortex-A7...
 
Key thing here - AR9331/MV3720/IPQ4019 - these are all communications focused devices, not application processors/boards...

If you are running Armbian desktop and you like to use Visual Studio Code,  open a terminal and run:
 
sudo apt update sudo apt install code  

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

what @Igor is getting at - this is a community supported driver - there's no real support from the chipset vendor for Linux.
 
88XXau has been problematic across the board with all Linux distro's...

Just In case anyone is interested I have pushed HTOP 2.2.1 to github, so it is possible to monitor big.LITTLE cores in real-time.
You can view the big.LITTLE in action, Vcore, Cpu thermal throttling and Cpu frequency for each big or LITTLE core.
 
HTOP is a nice console graphical tool for system-monitor, process-viewer and process-manager.
DEB package and source code in case you want to extend or fix things.
Be aware the process list and task can be very intrusive if you want to monitor many things at once.
It has been tested on NanoPi M4 (thanks to FriendlyElec for the samples) but should work on any SBC just adjust the Vcore path for different kernel version.
 
https://github.com/avafinger/htop-2.1.1_enhanced-version
 

Thanks for your work! New Ubuntu version and Wifi works :)

DTS overlay to activate I2S DAC 5102a on Armbian Buster 5.4.43
armbian-add-overlay sun50i-h5-i2s0-out.dts If you don't have headers armbian-config (software->headers)
 
Manual install whithout headers
mkdir /boot/overlay-user/ dtc -I dts -O dtb sun50i-h5-i2s0-out-no-header.dts -o /boot/overlay-user/sun50i-h5-i2s0-out.dtbo add user_overlays=sun50i-h5-i2s0-out to /boot/armbianEnv.txt  
sun50i-h5-i2s0-out.dts
/dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a: pcm5102a { #sound-dai-cells = < 0x00 >; compatible = "ti,pcm5102a"; status = "okay"; linux,phandle = < 0x26 >; phandle = < 0x26 >; pcm510x,format = "i2s"; }; }; }; fragment@1 { target-path = "/aliases"; __overlay__ { i2s0 = "/soc/i2s@1c22000"; }; }; fragment@2 { target = <&i2s0>; __overlay__ { status = "okay"; pinctrl-0 = <&i2s0_pins>; sound-dai = <&pcm5102a>; pinctrl-names = "default"; }; }; fragment@3 { target-path = "/"; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-master"; simple-audio-card,mclk-fs = <256>; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = <&i2s0>; }; simple-audio-card,codec { sound-dai = <&pcm5102a>; }; }; }; }; };  
sun50i-h5-i2s0-out-no-header.dts
/dts-v1/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = [ 2f 00 ]; __overlay__ { pcm5102a { #sound-dai-cells = < 0x00 >; compatible = "ti,pcm5102a"; status = "okay"; linux,phandle = < 0x26 >; phandle = < 0x26 >; pcm510x,format = "i2s"; }; }; }; fragment@1 { target-path = "/aliases"; __overlay__ { i2s0 = "/soc/i2s@1c22000"; }; }; fragment@2 { target = < 0xffffffff >; __overlay__ { status = "okay"; pinctrl-0 = < 0xffffffff >; sound-dai = < 0x26 >; pinctrl-names = "default"; }; }; fragment@3 { target-path = [ 2f 00 ]; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-master"; simple-audio-card,mclk-fs = < 0x100 >; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = < 0xffffffff >; }; simple-audio-card,codec { sound-dai = < 0x26 >; }; }; }; }; __symbols__ { pcm5102a = "/fragment@0/__overlay__/pcm5102a"; }; __fixups__ { i2s0 = "/fragment@2:target:0\0/fragment@3/__overlay__/sound_i2s/simple-audio-card,cpu:sound-dai:0"; i2s0_pins = "/fragment@2/__overlay__:pinctrl-0:0"; }; __local_fixups__ { fragment@2 { __overlay__ { sound-dai = < 0x00 >; }; }; fragment@3 { __overlay__ { sound_i2s { simple-audio-card,codec { sound-dai = < 0x00 >; }; }; }; }; }; };  

Not sure whether it's a good idea to bump this thread but just my 2cts on this:
CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf).
In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get:
 
 - Plain access to disk: 180MB/s
 - LUKS2 + CESA: 140MB/s
 - LUKS2 (no CESA): 52MB/s
 
I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64.
For me this is quite good already even tho CESA only supports some "relatively old" ciphers.
 
Hope this helps other people!

The issue has already been resolved and the Armbian build works on ARM devices.

If anybody is interested, I've got a single python script that works without needing to install any of the FriendlyElec software. Just enabled i2c0, python and a few dependencies.
 
You can find the code on: https://github.com/crouchingtigerhiddenadam/nano-hat-oled-armbian
The screen turns off after 15 seconds of inactivity to reduce burn-in, variable update rates, splash screen, date/time screen, computer stats screen and a shutdown screen.

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...

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

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...

** 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?

Please contact the administration to move this topic to the TV box section. I would like to (as far as possible) continue this direction (native Armbian build directly on ARM devices). For skeptics. Recently, I completely moved the LivreELEC build to the ARM platform (i.e. the entire process of creating LE images and Addons now takes place on ARM rk3399\s922x devices). My dream is (perhaps) to try to transfer the ArmbianTV build completely to the ARM platform and get rid of the x86 dependency.

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

For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
 
Thank you all for attending the meeting!

Recently revisiting things with H5 stability under certain SMP load factors* with @5kft and assistance with @lanefu - and H5 tends to be stable around 1104Mhz CPU/504MHz DDR with a 1.3v regulator overlay, and 1008/504 at 1.1v on NanoPi NEO2 - which doesn't really use the Mali450 at all.
 
@lanefu was using a different H5 board (Orange Pi something or other - pls comment) - but he was also able to reproduce the stability issue I noted.
 
Might be more interesting on something that engages all cores on the CPU, and does the GPU stress as well.
 
 
* openssl speed -multi 4 - which flexs the ARMv8 enhancements there, engaging more of the logical blocks in Cortex-a53 - note that the governor in use is schedutil, which tends to be a different code path than "performance" or "on demand"
 
@5kft - has been super awesome at helping out - reproducing the issue, concurring with analysis, proposing fixes...
 
sfx

Most SoC are not "slave capable" but only "master" ...

@tkaiser Allwinner only certifies the H3 to operate at 1008MHz @1.2V and H5 to operate at 1008MHz @ 1.1V with DDR clocks up to 672MHz. Designs and software support for adjustable voltage and higher clock rates must be validated by the third party that chooses to implementing such features.  DVFS will not be supported in the Allwinner H3/H5 BSPs since the transition to AXP8036. I have seen some small boards with 16-bit DDR3 (1 DDR chip) clocked at 744MHz but they are almost guaranteed to have memory errors and video playback issues.

Curious as to why one wants to apply the patches for preempt-rt in the first place? Do you have a reason/application that would benefit? Most times, one can see an overall decrease in application performance, and to take advantage of preempt-rt, the application must call pthreads in a very specific way - which means that many times, the app must also be rebuilt.
 
My reason for asking - if preempt-rt was so awesome, it would already be in the upstream linux kernel mainline and not require the patch. Avoiding politics around preempt-rt - many of the benefits here can be done without the patches, by selecting an appropriate scheduler - schedutil looks fairly interesting at the moment.
 
I work on networking oriented applications that have hard deadlines, on MIPS, PowerPC, ARM (both 32bit ARMv7a and 64-bit), and never had a need to apply the preempt-rt patches.
 
By networking oriented applications - I'm saying 20mSec framing for SIP-RTP (VoIP apps), along with 3GPP/UMTS signalling - if that ain't close to real-time, I don't know what is.