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
Hi, I have a R4 with 2 sftp in eth1 and eth 2. Both are sftp from fs.com
[ 14.444465] sfp sfp2: module FS SFP-GE-BX rev A0 sn F2130219083 dc 220922
[ 14.473257] sfp sfp1: module FS SFP-GE-BX rev A0 sn G2340772262 dc 240122
Partner link of eth1 is also a fs.com module. eth2 is connection to ISP.
Every time I reboot the router, eth1 connects, eth2 wont connect. The log fills up with:
[ 284.064453] mtk_soc_eth 15100000.ethernet eth2: Link is Down
[ 284.072404] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
The ethtool shows:
Settings for eth2:
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: 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: yes
So everything looks fine, link detected, partner adv. But no sigar.
After giving the next commands:
ethtool -s eth2 autoneg off
ethtool -s eth2 autoneg on
the sfp works without any problems.
I am running OpenWRT 24.10 trunk:
Linux bpir4 6.6.83 #0 SMP Tue Mar 25 08:52:55 2025 aarch64 GNU/Linux
In other threats I saw the suggestion ‘Force Link’, however this wont do the job. After reboot eth2 is not connecting.
Anyone any tips?
I had the same issue… Gave up and added the commands to /etc/rc.local so that they run at startup.
/usr/sbin/ethtool -s eth2 autoneg off /usr/sbin/ethtool -s eth2 autoneg on
Yes, looks like it. I dont think it is a BPIR4 problem, but a SFP problem. I had the same issue when plugged-in an original FS switch. I shall drop a question at FS.
Thanks for sharing the tip.
@frank-w @zerojj Hello, I have a G-010S-A that i’m trying to use with R4. The first time I plugged it in it showed a lot of “sfp sfp1: module removed” messages, so I did the solder trick that @zerojj mentioned, now it doesn’t output those messages, but I can’t connect to it. The sfp-wan interface stays at Rx packets:0, Tx packets:0 no matter what i do. It doesn’t respond to pings. Any ideas what to do wtih it?
dmesg messages:
[ 207.133355] sfp sfp1: module ALCATELLUCENT 3FE46541AA rev 0001 sn ALCLF96374BB dc 190722
[ 207.142754] sfp sfp1: Unknown/unsupported extended compliance code: 0x20
root@OpenWrt:~# uname -a
Linux OpenWrt 6.6.90 #0 SMP Thu May 15 08:09:40 2025 aarch64 GNU/Linux
root@OpenWrt:~# ethtool eth2
Settings for eth2:
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: 2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
link to aliexpress listing: https://www.aliexpress.com/item/1005007784094955.html?spm=a2g0o.order_list.order_list_main.5.68d81802zBQ1wf
Imho you need a link on it (fiber connected) before you can access the internal ip of the stick (and of course you need ip counterpart on r4).
Well for that to work i need to configure all the parameters from my isp’s ONT to this one. So that seems to be a chicken and egg problem. Do you know any workaround for that? I understand that i could do UART on these but i need to buy a sfp plug so i can wire my TTL adapter… that would mean another 2 weeks wait time from aliex for that. Maybe it’s a better idea to buy another sfp ONT entirely?
On some sfp this is triggered by the los gpio. In theory you can remap this via dt overlay to a pin on the gpio header you can manually set its value.
Does openwrt now have a setting for ignoring the los pin?
Afaik you cannot patch it in general because los detection some kind of security feature. If there is no rx signal the sfp should disable tx to avoid accidents when people looking into the transmitter.
But this can be manually and temprary changed (because linux requires a pin assigned to los property in dts) using devicetree overlay. I thought you have already done that…
Correct, we helped a user here to do that. But I would have thought openwrt may have some setting for this by now, but maybe not,