[BPI-R4] No link on 2.5G interface

This is mainline version of openwrt

@mkowalski I think we need to create a patch similar to what was done for mt76 - wifi txpower value is very low · Issue #17489 · openwrt/openwrt · GitHub . In short - BE14 owners might get a board with firmware on the board, so later the new firmware with better power regulations is ignored. I’m wondering if such a thing is possible also for 2.5G. WDYT @frank-w ?

Hi all, this is only to report that BPI-R4 2.5GbE is still not working in the latest snapshot. A bunch of outputs in case anyone wants to compare with theirs

# dmesg | head
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd090]
[    0.000000] Linux version 6.6.80 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 13.3.0 r28941-d8315d5358) 13.3.0, GNU ld (GNU Binutils) 2.42) #0 SMP Wed Mar  5 20:16:05 2025
[    0.000000] Machine model: Bananapi BPI-R4 2.5GE PoE

# dmesg | grep -i 2.5GbE
[   18.092491] MediaTek MT7988 2.5GbE PHY mdio-bus:0f: Firmware date code: 2024/10/30, version: 10.0
[   18.109579] MediaTek MT7988 2.5GbE PHY mdio-bus:0f: Firmware loading/trigger ok.
[   18.117844] mtk_soc_eth 15100000.ethernet lan4: PHY [mdio-bus:0f] driver [MediaTek MT7988 2.5GbE PHY] (irq=POLL)
# ls -l /lib/firmware/mediatek/mt7988/i2p5ge-phy-pmb.bin
-rw-r--r--    1 root     root        131072 Mar  5 21:16 /lib/firmware/mediatek/mt7988/i2p5ge-phy-pmb.bin

# sha256sum /lib/firmware/mediatek/mt7988/i2p5ge-phy-pmb.bin
643157e984732eccad6aa5e1f80a2be82a6cbf747aac25b54c75eefeccaf8aec  /lib/firmware/mediatek/mt7988/i2p5ge-phy-pmb.bin
# ethtool lan4
Settings for lan4:
	Supported ports: [ ]
	Supported link modes:   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:  100baseT/Full
	                        1000baseT/Full
	                        2500baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 15
	Transceiver: external
	Auto-negotiation: on
	MDI-X: Unknown
	Current message level: 0x000000ff (255)
			       drv probe link timer ifdown ifup rx_err tx_err
	Link detected: no

Have you tried 24.10.1 ? I’ running on the POE board and also no success. Really pissed that I got this thing, big waste of time.

Older poe version boards had a hardware error. Current boards working.

1 Like

why this problem was so hidden? I recommended this router to a colleague, he just chose the PoE version and now I simply have a distaste. Neither sinovoip company feels responsible for the replacement, nor is there any possibility of repair. If anyone is reading this thread, I think they will probably avoid sinovoip products in the future.

My last 5 cents here… The whole story is a disgrace to the whole open source community. I don’t want to dig whether it’s cultural to not be able to say “sorry we screwed up, this is what happens now”, but it’s simply what should have happened already a year ago.

Since September 2024 people with “banana-pi.org” email domain kept claiming “all is good my friend, all is good, we tested all is good”. Well surprise surprise, it is not :upside_down_face:

If someone wants to learn for the future, what should have happened is an RCA saying “hey folks, we just noticed the board model XYZ manufactured between XX/YY and XX/ZZ has hardware issue; to replace it please contact Jimmy”.

Because we are in the power-user community and we can assume there are people with more-than-average technical understanding, there should have been a second part saying “what happened is XYZ, we tried to fix it in software by doing ABC but we did not manage; as a result, we are changing DEF and it requires us to recall some boards”.

Anyway, good luck to everyone and I can only hope at least one person learned something from this mess.

1 Like

as the lack of answers from officials in the forum… it is good to have a forum but if it is only to let a few external users handing shitstorm…that looks like…we sold our shit and we don’t care! but by the way, we made another variant, are you happy!? :melting_face:

i understand this, and we thought it is a sw problem long time. We had no detailed cause or whats changed in later boards (i asked for it, but found no answer) but somewhere (i have not found it in quick search) in the last 2 Months there was stated, that earlier poe versions had such issue. i have only the phy variant and the poe module standalone (not soldered yet due to missing poe-hardware for testing). So just focused on getting the phy variant itself working also in mainline.

Remember that BPI-R4 is only PoE client (can be powered with PoE) not proving the power to any device.

Let’s assume that someone now uses a defective router as his main router and has to send it back and await a new one. What should he do during this time? What should he replace this device with? This is a bit of a frivolous solution. Here there should be an automatic shipment of the new device and a request to return the old one.

Mostly before a new router is used as main device it is be tested, or not? Then you had fallback with your old router. But i understand what you try to say :slight_smile:

Unfortunately i can only give the information that there was a hardware failure (was detected by daniel and confirmed by bpi in our non-public discussion),but we have no details yet. @simon can you give some insight? which boards are affected (which are good) and what was changed to solve the issue (maybe some users can do themself)?

Both of you folks are right, Dan and Frank, but the replacement process itself is an implementation detail whether you request customer to send defective device back first or “the amazon way” you ship the replacement first and await return of the faulty one. It’s not really the point of my rant here.

I have fallback device. Another guy in this thread may not have fallback device, not the point. If you enter the “open source router” space this is the risk you are taking.

How many people paid money for the dodged hardware? We don’t know. How many people who bought the dodged hardware were notified that what they bought is defective. Zero. You run the numbers yourself but seems like profit.

The rant is about the fact that unless you come to this forum here and start the shitstorm, manufacturer/distributor/seller will do nothing. When you are persistent enough, they will agree to the replacement. And fair, but at no point in time it was a rant about “oh no one wants to accept my return or replacement”, it was about “[…] in our non-public discussion” at which point the company behind BPI is no better than Cisco or pick-any-evil-company-out-there.

If we do open source, let’s do it. If we don’t, then let’s not pretend we do.

2 Likes