guidol

With just a few local test hacks, I was able to bring up kernel 5.10-rc1 on sunxi this morning (based on the new megous branch):
 
root@air's password: _ _ ____ _ _ _ | \ | | _ \(_) / \ (_)_ __ | \| | |_) | | / _ \ | | '__| | |\ | __/| | / ___ \| | | |_| \_|_| |_| /_/ \_\_|_| Welcome to Armbian 20.08.14 Buster with Linux 5.10.0-rc1-sunxi System load: 2% Up time: 11 min Memory usage: 14% of 491M IP: 172.24.18.151 CPU temp: 34°C Usage of /: 24% of 7.2G Last login: Tue Oct 27 07:20:02 2020 from 172.24.18.20 root@air:~# cat /proc/version Linux version 5.10.0-rc1-sunxi (root@355045fc2473) (arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025, GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #trunk SMP Tue Oct 27 14:13:23 UTC 2020 root@air:~# root@air:~# cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: 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: 5.44 ms. hardware limits: 480 MHz - 1.20 GHz available frequency steps: 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.10 GHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 816 MHz (asserted by call to hardware). cpufreq stats: 480 MHz:97.72%, 648 MHz:0.22%, 816 MHz:0.20%, 960 MHz:0.23%, 1.01 GHz:0.15%, 1.10 GHz:0.19%, 1.20 GHz:1.29% (679) root@air:~#  
I tested this on a spare NanoPi NEO Air board I had; I haven't tried an arm64 build yet.  dmesg is clean; cpufreq works,  overclocking works, wireless works, etc.  Our 5.9 kernel patchset applied almost completely without error (there are a few other changes needed such as the builddeb patches and fbcon reversion patch we did).
 
In any case I just wanted to let people know.  Given that 5.10 is confirmed to be the new LTS and 5.9 is the new primary -stable,  I'm wondering if 5.8's days are numbered (like what happened to 5.7).  I'm happy to put some work into bringing 5.10 into build if there is interest.
 

@5kft @Hannes Worst @@lex
somebody did hear us  the analog sound is back in dev kernel/dtb 5.9.1
and now - I think - we have found the missing link:
sound was playing but we didnt hear anything on analog-audio because - as I remember right -  the option
AIF1 Slot 0 Digital DAC
was missing. So it couldnt be enabled  
 
Now the option is back and the DAC could now enabled again - so no more silence anymore  
 
BUT be advised to set AIF DA0 not higher than 17, because then the sound will very fast be distorted/overdriven  
 
So here is my kernel-information als alsamixer-setting for analog-audio (sun50i-a64-audio):
_ _ ____ _ _ __ _ _ | \ | | _ \(_) / \ / /_ | || | | \| | |_) | | / _ \| '_ \| || |_ | |\ | __/| | / ___ \ (_) |__ _| |_| \_|_| |_| /_/ \_\___/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.1-sunxi64 No end-user support: built from trunk package bsp-kernel[20.11.0-trunk] u-boot[20.11.0-trunk] dtb [20.11.0-trunk] firmware [20.11.0-trunk] config[20.11.0-trunk] branch[dev] root@npi-a64-116(192.168.6.116):~# uname -a Linux npi-a64-116 5.9.1-sunxi64 #trunk SMP Mon Oct 26 18:14:55 +03 2020 aarch64 GNU/Linux root@npi-a64-116(192.168.6.116):~# more /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@npi-a64-116(192.168.6.116):~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun50ia64audio [sun50i-a64-audio], device 0: 1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0 [1c22c00.dai-sun8i-codec-aif1 sun8i-codec-aif1-0] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: sun50ia64hdmi [sun50i-a64-hdmi], device 0: 1c22800.i2s-i2s-hifi i2s-hifi-0 [1c22800.i2s-i2s-hifi i2s-hifi-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@npi-a64-116(192.168.6.116):~# alsamixer Card: sun50i-a64-audio Value: Item: 83 Headphone [dB gain: -8.00] Mixer Headphone Source [Mixer] 15 AIF1 DA0 [dB gain: -24.00, -24.00] Stereo AIF1 DA0 Stereo [Stereo] Enable AIF1 Slot 0 Digital DAC 82 DAC [dB gain: 18.75, 18.75] Enable DAC Reversed  

