No network with 5.9.0-sunxi on Banana Pi M2 Berry


Go to solution Solved by Frank F.,

Recommended Posts

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

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

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

 

Link to post
Share on other sites

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

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

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

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