Werner

Thanks ! I will take a look later this weekend ...

I checked in a number of changes today into master that make it very straightforward to build sunxi w/kernel v5.9-rc2.  I have created a v5.9 development branch for sunxi in my repo that contains the current changes necessary for v5.9:  https://github.com/5kft/build/tree/v5.9-sunxi-development.  With the base mainline changes in master now only a few changes are needed to support v5.9.
 
With these changes, both sunxi and sunxi64 work in an initial state with v5.9-rc2.  There are still some things that need some cleanup (e.g., there's a sound driver issue and a few other existing patches that need to be cleaned up/merged), but overall it seems to be at a very good initial working point now.  From cursory testing of this on some NEO variants with several different Realtek-based USB Wi-Fi adapters all seems to work quite well.
 
I originally encountered some serious problems with the AP6212 Wi-Fi adapter (tested on a NEO Air and NEO Plus2) where Wi-Fi communication would randomly hang or stop.  I narrowed this down to the brcmfmac changes in this change in the kernel:  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47ec5303d73ea344e84f46660fff693c57641386.  I haven't debugged exactly what the issue is - I'm guessing it's something to do with the SDIO reset changes that were added, or perhaps there is an incompatibility with these changes and the current AP6212 firmware we're using.  However by reverting these specific changes to the brcmfmac driver back to the kernel v5.8.y version, the AP6212 Wi-Fi part works perfectly fine again, so I added a patch to revert the v5.9 changes to this driver.
 
@Igor, @martinayotte - any thoughts as to when we might want to move sunxi-dev to v5.9?  It's going to be in -rcX state for another month or so, so I'm not sure it makes sense to move from v5.8.y right away, but then again there's an appeal to being on the latest.  Interested to hear your thoughts!

If you want to start from scratch and have no important data on the device you could simply kill the partition table with dd and start over.

v20.08.1
Due to several - mainly small - problems in last build we are considering pushing out a smaller bug fix release.
 
- fixes that are merged in next 7 days (due = September 4th)
- all images will be rebuild
- an update will go out

Since 5.9 is ahead I'd suggest to focus on that since this will become next LTS kernel.

Any tutorial for Debian/Ubuntu on the web should suffice since there is no difference between Armbian and those on OS level.

This is an external driver catched from here: https://github.com/brektrou/rtl8821CU
Maybe some change there broke compilation for 4.9...

I wasn't updating index file until all files are present on all mirrors. Now I pushed index update which will take up to 24-48h (not sure since we are doing 1st time) to update all mirrors. If we would update all at once, people will be receiving errors - file not found - all the time ... updating index from server one, then redirector points to another mirror - where files are not yet - error. Now files are everywhere, but index is somewhere still old.
 
Anyway, things are in automated motion now.

Aaaaaaand it's out: https://www.armbian.com/newsflash/armbian-20-08-caple/

Aight, will do. I'll edit here once its finished.
 
https://werner.armbian.de/_extra/Armbian_20.08.0-trunk_Bananapi_focal_current_5.7.16.img.xz

Aaaaaaand it's out: https://www.armbian.com/newsflash/armbian-20-08-caple/

I do not have this board so I cannot test that.
I create a new image with generic joystick support and added all available models as modules. Let me know if it works.
 
https://werner.armbian.de/_extra/Armbian_20.08.0-trunk_Orangepipc_focal_current_5.7.16.img.gz
 

Did a quick check. xpad module seems to be missing in sunxi kernel configs while it is present in rk* und some other. I'll look into

I have absolutely no clue, probably banal reason. We had many other far more critical issues. I almost throw both N2 out of the window  

Armbian shows real speed, while hardware vendors (Amlogic not Hardkernel) are sometimes selling you bullshit.
 
 

TL;DR: the following is a simple summary of the issue:
 
Amlogic SoCs contain an own embedded microcontroller (Cortex-M3) used for controlling power and clocks A proprietary and closed source firmware is loaded on the M3 at boot. This stuff is contained in the bl30.bin blob we have to include This firmware controls the real clockspeeds, ignores what the cpufreq framework running in the Linux kernel wants and even reports back bogus clockspeeds (the kernel wants to set 1512 MHz, the M3 ignores this and sets 1416 MHz instead but the code returns faked 1512 MHz) Various tests showed that this is not related to thermal protection but just to $something we currently don't understand and out of our control Hardkernel are the only ones who managed to get a bl30.bin blob from Amlogic for their ODROID-C2 that does not cheat on us but honours the cpufreq framework, sets the wanted clockspeeds and also returns real and not faked cpufreq values. On all other Amlogic SBC situation is different  
 
 
Talking about 'not entirely honest' when it's about bold lies is funny
 
It's some proprietary crap that controls DVFS on Amlogic SoCs (a bl30.bin BLOB loading some firmware on the embedded Cortex-M3 which controls DVFS/cpufreq on its own) and Hardkernel is the only vendor that got this BLOB from Amlogic in a way where the installation does not cheat on you. In case the BLOB does also DRAM initialization (most likely) it should be hard to exchange it between boards.
 
https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=43338 (S912 and S905X are both known to cheat on the Linux kernel. The cpufreq values are all faked. Most probably this does also apply to all S905 devices except ODROID-C2 since Hardkernel managed to get a fixed BLOB from Amlogic)
 

sudo systemctl status apt-cacher-ng sudo systemctl stop apt-cache-ng sudo rm -rf /var/cache/apt-cacher-ng/* sudo systemctl start apt-cacher-ng sudo systemctl status apt-cacher-ng  

Not yet. I'll take a look this weekend. First days with the N2+ I had to wait for software to come. Now it's all coming at the same time and I ain't got the time. At least I know what to do. Cheers.

Thanks to Werner, I have a stable desktop on my Orange Pi 3 running the Armbian_20.05.4_Orangepi3_focal_current_5.4.45_desktop.img.xz (stable release).  MOD can put this elsewhere if it belongs in tutorials and not bugs.
 
Here is how to step through his fix for anyone new to linux (like myself).
1. After flashing and setting root and user, the user will be logged into the graphical Xfce desktop environment (DE) and will freeze soon.
2. On the next reboot you can try to use one of the separate terminals instead of the DE.  This is done by holding CTRL+ALT and selecting F1-F6
3. Quickly log into root account and type the following "sudo systemctl set-default multi-user"  This will disable the DE next time you load.
4. The system may freeze as the DE is being loaded, so its best to reset and log into the bash shell with root again.
5. We have to setup a shell script that runs every boot, as the files that Werner overwrites get replaced every time. We will edit/etc/rc.local
6. Goto "cd /etc/ " and chose your favorite editor.  I used vim, so I type "vim rc.local" to start editing.
7.  Add the lines that Werner posted earlier to the rc.local file 
cd /sys/devices/platform/soc/1800000.gpu/devfreq/1800000.gpu/ echo userspace > governor echo 756000000 > max_freq echo 756000000 > min_freq 8. Save and exit to shell.
9. last step is to enable the DE again, type "systemctl set-default graphical"
10.  Reboot and enjoy a stable desktop.
 
It took me about a day to have this working, mainly because of me not understanding the the GPU clock values were getting reset and not knowing unix commands & file structure.  It reminded me as a kid messing with the autoexec.bat on a ms-dos machine.  I am hoping to use an SDR and make this into a HD Radio Decoder (already built the NRSC-5 & GUI) , have it stream to an android head unit in my car & control via VNC.
 

I'm trying to understand the issue, but it seems rather bizarre.
 
Basically, when freeing the station_info structure in nl80211_send_station, kfree is called with a somewhat valid pointer, but then kfree (SLUB version) trips when calling PageCompound on the page of the provided pointer.
 
My best bet is that the structure isn't initialized correctly, leading some fields to be initialized with garbage values. However, it seems strange that everything goes without any bug until that specific point.
 
 
 

Ok, that clearly seems to be a badly initialized structure issue. Changing struct station_info sinfo; by struct station_info sinfo = {0}; in drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c : rtw_cfg80211_indicate_sta_assoc remove the BUG calls on a client connection.
Now, I'll have to test it in a real environment, to check if the Wifi connection works and is stable.
 
I'll post a clean patch tomorrow.

It seems that the actual install routine of Pihole doenst detect buster with kernel 5.8 correctly.
At "my" normal install command "curl -sSL https://install.pi-hole.net | bash" I did get
[✗] Unsupported OS detected: Armbian 20.08.0-trunk Buster https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems e.g: If you are seeing this message on a fresh install, you can run: 'curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash' If you are seeing this message after having run pihole -up: 'PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r' (In this case, your previous run of pihole -up will have already updated the local repository) but after giving (as written above) the install command with the option "to not check the OS"
curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash
the installation went fine  

You explain nothing about that command - good for you to know exactly what it does.

Does not work very well atm. Just tried with Bullseye on an OrangePi One. Chromium does not render any website at all (error code 256) and Firefox crashes when calling about:support....