Jump to content

Recommended Posts

Posted

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.

 

Posted

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!

Posted
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 ...

 

Posted
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 :)

 

Posted

I think we have to move current to 5.8.y asap and then whatever happens with DEV is fine for me.

Posted
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.

Posted
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.)

Posted
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 ...

Posted
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:

Posted
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.

Posted
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:

 

Posted

 

3 minutes ago, Igor said:

 

 

Anyone seen this:

 

Is this with 5.9 now?

Posted
Just now, Werner said:

Is this with 5.9 now?


No, that's current 5.7.y build.

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

Welcome to Armbian buster with Linux 5.9.0-rc2-sunxi64

Nice.

 

Posted
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.

Posted
6 hours ago, Werner said:

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

Welcome to Armbian buster with Linux 5.9.0-rc2-sunxi64

Nice.

 

 

:thumbup:

Posted
[ warn ] * [l][c] wifi-4003-fix-sha256_state-clashes.patch [ failed ]
[ warn ] * [l][c] wifi-4004-fix-cfg80211-for-5.8.patch [ failed ]

FYI

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

Posted
[ 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.

Posted
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 ...

Posted
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.

Posted
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).

Posted

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

Posted
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.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines