[BPI-R4] and SFP

maybe a quirk or the phy driver needs to be patched to give more time?

hmm, maybe. I did not share one more detail: it happens when I connect device that is faster than 1Gbit. I have some other network cards or by connecting to w1700k via 10G port (it also have rtl8621) and such issue raises and that’s it. I can wait all retries, but nothing would change

So kernel/phylink does not support > 1G ? On 1g there is no issue with same sfp?

What does ethtool say?

even when I disable autoneg and ser 1 gbit, issue appears. Only connecting to old card that only have 1Gbit seems to work normally. Odd. Tomorrow will bring more details (/sys/class/net/sfp2/statistics/*errors; ethtool; etc.)

Thanks for help Frank.

EDIT: going back to vanilla (would be not sfp2 but sfp-lan), after connecting to w1700k via 10G, on BPi-R4 I have:

Sun Oct 19 21:57:28 2025 kern.info kernel: [  263.147530] mtk_soc_eth 15100000.ethernet sfp-lan: Link is Down
Sun Oct 19 21:57:28 2025 kern.info kernel: [  263.153775] br-lan: port 4(sfp-lan) entered disabled state
Sun Oct 19 21:57:28 2025 daemon.notice netifd: Network device 'sfp-lan' link is down
Sun Oct 19 21:57:32 2025 kern.info kernel: [  267.146473] sfp sfp2: module removed
Sun Oct 19 21:57:35 2025 kern.info kernel: [  269.730498] sfp sfp2: module OEM              SFP-10G-T        rev A    sn 202503260108     dc 250326
Sun Oct 19 21:57:35 2025 kern.info kernel: [  269.770402] hwmon hwmon3: temp1_input not attached to any thermal zone

3: sfp-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq master br-lan state DOWN group default qlen 1000
    link/ether e2:ae:de:4b:24:cc brd ff:ff:ff:ff:ff:ff

root@BPI-R4-NAND:~# ethtool sfp-lan
Settings for sfp-lan:
        Supported ports: [ FIBRE ]
        Supported link modes:   1000baseX/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  1000baseX/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: No
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: off
        Port: FIBRE
        PHYAD: 0
        Transceiver: internal
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err

root@BPI-R4-NAND:~# cat /sys/class/net/sfp-lan/statistics/*errors;
0
0
0
0
0
0
0
0
0
0
0
0
0

Interface is down, executing ip link set sfp-lan up does not do anything. Can not connect via wireless or get ip address via LAN port, only UART says something, but router is not usable. After reboot, no wireless, no error. Definitely some workaround is needed for that module, but maybe better just to change module to others.

I commented that in PR - phy-realtek: add rtl8251l, rtl8254b, rtl8261be, rtl8261n, rtl8264 and rtl8264b by balika011 · Pull Request #20450 · openwrt/openwrt · GitHub - but even on pure OpenWrt without that change, behavior is same.

tl;dr My SFP uses rtl8261, where not problematic modules uses: rtl8261N

So:

What mtk_soc_eth Expects:
* Fixed-link (no PHY)
* MDIO-connected PHYs (like MT7530)
* SFP modules — only if CONFIG_SFP=y and device tree has sfp {} node

But your RTL8261:
* Is not on MDIO
* Uses I2C only (bus 4, 0x56)
* Has non-standard ID (0xff13ff13)
* No driver support in Linux

So IIUC, it would require some hacks, edit DTS and build image for myself, edit mtk_eth_soc.c. I just bought wrong module. Hope someone else who also make a mistake will find answer quicker.

Edit: just to ensure, it is not possible to change somehow the phy id to be detected as rtl8261n? Like spoof/trigger somehow quirk responsible for rtl8261n? Kindly ping @ericwoud

So does it have an i2c-mdio bridge built-in?

Where is this info from?

Then you can directly use C22 or C45 on it, no need for rollball. Then 0x56 is the expected address. Do you also have something on 0x50 and 0x51?

I did not have done enough research in this topic, so I tried to get some answers with few AI. In the end, they give me similar summary, that might not be correct, that’s why I’m asking expert :slight_smile:

I added some information

So does it have an i2c-mdio bridge built-in?

if the value should be like:

root@BPI-R4-NAND:~# i2cdetect -y 4
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
``` than yes.

Did you pop open to see which rtl chip is inside?

If that was info from ai, never mind, it always makes stuff up when it doesn’t know.

1 Like

I did not open the sfp, but form the seller I know that it is RTL8261 (not RTL8261N). Don’t think he would lie :stuck_out_tongue: I never have time to increase knowledge related to SFP, that’s why asked AI…

It is ether BE or N?

Or just ask a refund…

Perhaps an i2cdump of 0x56 gives some more info.

After tear down it is… Rtl8261BE. Dump 0x56 will do tomorrow and share in this issue

Thanks for advice.

EDIT: I have done dump SFP module OEM SFP-10G-T based on RTL8261 will not work till dmesg reported "no PHY detected" · Issue #20294 · openwrt/openwrt · GitHub Wondering if correct channel or I miss something?

First set the interface (eth0/1/2) up, wait some time, then dump 0x56. Then you could see more then just FF.

If it is rollball similar to the other rollball modules.

So if rollball doesn’t work, try removing the fixup that recognizes this module and sets up rollball.

You may be able to use it, without phy register access.

1 Like