dolphs Posted August 28, 2020 Posted August 28, 2020 Now that 5.9 will be released ( LTS early October / end September?) , DVFS is also present for H5 boards as well @megi provides his 5.9 branch so let's move on to this topic testing / patching/ building.
5kft Posted August 29, 2020 Posted August 29, 2020 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! 1
martinayotte Posted August 30, 2020 Posted August 30, 2020 2 hours ago, 5kft said: any thoughts as to when we might want to move sunxi-dev to v5.9? I'm usually don't try to switch to RCx, except if I have time to waste, so normally, I will switch DEV only when RCx are finished ...
5kft Posted August 30, 2020 Posted August 30, 2020 1 hour ago, martinayotte said: I'm usually don't try to switch to RCx, except if I have time to waste, so normally, I will switch DEV only when RCx are finished ... Makes sense. I'll keep my branch updated with the v5.9-rc versions, and then when v5.9 is released then the switch will be easy
Igor Posted August 30, 2020 Posted August 30, 2020 I think we have to move current to 5.8.y asap and then whatever happens with DEV is fine for me.
5kft Posted August 30, 2020 Posted August 30, 2020 3 hours ago, Igor said: I think we have to move current to 5.8.y asap and then whatever happens with DEV is fine for me. That was my original thinking, given that 5.7.y is EOL now... I'll go ahead and push my changes - current -> 5.8, dev -> 5.9. It would be great if someone could confirm H6 operation with 5.8 after this - I cleaned up all of this (it was messed up before), but I don't have an H6 board to test the changes with.
martinayotte Posted August 30, 2020 Posted August 30, 2020 1 hour ago, 5kft said: if someone could confirm H6 operation I've an OPi3 currently running 5.8.0 build done almost a month ago ...
5kft Posted August 30, 2020 Posted August 30, 2020 1 hour ago, martinayotte said: I've an OPi3 currently running 5.8.0 build done almost a month ago ... Great! Could you try it off of the master branch? I fixed the thermal and cooling maps and a number of other patch errors related to the H6. (Note that the "current" branch is now 5.8 and "dev" is now 5.9.)
martinayotte Posted August 31, 2020 Posted August 31, 2020 21 hours ago, 5kft said: Could you try it off of the master branch? Ok ! I will do some 5.9 builds for few of my Allwinner garden members ...
5kft Posted August 31, 2020 Posted August 31, 2020 35 minutes ago, martinayotte said: Ok ! I will do some 5.9 builds for few of my Allwinner garden members ... Great, thank you! I've tested across my corpus of boards, they are all H2+/H3/H5 (Orange Pi, Nano Pi, etc.) They all worked great
martinayotte Posted August 31, 2020 Posted August 31, 2020 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 ... 2
5kft Posted August 31, 2020 Posted August 31, 2020 Just now, martinayotte said: 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 ... Agreed - I did this locally as well and it worked fine. 1
Igor Posted August 31, 2020 Posted August 31, 2020 32 minutes ago, martinayotte said: 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 ... For this quick update I would skip it, then we just move it in. Anyone seen this:
Werner Posted August 31, 2020 Posted August 31, 2020 3 minutes ago, Igor said: Anyone seen this: Is this with 5.9 now?
Igor Posted August 31, 2020 Posted August 31, 2020 Just now, Werner said: Is this with 5.9 now? No, that's current 5.7.y build.
martinayotte Posted September 1, 2020 Posted September 1, 2020 My Allwinner garden tour using 5.9.y is almost finished ! Only 2 board models left ... 2
Werner Posted September 2, 2020 Posted September 2, 2020 ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.9.0-rc2-sunxi64 Nice.
RussianNeuroMancer Posted September 2, 2020 Posted September 2, 2020 On 8/31/2020 at 11:57 PM, Igor said: For this quick update I would skip it, then we just move it in. Anyone seen this: On resolutions above FullHD - yes. Seen on NanoPi-M1 and NanoPi K1 Plus. Issue is there even without installed DE, as far I remember.
5kft Posted September 2, 2020 Posted September 2, 2020 6 hours ago, Werner said: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian buster with Linux 5.9.0-rc2-sunxi64 Nice.
Werner Posted September 3, 2020 Posted September 3, 2020 [ warn ] * [l][c] wifi-4003-fix-sha256_state-clashes.patch [ failed ] [ warn ] * [l][c] wifi-4004-fix-cfg80211-for-5.8.patch [ failed ] FYI
martinayotte Posted September 3, 2020 Posted September 3, 2020 19 minutes ago, Werner said: FYI Those 2 patches worked fine 2 days ago for my 5.9.y builds (and also a month ago in 5.8.y) ... Is there something that changed since then ?
Werner Posted September 3, 2020 Posted September 3, 2020 [ warn ] * applying kali-wifi-injection-1.patch [ failed ] There is more. No idea about the cause. But did not really look into. Just noticed by chance.
piter75 Posted September 3, 2020 Posted September 3, 2020 1 hour ago, martinayotte said: Is there something that changed since then ? rtl8189fs was patched "upstream": https://github.com/jwrdegoede/rtl8189ES_linux/commit/0ba46e2434eec6f67d0712ed119a4ef8e05ccf91 I removed rtl8189fs from our patches for rockchip64 yesterday and propagated the change to other families about an hour ago. 1
martinayotte Posted September 3, 2020 Posted September 3, 2020 3 minutes ago, piter75 said: rtl8189fs was patched "upstream" Ah ! Ok ! So, we can trim my WiFi patches to keep only parts relevant to other drivers not provided by jwrdegoede ...
piter75 Posted September 3, 2020 Posted September 3, 2020 Just now, martinayotte said: we can trim my WiFi patches to keep only part relevant to other drivers not provided by jwrdegoede I did exactly that. Only for rtl8189fs, though, as rtl8189es still needs it.
martinayotte Posted September 3, 2020 Posted September 3, 2020 46 minutes ago, piter75 said: I did exactly that. Good ! Thanks !
5kft Posted September 3, 2020 Posted September 3, 2020 5 hours ago, Werner said: [ warn ] * applying kali-wifi-injection-1.patch [ failed ] There is more. No idea about the cause. But did not really look into. Just noticed by chance. Yes, one part of this patch is included in the v5.9 mainline upstream, so that particular part is rejected as it is already present. This patch is a general patch for all builds (it is present in patch/misc), so it's a little more work to address - e.g., it's a matter of splitting the patch and doing a kernel version check during the build. I simply haven't gotten around to addressing this yet in the build process (there's no impact because of this). 1
guidol Posted September 4, 2020 Posted September 4, 2020 Today I did compile Kernel 5.9.0rc2 dev (u-boot/dtb etc) for NanoPi Neo2 and after installing the .debs to the NanopI Neo2 it doenst boot anymore... Tomorrow(?) I have to get the Neo2 out of the NAS-Case and check with a serial-TTL what is failing Before this it was running kernel 5.8.3 Is there a way to "install" the debs from 5.8.3 to the card "offline"?
5kft Posted September 4, 2020 Posted September 4, 2020 1 hour ago, guidol said: Today I did compile Kernel 5.9.0rc2 dev (u-boot/dtb etc) for NanoPi Neo2 and after installing the .debs to the NanopI Neo2 it doenst boot anymore... Tomorrow(?) I have to get the Neo2 out of the NAS-Case and check with a serial-TTL what is failing Before this it was running kernel 5.8.3 Is there a way to "install" the debs from 5.8.3 to the card "offline"? It's hard to say what happened without seeing the boot process on console, and the contents of /boot. I've gotten in the habit of uninstalling the current kernel + dtbs before installing the new one in some instances (such as going from -current -> -dev or 5.8 -> 5.9), as by default if you just install the new one the old one won't get uninstalled, and the boot partition can run out of space. (I ran into this a lot as I was doing the work on v5.9...perhaps I should bump the /boot partition size up a bit more again...) One relatively straightforward way to recover from this situation is to use another card and install a fresh/bootable Armbian image onto it (/boot, /, etc.) Then simply copy over the rootfs contents from the old card over to the new card (/ partition), taking care to set the new rootfs UUIDs in /boot/armbianEnv.txt and /etc/fstab. You can use "--exclude" with tar to skip copying the contents of /dev/, /proc/, etc. I created a full backup process for my boards using this process. I could try to write up some instructions on how to do this if it would be helpful.
Recommended Posts