All the update I got was “you could return […] we will inspect” ¯_(ツ)_/¯
In either case, you seem to get 2.5GbE without PoE which is not the same. I see 3 versions of this board in the wild
If you are lucky, only (3) is dodged.
Hi @mkowalski
I bought the #2
Are you saying, the problem (No Link) exists only on #3 ?
Please clarify when you get a moment. Appreciate it.
No, I cannot clarify any more details. @sinovoip should. They are the only ones to know the diff between PoE and non-PoE board and what could be the cause here.
All I can observe myself that boards with PoE expose the issue. Anything else is a pure speculation
Ok, thanks, I will keep you posted when I get it. (It will take a couple weeks since, it is coming from overseas)
I’m very very surprise, that nobody from @sinovoip @sinovoip1 did not reply in that thread. Such topic should be a prio for them. The customer, seeing that something does not work, begins to hesitate to buy it.
I contacted the seller about this issue and this is the reply I got
Hello, we currently only have a small number of customers who have such feedback. You can wait until your product arrives and then confirm. If there is really a problem, you can return it at that time.
So it is happening, but not sure if it affects everyone or small number of groups. unfortunately I cannot return the item since it is shipping from overseas from my relative house. I just have to live with it.
Are there any other functionalities are getting affected by this “No Link” issue? like m.2 / minipci-e etc…
but not sure if it affects everyone or small number of groups
I have my reasons to believe that “2.5 GbE with PoE” is the least spread model out there. So there is basically not enough data for us, community, to judge this.
If you ask myself, I can go and say “everyone with this board is affected”. If you go and ask support, they can go and say “it’s only one sample of a non-functional board”. So it’s very much word against word. Till now their only comment was “I have checked the issue on forum, but many customers use them and they work well” ¯_(ツ)_/¯
Anyway if anyone comes here from Google (for SEO: bpi-r4 2.5 g gbe poe) I could only recommend to hold on before proceeding.
Earlier in this post I noted that my BPi-R4 with 2.5 GbE but no PoE appears to work fine (OS build permitting). While any product can have random defects there doesn’t yet appear to be cause for panic about systemic problems. The PoE model has additional hardware & assembly complexity so possibilities for issues increase a bit. And yes, if you get a problematic board you’d have to deal with returns/exchanges. If this worries you perhaps you should consider where you buy from and perhaps look at Amazon instead of AliExpress for example. But you’ll likely pay more!
Right,
Unfortunately, I am in a country that Ali Express will not ship, so my options are limited. But I will keep you posted in a couple of weeks.
Hey @dangowrt, we started digging deeper with @danpawlik and the following patch series is on the table now – Linux-Mediatek patches - Patchwork
It is not merged upstream but at least from commit messages it does seem like this patch set may be required for the 2.5G PHY.
However, the patchset in the current form does not apply cleanly on top of 6.6.56. Can you please advise? We are not sure if the reason is that something has been partially applied already or that we are trying to build it incorrectly.
Your advice would be invaluable as this seem to be part of the code where you are fluent
The series you referenced has already been picked into OpenWrt long ago, which is why it cannot be applied again. It’s also the reason why the 2.5G port of all other MT7988 devices (I got MediaTek’s reference board as well as Adtran SmartRG SDG-8733A) work just fine.
See this patch in OpenWrt: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/mediatek/patches-6.6/733-11-net-phy-add-driver-for-built-in-2.5G-ethernet-PHY-on.patch;h=2548e789f065f47d25ea3bf5ae037c9e3af95a13;hb=HEAD
which corresponds to this patch on patchwork: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/
So what ever the reason is for it not to work on the BPi-R4-PoE, it’s not the missing PHY driver.
Also in the posted bootlog the PHY driver is being loaded and used.
So what could still be:
eth_2p5g_phy_mtcmos_ctrl() )Ok, small but important update. After additional rebuilds&tests I managed to get 2.5GbE PoE working on factory 21.0x image but without autoneg. The last bit is not very important as I do not really care.
Now additional attempts
So right now the one and only combination that works is the outdated factory image with autoneg manually disabled.
I have always tried autoneg off on openwrt builds, but looking at my own test matrix, factory image always ran with autoneg on.
Step by step, there is a remaining bit that I do not yet understand – why is master openwrt + mediatek feed not working.
The diff in ethtool is very clear and makes it obvious if the stack is healthy or not, i.e.
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
[...]
Port: MII
versus
root@BPI-R4:~# ethtool eth1
Settings for eth1:
Supported ports: [ ]
[...]
Port: Twisted Pair
(in the latter, there is no point in trying to configure speed&co. manually; it will not come up).
Do you see firmware load and phy detection on the working image? Please post related lines from dmesg/syslog
And please check of firmware version is same as in openwrt/mtk feeds
dmesg from Mediatek image - [BPI-R4] No link on 2.5G interface - #35 by mkowalski
And please check of firmware version is same as in openwrt/mtk feeds
Sorry for basic question but what exactly you check to confirm this? Are we talking only about i2p5ge-phy-pmb.bin or other stuff too?
Please also log from working one
Any difference in the logs. To maybe have a clue why one is working and not the other…i do not have the phy board…even if i could put my 2sfp board in same mode,i cannot test as my copper sfps have additional phys.
Hello everyone, I just wanted to give you guys an update I finally received my BpiR4 non-poe but 2.5 version. I booted up with default NAND boot and I can see it is up and running. I can see a through put of 2.35Gbits/sec using my 2.5G switch using iperf3
here is the dmesg output
root@OpenWrt:~# dmesg | grep eth1
[ 1.718592] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc011e80000, irq 14
[ 4.877034] mediatek_soc_hnat 15100000.hnat: lan2 = eth1
[ 15.672507] mtk_soc_eth 15100000.ethernet eth1: PHY [mdio-bus:0f] driver [MediaTek MT798x 2.5GbE PHY]
[ 15.681741] mtk_soc_eth 15100000.ethernet eth1: configuring for phy/xgmii link mode
[ 15.689747] br-lan: port 4(eth1) entered blocking state
[ 15.694999] br-lan: port 4(eth1) entered disabled state
[ 15.700411] device eth1 entered promiscuous mode
[ 15.705361] br-lan: port 4(eth1) entered blocking state
[ 15.710610] br-lan: port 4(eth1) entered forwarding state
[ 16.502418] br-lan: port 4(eth1) entered disabled state
[ 19.799214] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 2.5Gbps/Full - flow control rx/tx
[ 19.807858] br-lan: port 4(eth1) entered blocking state
[ 19.813094] br-lan: port 4(eth1) entered forwarding state
here is the ethtool output
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: MII
PHYAD: 15
Transceiver: external
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
I am planning to upgrade to current version of openwrt, I will keep you posted.
Ok, I tried the latest snapshot of openwrt ( as on 11/03/2024 ) r27995-57f2c72505 - kernel 6.6.58
All are good and up and running.
Hey @anavas, can you please show the same output (dmesg from around firmware loading and ethtool) from the OpenWrt? Mostly interested in “Supported ports” and “Port” fields as those are dodged in my OpenWrt.
Also, where did you source the OpenWrt? Image builder with default configuration or own build?
Here you go… I sourced my openwrt image from firmware builder with default config.
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: MII
PHYAD: 15
Transceiver: external
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd090]
[ 0.000000] Linux version 6.6.58 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r27995-57f2c72505) 13.3.0, GNU4
[ 0.000000] Machine model: Bananapi BPI-R4 2.5GE PoE
[......]
[ 5.773752] FIT: Detected U-Boot 2024.10-OpenWrt-r27995-57f2c72505
[ 5.779923] FIT: Selected configuration: "config-mt7988a-bananapi-bpi-r4-poe" (OpenWrt bananapi_bpi-r4-poe)
[ 5.789665] FIT: kernel sub-image 0x00001000..0x005b9f57 "kernel-1" (ARM64 OpenWrt Linux-6.6.58)
[ 5.799402] FIT: flat_dt sub-image 0x005ba000..0x005c584a "fdt-1" (ARM64 OpenWrt bananapi_bpi-r4-poe device tree blob)
[ 5.810960] FIT: flat_dt sub-image 0x005c6000..0x005c6609 "fdt-mt7988a-bananapi-bpi-r4-emmc" (ARM64 OpenWrt bananapi_bpi-r4-po
[ 5.827636] FIT: flat_dt sub-image 0x005c7000..0x005c711c "fdt-mt7988a-bananapi-bpi-r4-rtc" (ARM64 OpenWrt bananapi_bpi-r4-poe
[ 5.844137] FIT: flat_dt sub-image 0x005c8000..0x005c85c1 "fdt-mt7988a-bananapi-bpi-r4-sd" (ARM64 OpenWrt bananapi_bpi-r4-poe
[ 5.860466] FIT: flat_dt sub-image 0x005c9000..0x005c98f0 "fdt-mt7988a-bananapi-bpi-r4-wifi-mt7996a" (ARM64 OpenWrt bananapi_b
[ 5.878527] FIT: filesystem sub-image 0x005ca000..0x01028fff "rootfs-1" (ARM64 OpenWrt bananapi_bpi-r4-poe rootfs)
[ 5.889752] block mmcblk0p7: mapped 1 uImage.FIT filesystem sub-image as /dev/fit0
[ 5.897492] block mmcblk0p7: mapped remaining space as /dev/fitrw
[ 6.034033] mtk_soc_eth 15100000.ethernet: generated random MAC address 65:74:68:25:64:00
[ 6.046588] mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc082a80000, irq 106
[ 6.056283] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc082a80000, irq 106
[ 6.065959] mtk_soc_eth 15100000.ethernet eth2: mediatek frame engine at 0xffffffc082a80000, irq 106
[ 6.160466] mt7530-mmio 15020000.switch: configuring for fixed/internal link mode
[ 6.167974] mt7530-mmio 15020000.switch: Link is Up - 10Gbps/Full - flow control rx/tx
[ 6.196226] mt7530-mmio 15020000.switch wan (uninitialized): PHY [mt7530-0:00] driver [MediaTek MT7988 PHY] (irq=124)
[ 6.235412] mt7530-mmio 15020000.switch lan1 (uninitialized): PHY [mt7530-0:01] driver [MediaTek MT7988 PHY] (irq=125)
[ 6.273039] mt7530-mmio 15020000.switch lan2 (uninitialized): PHY [mt7530-0:02] driver [MediaTek MT7988 PHY] (irq=126)
[ 6.312779] mt7530-mmio 15020000.switch lan3 (uninitialized): PHY [mt7530-0:03] driver [MediaTek MT7988 PHY] (irq=127)
[ 6.323775] mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
[......]
[ 16.758442] MediaTek MT7988 2.5GbE PHY mdio-bus:0f: Firmware date code: 0/0/0, version: 0.0
[ 16.775079] MediaTek MT7988 2.5GbE PHY mdio-bus:0f: Firmware loading/trigger ok.
[ 16.783393] mtk_soc_eth 15100000.ethernet eth1: PHY [mdio-bus:0f] driver [MediaTek MT7988 2.5GbE PHY] (irq=POLL)
[ 16.793579] mtk_soc_eth 15100000.ethernet eth1: configuring for phy/internal link mode
[ 16.802854] br-lan: port 4(eth1) entered blocking state
[ 16.808085] br-lan: port 4(eth1) entered disabled state
[ 16.813335] mtk_soc_eth 15100000.ethernet eth1: entered allmulticast mode
[ 16.820244] mtk_soc_eth 15100000.ethernet eth1: entered promiscuous mode
OK, seems like it’s PoE module what makes a difference here, not 2.5G. Same dmesg for me, but ethtool output is dodged. Given it works on Mediatek’s 21.xx, I am still digging