guidol

We need a reason to make patch releases  

Release info:
https://www.armbian.com/newsflash/armbian-20-11-tamandua/
 
Downloads:
https://www.armbian.com/download/
 

And the nice thing, you can have Htop in a Browser...
 

It's a gaming case. Has all requirements such as leds in the bottom  , green led Razor logo in the front, glass window and RGB leds on the cooling cap ...  but it is fu* 1cm too small to mount a radiator inside the case.  I could mount it outside but its not screwed with all screws . Cooling performance is awesome at this point.
 
Ignore messy cabling - will be done at the end.
 

Hopefully it gets into better shape once Armbian starts tinkering with it

Thanks for your response and explanation.
I performed the backup and upgraded the kernel to 4.14.202 and it has gone smoothly.
And, Tailscale is back to it's happy self again.
 
I really enjoy these little devices too, so I will continue to try and learn more and more about them and Linux but sometimes it seems bottomless.
I appreciate the efforts of the contributors.
 
Jon
 

i think it could be a generic a20 problem - maybe have a look at:
 
https://forum.armbian.com/topic/7575-k-worker-problem-on-a20-based-boards/
https://forum.armbian.com/topic/14282-headless-systems-and-sun4i_drm_hdmi-a10a20/
https://superuser.com/questions/1515001/debian-10-buster-on-cubietruck-with-bug-in-sun4i-drm-hdmi
 
best wishes - hexdump

