Sure, but I do not know when. Daniel signed off, so I thought he did…
So it turns out there are 2 issues uncovered:
-
After the ip link up command an-mode is stuck at MLO_AN_INBAND. Only after re-triggering mac configuration, MLO_AN_PHY is set.
-
The pcs should report it’s link status, regardless of inband status/negotiation being enabled or disabled…
Both issues are resolved with:
This is not actually a real solution, but we can use it until there is a real solution.
1 Like
Hi,
Will Ubiquiti SFP module “UF-SM-1G-S” (1000baseT) work with BPI-R4? Right now, module is not detected when inserted: sfp sfp1: failed to read EEPROM: -ENXIO
On BPI-R3 this module works fine.
Any pointers on how to get it working, if possible?
Never mind, it seems I’m running into issue where I have NVMe drive installed which interferes with i2c as explained here:
Hi mate! We are in a same boat with this ONU sticks.
[ 11.953993] sfp sfp1: module ALCATELLUCENT 3FE46541AA rev 0001 sn ALCLF924026B dc 200614
[ 11.963465] sfp sfp1: Unknown/unsupported extended compliance code: 0x20
root@OpenWrt:~# ethtool sfp-wan
Settings for sfp-wan:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/Full
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: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseX/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
If you are also going to make a 6pin mod on the new stick, I advise not to disassemble it completely, but to bend only a small metal part (it is initially bent inward, but with a small screwdriver and pliers you can bend it back and get enough space to access the resistors in the second square). I also used low-temperature solder paste (it contains solder), applied it with the tip of a screwdriver and in one touch with a sharp tip of a soldering iron everything was ready.
My module also has Chinese firmware installed, it allows changing ONU parameters via the interface and with it, 2.5 gbe worked on my Broadcom BCM with a patch. I don’t think that the firmware affects the ability to detect from the BPI-R4 side. The only difference is that I can’t read information about temperatures and voltage, while information about the optical connection is displayed (the link is still ‘no’, but the laser power is displayed)
Can you please share an image of what exactly you did there and maybe a link to the solder paste?
Thanks 
Sure, you need to bend the plate, I have circled it with an oval in the photo. It is flexible, first bend it with a small screwdriver, and then pick it up with pliers. Your task is to free up a little space near the second square, I have circled them in another photo. There are 2 resistors, 4 contacts in total, you need to solder all 4 of these contacts together (a drop of solder on them)). I just applied the paste and in two touches of the soldering iron it all soldered, you can see this drop in the photo. Soldering paste from Ali, I bought it a long time ago, I can’t find the link, but I am attaching a photo of the packaging, the price is definitely less than $ 10
Which kernel version/distro are you using?
Even after soldering, my Zyxel PMG3000-D20B just disappears with kernel 6.6 (OpenWrt 24.10/snapshot). In the final 6.1 snapshot build it’s still present but bugged (details). It appears fine with the original 21.02 @ 5.4.271 Sinovoip build.
Linux OpenWrt 6.6.74 #0 SMP Wed Jan 29 20:51:54 2025 aarch64 GNU/Linux
**plug in**
[ 143.389798] sfp sfp1: mod-def0 0 -> 1
[ 143.393476] sfp sfp1: SM: enter empty:up:down event insert
[ 143.398954] sfp sfp1: SM: exit probe:up:down
[ 143.403249] sfp sfp1: mod-def0 1 -> 0
[ 143.406906] sfp sfp1: SM: enter probe:up:down event remove
[ 143.412384] sfp sfp1: module removed
[ 143.415956] sfp sfp1: SM: exit empty:up:down
[ 300.522914] sfp sfp1: SM: enter empty:up:down event dev_down
[ 300.528588] sfp sfp1: SM: exit empty:down:down
**ip link set sfp-wan up**
[ 304.136579] mtk_soc_eth 15100000.ethernet sfp-wan: configuring for inband/10gbase-r link mode
[ 304.145133] mtk_soc_eth 15100000.ethernet sfp-wan: major config, requested inband/10gbase-r
[ 304.153496] mtk_soc_eth 15100000.ethernet sfp-wan: major config, active inband/none/10gbase-r
[ 304.162008] mtk_soc_eth 15100000.ethernet sfp-wan: phylink_mac_config: mode=inband/10gbase-r/none adv=00,00000000,00007c00,000c7200 pause=00
[ 304.187056] sfp sfp1: SM: enter empty:down:down event dev_up
[ 304.192706] sfp sfp1: SM: exit empty:up:down
** ethtool -s sfp-wan advertise 0x20000000000 **
[ 330.004066] mtk_soc_eth 15100000.ethernet sfp-wan: major config, requested inband/1000base-x
[ 330.012511] mtk_soc_eth 15100000.ethernet sfp-wan: interface 1000base-x inband modes: pcs=03 phy=00
[ 330.021558] mtk_soc_eth 15100000.ethernet sfp-wan: major config, active inband/inband,an-disabled/1000base-x
[ 330.031916] mtk_soc_eth 15100000.ethernet sfp-wan: phylink_mac_config: mode=inband/1000base-x/none adv=00,00000000,00000200,00000000 pause=04
Though maybe this’ll get better when kernel 6.12 lands in OpenWrt and Frank W.'s fixes upstreamed to 6.14 can be applied on top. Though his dev repo seems to have wildly diverged. (I don’t understand the exact relationship between his & Eric W.'s dev repo to the upstream kernel, anyway.)
Hi, I have Huawei MA5671A, when I turn on the power, everything works fine… But after reboot, sfp does not start and shows an error
Sat Feb 1 20:25:04 2025 kern.info kernel: [ 16.823915] sfp sfp1: Host maximum power 3.0W
Sat Feb 1 20:25:04 2025 kern.info kernel: [ 16.828841] sfp sfp2: Host maximum power 3.0W
Sat Feb 1 20:25:04 2025 kern.err kernel: [ 17.140098] sfp sfp1: EEPROM base structure checksum failure: 0x7c != 0x00
Sat Feb 1 20:25:04 2025 kern.err kernel: [17.147067] sfp EE: 00000000: 03 04 01 00 00 00 00 00 00 00 00 03 19 00 00 c8 ................
Sat Feb 1 20:25:04 2025 kern.err kernel: [ 17.155790] sfp EE: 00000010: 00 00 00 00 40 40 42 40 40 41 00 00 00 00 00 00 ....@@B@@A......
Sat Feb 1 20:25:04 2025 kern.err kernel: [17.164510] sfp EE: 00000020: 00 20 20 20 00 00 00 00 46 00 11 10 41 50 00 00 . ....F...AP..
Sat Feb 1 20:25:04 2025 kern.err kernel: [ 17.173208] sfp EE: 00000030: 00 00 00 00 00 00 00 00 30 30 20 20 01 14 00 00 ........00 ....
Sat Feb 1 20:25:04 2025 kern.err kernel: [ 17.181893] sfp EE: 00000040: 00 00 00 00 00 00 00 00 70 bd d0 80 c0 ff ff ff ........p......
Sat Feb 1 20:25:04 2025 kern.err kernel: [ 17.190593] sfp EE: 00000050: 78 4c 8d 80 01 00 00 00 30 bd d0 80 c0 ff ff ff xL......0.......
Please tell me what to do with this!
Which fixes? I only try to upstream dts for r4,so basicly not much difference to current openwrt state. Network stack needs some driver patches first before ethernet/switch dts can be added.
Must have been my wishful thinking then, I’d simply hoped that these commits after 2024-10-25 (plus the two UART/efuse ones by Miłecki) contained a good chunk of the fixes. I take it they don’t?
Honestly I’m probably too bad at using git to get a grasp of your WIP/pending changes, I haven’t found a way to get something useful out of github’s compare, either. Would be neat to get an actual list of commits/diffs to work through so as to apply manually to OpenWrt (at least after 6.12).
The patches i posted are mainly patches adding basic support,only slightly changed to get accepted for mainline. There is no network part yet,also no sfp. Maybe i add sfps in next round,but without full network part (which is much work) it will not work.
The mt76 patch is for a bootup issue. Not related to tx limitation.
Good morning, now I have this 10GB xgs-pon 8311 WAS-110, I have chosen the web version that has openwrt firmware and it is very easy to manage the data that you have to enter, the banana pi does not recognize it,
root@OpenWrt:~# ethtool eth2
Settings for eth2:
Supported ports: [FIBER]
Supported link modes: 10000baseLR/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10000baseLR/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
0x0000: 03 04 01 20 00 00 00 00 00 00 00 03 64 00 14 c8
0x0010: 00 00 00 00 48 2d 43 4f 4d 20 20 20 20 20 20 20
0x0020: 20 20 20 20 00 00 00 00 53 50 50 34 32 35 48 2d
0x0030: 47 41 42 34 20 20 20 20 41 2d 30 31 04 f6 00 69
0x0040: 00 00 00 00 50 54 32 34 33 34 30 34 42 30 30 30
0x0050: 31 30 20 20 32 34 31 30 32 33 20 20 68 f0 05 11
0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0090: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0100: 5a 00 ce 00 55 00 d3 00 8c a0 75 30 87 8c 7a 44
0x0110: 75 30 00 00 6b 6c 00 00 ff ff 3d e8 ff ff 4d f0
0x0120: 07 cb 00 0b 06 30 00 0e 00 00 00 00 00 00 00 00
0x0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0140: 00 00 00 00 3f 80 00 00 00 00 00 00 01 00 00 00
0x0150: 01 00 00 00 01 00 00 00 01 00 00 00 00 00 00 b0
0x0160: 1c d8 83 e8 00 00 00 00 00 00 58 7b b0 78 02 00
0x0170: 05 40 00 00 05 40 00 00 00 00 00 00 00 00 00 00
0x0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
To make it work I will tell you how I have it set up, I bought this converter.
I put the 10gb xgs-pon in one and in the other a 10gb sfp+rj45, the speeds are 8gb both upload and download.
but I would like if there is the possibility of making it work directly.
thanks
I can only guess that the sfp takes some time to get ready like most of gpon/xpon modules,so you will need a quirk to let kernel wait for module init and then access eeprom
Good afternoon and thank you very much @franco-w the truth is that I had it for more than 5 minutes and I couldn’t access it and it still didn’t detect it.
so I bought the converter and in 30 seconds, it accesses the banana pi.
I will continue using this method, until more people have this type of xgs-pon and it can be solved.
as you can see the speeds are very good
thanks for your help
+
=
Good afternoon, I’ve been reading that link but I’m not clear on how to do it. If you have to solder, I’m not good at that, my pulse is a real disaster, if you have to touch the core, I have no idea how to do it.
That’s why, since it’s working great for me and from what I’ve read, the XGS-PON won’t be able to get any more out of the speeds it’s giving me, I’ll be stuck for now.
If someone finally implants the eeprom like mine, I always go through those threads in case there’s any progress, I’ll try the image out of curiosity.
But the price of the XGS-PON is too high to have to do any hardware correction, which is still not clear to me.
Thanks for the thread
Nobody says anything about soldering or changing hardware. Just read the (really small) posting from eric.
Good evening, thanks, since soldering wasn’t my thing,
I’ve been looking inside,
The only thing that comes up is gpon.
Apart from that, I don’t know what I should do.
Mine is xgs-pon, which is different. I’ve done a search and only 7 mentions of gpon come up.
Nothing about xgs-pon comes up in the search.
I might be missing something, but as I mentioned, I wouldn’t know what to do in the kernel.
Thanks for your help.
You should try adding a quirk like the one posted from eric with your vendor/product strings (you see them in bootlog,ethtool -m and in eeprom).
Of course you need to rebuild kernel/openwrt