Jump to content

No network with 5.9.0-sunxi on Banana Pi M2 Berry


Go to solution Solved by Frank F.,

Recommended Posts

Posted

I know it's not an officially supported board, but it's been working really well so far, so I'll give it a shot.

 

Today I updated my kernel to 5.9.0-sunxi (coming from 5.9.0-rc7-sunxi) and after rebooting the (wired) network was dead. Everything looked fine, ethernet driver is loaded, interfaces were up and had IP addresses, but packets were not being sent. Pinging anything but the Banana Pi itself says "destination host unreachable". Routes were set and looked correct - even tho they should not even be necessary as I was pinging the gateway. tcpdump on eth0 showed nothing at all, almost as if the kernel doesn't know where to send the packets.

 

Anyone else having the same problem or any ideas what else I could try?

 

I did get the system back online by downgrading linux-image-dev-sunxi and linux-dtb-dev-sunxi, but that does not seem to me like a future proof solution. ;)

Posted

That was quick. I was looking to submit a PR, but I think that this commit reverts the original "fix" already, correct?

 

How do I find out if a new kernel package in the repo contains the commit?

Posted
1 hour ago, Werner said:

You can build a new kernel package from master branch using the build script. This will include @5kft's revert commit.

I did it and it does work :) 

-rwxr--r-- 1 datashare datashare    43652 Oct 17 17:58 armbian-config_20.11.0-trunk_all.deb
-rwxr--r-- 1 datashare datashare  6916332 Oct 17 17:58 armbian-firmware_20.11.0-trunk_all.deb
-rwxr--r-- 1 datashare datashare   192712 Oct 17 17:57 linux-dtb-dev-sunxi_20.11.0-trunk_armhf.deb
-rwxr--r-- 1 datashare datashare 35322316 Oct 17 17:58 linux-image-dev-sunxi_20.11.0-trunk_armhf.deb
-rwxr--r-- 1 datashare datashare   236608 Oct 17 17:48 linux-u-boot-dev-bananapim2berry_20.11.0-trunk_armhf.deb

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

Welcome to Armbian Buster with Linux 5.9.0-sunxi

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@bpi-m2-berry(192.168.6.20):~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.6.20  netmask 255.255.255.0  broadcast 192.168.6.255
        ether 02:53:bc:93:a8:02  txqueuelen 1000  (Ethernet)
        RX packets 329  bytes 35595 (34.7 KiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 315  bytes 35070 (34.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 37

  root@bpi-m2-berry(192.168.6.20):~# dmesg|grep eth0
[    8.326164] dwmac-sun8i 1c50000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
[    8.329007] dwmac-sun8i 1c50000.ethernet eth0: No Safety Features support found
[    8.329028] dwmac-sun8i 1c50000.ethernet eth0: No MAC Management Counters available
[    8.329037] dwmac-sun8i 1c50000.ethernet eth0: PTP not supported by HW
[    8.329052] dwmac-sun8i 1c50000.ethernet eth0: configuring for phy/rgmii link mode
[   10.454163] dwmac-sun8i 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

 

  • Solution
Posted

I just installed 5.9.0 from the 20.08.12 package and I can confirm it's working fine. The system came back with working network connection.

Thanks to everyone, esp. @Igor for finding the root cause and @5kft for getting the patch included so quickly.

Posted

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

Posted
12 hours ago, 5kft said:

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


I would say we remove revert and go with a mainline. Also possible to just wait since most of them are already changed https://groups.google.com/g/linux-sunxi and remove our patch once they reaches maineline?

Posted
1 hour ago, Igor said:

I would say we remove revert and go with a mainline. Also possible to just wait since most of them are already changed https://groups.google.com/g/linux-sunxi and remove our patch once they reaches maineline?

 

Yes, I agree - especially if this patch from @Icenowy makes it into the mainline: https://groups.google.com/g/linux-sunxi/c/QzBM7nciPLo.  We should wait for the dust to settle then can remove our revert patch and adapt the other DTs appropriately.  Thanks!

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

Important Information

Terms of Use - Privacy Policy - Guidelines