Wow, that was a very helpful answer, thanks a lot!!
With that info I can just blacklist that modules (anyway, I'm not interested in using the ADC functionality of the A20 :P) and now the system shows proper low cpu usage:
root@lime:~# cat /etc/modprobe.d/fix.conf blacklist sun4i_gpadc sun4i_gpadc_iio root@lime:~# ps auxk -cpu | head USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.5 26932 5332 ? Ss 00:07 0:07 /sbin/init root 2 0.0 0.0 0 0 ? S 00:07 0:00 [kthreadd] root 3 0.0 0.0 0 0 ? I< 00:07 0:00 [rcu_gp] root 4 0.0 0.0 0 0 ? I< 00:07 0:00 [rcu_par_gp] root 8 0.0 0.0 0 0 ? I< 00:07 0:00 [mm_percpu_wq] root 9 0.0 0.0 0 0 ? S 00:07 0:00 [ksoftirqd/0] root 10 0.0 0.0 0 0 ? I 00:07 0:23 [rcu_sched] root 11 0.0 0.0 0 0 ? I 00:07 0:00 [rcu_bh] root 12 0.0 0.0 0 0 ? S 00:07 0:00 [migration/0]  

I'm not an expert in this area whatsoever, but this problem looks like an upstream kernel issue, and perhaps is related to this fallback deadlock fix?  https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=a2715fbdc6fc387e85211df917a4778761ec693d
 
The posted fix patch is only applicable to kernel v5.10; just in case you want to give it a try, I've uploaded a ToT test build of v5.10-rc3 with this kernel patch applied:  https://drive.google.com/file/d/1Eg_cn3bEYsRFZ3vrP9Mc0fxJjPREczcW/view.  Again, I'm not sure if this will fix the problem, but there are a number of changes in cryptodev here compared to kernel v5.9, so it might be worth a try.

Hi,
Thanks for your work,
I tested your kernel packages yesterday and everything works flawlessly now. I get about 40 to 50 MBps throughput with Ipsec now without stalling and "breaking" the Interface.
 
I am happy, thanks alot!
 
Cheers
 
Ford Prefect
 

Board is here 
 

Was looking for a place to post a solution to this issue, but you guys have got there before me.As others have described, booting a (my) Pinebook with the latest version of Armbian (tried both Bionic and Buster) results in a blank screen seconds after boot.This is even after booting to multi-user.target when there should be no graphical display manager running.I got the latest kernel/version available for 19 and tried that (Kernel 5.4.62) and that worked.Previously I'd tried doing a full firmware upgrade, disabling the lightdm.service, setting the boot target to multi.user/3 and disabling the autologin (in case that had something to do with it) but under the 5.8 I got the blank screen each time.Not complaining here - just wanted to confirm I'd had the same issue.Love Armbian and all the great work that's being done - peace to all.
 
Manjaro ARM also does the same thing, by the way, so it's not just an Armbian issue

Platform : Kernel 5.9.5 Pine64+ A64 buster server
Analog sound working ! After a few days, i figure out the analog sound problem. There is a widget property in sound definition at sun50i-a64-pine64.dts file.  This mainly specifies audio off-codec DAPM widgets (Dynamic Audio Power Management for Portable Devices according to devicetree/bindings/sound/widgets.txt) In my case this widgets disable analog sound and i couldnt find a way to enable it I remove widget line and linked routing properties from dts file and rebuild it and it works. If you dont want to rebuild armbian alternate way is using a custom overlay.  Dont forget to unmute HeadPhone with "m" key and increase AIF1 DA0. I hope it will help to someone.  Unfortunately i could not enable microphone input, any ideas?? Thanks
sound_overlay.dts

I actually tried both - Debian works fine (as you noted), but Focal crashes just like I was seeing yesterday:
 
 
 

It works great ... THX


Envoyé de mon iPhone en utilisant Tapatalk

@Medapayne
create a /etc/asound.conf to get the analog audio card as default.
whats the output of
aplay -l
 
Mine:
 
___ ____ _ _____ / _ \| _ \(_) |__ /___ _ __ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_| | __/| | / /| __/ | | (_) | \___/|_| |_| /____\___|_| \___/ Welcome to Armbian 20.08.9 Buster with Linux 5.9.1-sunxi root@opi-zero(192.168.6.99):~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@opi-zero(192.168.6.99):~# more /etc/asound.conf pcm.!default { type hw card 0 device 0 } ctl.!default { type hw card 0 } and enable [*] analog-codec in armbian-config -> system -> hardware  

@Medapayne
create a /etc/asound.conf to get the analog audio card as default.
whats the output of
aplay -l
 
Mine:
 
___ ____ _ _____ / _ \| _ \(_) |__ /___ _ __ ___ | | | | |_) | | / // _ \ '__/ _ \ | |_| | __/| | / /| __/ | | (_) | \___/|_| |_| /____\___|_| \___/ Welcome to Armbian 20.08.9 Buster with Linux 5.9.1-sunxi root@opi-zero(192.168.6.99):~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Codec [H3 Audio Codec], device 0: CDC PCM Codec-0 [CDC PCM Codec-0] Subdevices: 1/1 Subdevice #0: subdevice #0 root@opi-zero(192.168.6.99):~# more /etc/asound.conf pcm.!default { type hw card 0 device 0 } ctl.!default { type hw card 0 } and enable [*] analog-codec in armbian-config -> system -> hardware  

NanoPi Neo3 could now ordered - but not with a metalic case. Dont know how it will heat up in there
https://www.friendlyarm.com/index.php?route=product/product&product_id=279&search=neo3&description=true&category_id=0&sub_category=true
 
And with this cas you couldnt use the 2 additional 2 USB 2.0 ports or fan-support.... which is available on the pin headers...

Great, Guidol!
 
Thank you very much for this good news. I wil try it out! Thanks for the one that solved the problem.
 

Of course, I know that debugging takes time. I'm just trying to provide developers with as many clues as I can to make their job easier.

I fully understand this, that quote was attribute to "No end-user support: built from trunk" wording in motd
 
I learned linux playing with these SBC's, mainly Armbian and it is a hobby for me. I have several installations at my home-office as hobby projects. If I ever earn some money from these stuff I'll donate it. But for this or helping others on the forums, I need to learn first  
 
Things like chroot environment, kernel parameters, kernel compiling are very new to me. The build script is very high quality code from my perspective. Last week, by examining it I learned a lot. For example the "wait_for_package_manager" function in general.sh provides solution for some of my problems. Kudos for @Igor and everybody contributed.
 
I'll try to "document" my adventure for other newbies.
 

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