Switching SUNXI-DEV to 5.9.y (h3-h5-h6/megous)


Recommended Posts

Armbian is a community driven open source project. Do you like to contribute your code?

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!

Link to post
Share on other sites
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 :)

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.)

Link to post
Share on other sites
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 :thumbup:

Link to post
Share on other sites
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.

Link to post
Share on other sites
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:

 

Link to post
Share on other sites
6 hours ago, Werner said:

  ___  ____  _    ___
 / _ \|  _ \(_)  / _ \ _ __   ___   _
| | | | |_) | | | | | | '_ \ / _ \_| |_
| |_| |  __/| | | |_| | | | |  __/_   _|
 \___/|_|   |_|  \___/|_| |_|\___| |_|

Welcome to Armbian buster with Linux 5.9.0-rc2-sunxi64

Nice.

 

 

:thumbup:

Link to post
Share on other sites
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).

Link to post
Share on other sites

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

Link to post
Share on other sites
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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...