@Igor I'd like to get your thoughts regarding this...:  The Realtek kernel change that caused this issue is indeed correct and good (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=bbc4d71d63549bcd003a430de18a72a742d8c91e), as it fixes the earlier invalid implementation in the kernel.  The failure problems with the RTL8812E occur with this change because "phy-mode" in the DT now matters and must be correct, whereas previously it did not.  By changing the "phy-mode" to "rgmii-id" correctly for sunxi boards that have the TXDLY and RXDLY pull-ups on the PHY, the RTL8812E is properly configured and works.  However this means that all of the relevant DTs need to be updated to correctly reflect their actual hardware configuration.
 
I started making these changes in the patches in sunxi-dev, confirming the existence of the delay configuration pull-ups with the board schematics to determine the proper phy-mode to set, and removing my reversion patch.  However any boards that are missed will have Ethernet failures until the DTs are properly patched.  Should we just leave the reversion patch in instead (long-term)?

I just installed 5.9.0 from the 20.08.12 package and I can confirm it's working fine. The system came back with working network connection.
Thanks to everyone, esp. @Igor for finding the root cause and @5kft for getting the patch included so quickly.

According to the method you introduced, the music played happily. thank you very much.  Good good study, day day UP.

I did it and it does work  
-rwxr--r-- 1 datashare datashare 43652 Oct 17 17:58 armbian-config_20.11.0-trunk_all.deb -rwxr--r-- 1 datashare datashare 6916332 Oct 17 17:58 armbian-firmware_20.11.0-trunk_all.deb -rwxr--r-- 1 datashare datashare 192712 Oct 17 17:57 linux-dtb-dev-sunxi_20.11.0-trunk_armhf.deb -rwxr--r-- 1 datashare datashare 35322316 Oct 17 17:58 linux-image-dev-sunxi_20.11.0-trunk_armhf.deb -rwxr--r-- 1 datashare datashare 236608 Oct 17 17:48 linux-u-boot-dev-bananapim2berry_20.11.0-trunk_armhf.deb ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \| __ ) | _ \| |_) | | | |\/| | __) | _ \ | |_) | __/| | | | | |/ __/| |_) | |____/|_| |_| |_| |_|_____|____/ Welcome to Armbian Buster with Linux 5.9.0-sunxi package bsp-kernel[20.11.0-trunk] u-boot[20.11.0-trunk] dtb [20.11.0-trunk] firmware [20.11.0-trunk] config[20.11.0-trunk] branch[dev] root@bpi-m2-berry(192.168.6.20):~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.20 netmask 255.255.255.0 broadcast 192.168.6.255 ether 02:53:bc:93:a8:02 txqueuelen 1000 (Ethernet) RX packets 329 bytes 35595 (34.7 KiB) RX errors 0 dropped 2 overruns 0 frame 0 TX packets 315 bytes 35070 (34.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 37 root@bpi-m2-berry(192.168.6.20):~# dmesg|grep eth0 [ 8.326164] dwmac-sun8i 1c50000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 8.329007] dwmac-sun8i 1c50000.ethernet eth0: No Safety Features support found [ 8.329028] dwmac-sun8i 1c50000.ethernet eth0: No MAC Management Counters available [ 8.329037] dwmac-sun8i 1c50000.ethernet eth0: PTP not supported by HW [ 8.329052] dwmac-sun8i 1c50000.ethernet eth0: configuring for phy/rgmii link mode [ 10.454163] dwmac-sun8i 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx  

You can build a new kernel package from master branch using the build script. This will include @5kft's revert commit.
 
Or you get lucky a find a matching package here: https://beta.armbian.com/

I'm running the legacy armbian on an orange pi pc for CCTV. Four IP + Zoneminder cameras with the CPU reaching 75º without a cooler. The system is rock solid. Migrating to the most current version of armbian, I couldn't keep him alive for more than 2 days. Constant freezes. The funny thing is that in legacy armbian, with the same hardware configurations the system works wonderfully. I love the legacy Armbian. For me it works spectacularly.

Hi all
I am new to V3s dev. I am creating a small computer based on the lichee pi zero. 
I am trying to get the best option to add a keyboard. 
Would you suggest me to design an I2C keyboard , or will a classicac usb keyboard work out of the box ? Building a usb keyboard based on an atmega32u4 microcontroler would be very simple.

I overcame that issue by running make with the following environment variable:
- USER_EXTRA_CFLAGS="-fno-stack-protector"
 
`USER_EXTRA_CFLAGS="-fno-stack-protector" make all`
 
This may help someone... 👍

I went ahead and cleaned up the remaining problems for 5.8.  I don't have an H6 board so I can't test the changes there, but I believe they should work fine (I did a rework of my previous thermal changes for H6 and re-applied on the new 5.8 base).

In the past I did also install vsftpd, but some time ago I did see that the package oppenssh not only has openssh-client / openssh-server...

As third part there is the openssh-sftp-server which armbian does install.
So I never installed vsftpd additionally again

The 3 packets in armbian (on my installation) are:
 
openssh-client 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) client, for secure access to remote machines openssh-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) server, for secure access from remote machines openssh-sftp-server 1:8.2p1-4ubuntu0.1 arm64 secure shell (SSH) sftp server module, for SFTP access from remote machines An idea for the configuration of openssh-sftp-server could be found at
https://www.allthingsdigital.nl/2013/05/12/setting-up-an-sftp-only-account-with-openssh/

@guidol - no, while this may seem weird it's perfectly normal - this is a "bind mount", and this is how bind mounts appear in "mount".  You can create one of these yourself, for example:
root@nanopi:~# mkdir foo bar root@nanopi:~# mount --bind foo bar root@nanopi:~# mount | grep bar /dev/mmcblk1p2 on /root/bar type f2fs (rw,relatime,lazytime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=default,fsync_mode=posix,compress_algorithm=lz4,compress_log_size=2) root@nanopi:~# (The "log.hdd" bind mount is created via "/usr/lib/armbian/armbian-ramlog".)  Hope this helps!

@5kft Yes - does work now correctly. I compiled the kernel/dtb 5.9.0.rc4 after your commit and installed all files. Then I activated the 1.0Ghz/1.1v dtbo and rebooted. All dtbo-files are now loaded correctly:
 
 
And all CPU-frequencies are available up to the 1008Mhz (1.01Ghz)  

From what I saw it was a direct commit to master without PR. Therefore nobody had to accept and merge it.

USBImager V1.0..4 is now 2 months old, but I today recommend by cnx-software:
https://www.cnx-software.com/2020/09/08/usbimager-a-lightweight-alternative-to-balenaetcher/
 
Filter out drives on the same disk as C:
https://gitlab.com/bztsrc/usbimager/-/commit/1775cdc628a3d28ce454c181952aa283334d0991

USBImager V1.0..4 is now 2 months old, but I today recommend by cnx-software:
https://www.cnx-software.com/2020/09/08/usbimager-a-lightweight-alternative-to-balenaetcher/
 
Filter out drives on the same disk as C:
https://gitlab.com/bztsrc/usbimager/-/commit/1775cdc628a3d28ce454c181952aa283334d0991

This fixes operation for these overlays under v5.9 so that they work correctly (just like under v5.8) 

@guidol - thank you, the logs you provided were exactly what I needed!  I have fixed the issue with the overclock overlays for -dev, and have push the changes to master (https://github.com/armbian/build/commit/9a096fc557367668e01736400d2c5cb4c8c28a75).  Please give these changes a try and let me know how it goes!

As H6 got built,
I owe boards below - is there any interest if I'd share default rc4 buster images for these ?
Just need a location to upload these
./compile.sh BRANCH=dev RELEASE=buster BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no - H2+:  orangepizero lts
- H3:  orangepi lite, Banana Pi BPI-M2+
- H5 : neo2 1.0/ neo2 1.1, neo2 black 

Default User/Password for a new flashed image on SDCard is
User: root
Initial Password: 1234
 
after that you have to enter a new root-password

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

I think it should be good to switch to u-boot v2020.07, at least for DEV, I've done that since few weeks locally and didn't got any issues ...

My Allwinner garden tour using 5.9.y is almost finished ! Only 2 board models left ...