@j_g
can you help check, when bpi-r4 boots up with your EEPROM hack. Does S800E report usxgmill mode or does it automatically switches to 10gbase-R?
[ 11.484218] mtk_soc_eth 15100000.ethernet eth1: switched to inband/10gbase-r link mode
[ 13.704939] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
[ 13.754367] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
I had to change phy-mode for sfp1 from usxgmill to 10gbase-r for the link to be up and working.
root@OpenWrt:~# dmesg | grep eth0
[ 4.236230] mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc082700000, irq 106
[ 4.506944] mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
[ 5.443141] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 5.451281] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[ 13.219595] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[ 13.241731] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 13.249895] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[ 13.284181] mtk_soc_eth 15100000.ethernet eth0: entered allmulticast mode
Edit1: I can’t confirm if eth1 is the right interface, but here are the logs:
root@OpenWrt:~# dmesg | grep eth1
[ 4.245908] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc082700000, irq 106
[ 11.713076] mtk_soc_eth 15100000.ethernet eth1: switched to inband/10gbase-r link mode
[ 13.375314] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
Edit2: might be better to show both interfaces, here’s dmesg after a fresh reboot
root@OpenWrt:~# dmesg | grep mtk_soc_eth
[ 4.223854] mtk_soc_eth 15100000.ethernet: generated random MAC address 65:74:68:25:64:00
[ 4.236265] mtk_soc_eth 15100000.ethernet eth0: mediatek frame engine at 0xffffffc082780000, irq 106
[ 4.245957] mtk_soc_eth 15100000.ethernet eth1: mediatek frame engine at 0xffffffc082780000, irq 106
[ 4.255617] mtk_soc_eth 15100000.ethernet eth2: mediatek frame engine at 0xffffffc082780000, irq 106
[ 4.504808] mtk_soc_eth 15100000.ethernet eth0: entered promiscuous mode
[ 5.439328] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 5.447496] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[ 11.711799] mtk_soc_eth 15100000.ethernet eth2: switched to inband/10gbase-r link mode
[ 11.749734] mtk_soc_eth 15100000.ethernet eth1: switched to inband/10gbase-r link mode
[ 13.225263] mtk_soc_eth 15100000.ethernet eth0: Link is Down
[ 13.247536] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 13.255730] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control rx/tx
[ 13.289913] mtk_soc_eth 15100000.ethernet eth0: entered allmulticast mode
[ 13.381128] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/10gbase-r link mode
[ 13.424071] mtk_soc_eth 15100000.ethernet eth1: entered allmulticast mode
[ 13.431098] mtk_soc_eth 15100000.ethernet eth1: entered promiscuous mode
[ 13.476204] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/10gbase-r link mode
[ 13.518961] mtk_soc_eth 15100000.ethernet eth2: entered allmulticast mode
[ 13.525880] mtk_soc_eth 15100000.ethernet eth2: entered promiscuous mode
[ 15.624827] mtk_soc_eth 15100000.ethernet eth2: Link is Up - 10Gbps/Full - flow control off
wrt gpio-hog being stuck as an input, I can’t think of any answers at the moment. I don’t see the same pin used anywhere else, and output-low seems pretty explicit. I can only suggest an uglier hack (inserting it as a led in gpio-leds with default-state = "on"; with GPIO_ACTIVE_LOW)
eth2 is sfp1 or sfp-wan. From your dmesg, it automatically switches to 10gbase-r. I have a suspicion going to test it out. I am still extremely curious on why i2c can’t read S800E eeprom!
eth2 is the mac for left sfp (wan) eth1 is mac for sfp (lan) between wan-sfp and rj45 ports
Random address is normal as the macs not having an address burned into efuse or board. Fixed mac has to be done in software by reading from a file or from eeprom or similar
“A vicious circle, the module cannot change the mod-def0 signal from HI to LO because there is no power. BPI-R4 cannot supply power because mod-def0 HI.”
“It cannot be circumvented by software. The logic is implemented via circuit, the software sees the module for a split second, and then it vanishes to never come back. The BPI-R3 had no such circuicy, and any other bit of SFP hardware I tested doesn’t either. The module only does not work in the stock BPI-R4. And given the circuit diagram for the R4 has a place for a brige in place of the mosfet drawn into the diagram, I highly assume this was at least to some degree accounted for. There are no ill effects to replacing the mosfet with a bridge. Other than the status LED being permanently lit.”
DOES work now (or is starting to work) through some software mods? No hardware modifications needed. Correct?
dm7000s: It’s a software hack that “works” with caveats, most important being that SFP presence detection through mod-def0 will not work so your mileage may vary.
glassdoor: I actually picked up the bpi-r4 after seeing this thread :P. I assumed that a simple bridge over the mosfet would solve the issue, and was definitely not expecting the i2c issues that we are facing now. So far I am unsure if its an issue with the bpi-r4 design, or on Huawei’s side with the S800E.
That being said, the 3.3V SFP power mosfet implementation is (imo) unusual. Being able to toggle power to the SFP module could be handy for resetting misbehaving modules, but the mosfet could be better served by a dedicated GPIO pin instead of being tied to mod-def0.
Btw I’m not sure what it’s like where you’re at, but if there are half-decent phone repair shops around you, they might be able to help you bridge the WAN mosfet for a few dollars? Should be easy for them (just show them the photos from this thread), and could possibly save you some headache.
for what it’s worth. bpi-r4 is the only piece of gear with sfp+ i have have tested that does not work with s800E. It works on edgerouter infinity(really old kernel), ms-01(intel x710) and quite a few 10G/2.5G switches that have graced my test bench. All of them works except bpi-r4. For kicks i even tried it on a asus rt-be88u’s sfp+ port a few days back. and it just works.lol
Power and reading S800E were never an issues except bpi-r4!
Actually before you came along. I had sort of written off bpi-r4 with the s800e.
For the man on the street, getting the mosfet removed and bridging it should be easy. As you said plenty of mobile shop will easily do it for a quick buck. But circumventing i2c requires building your own custom images and “fingers crossed” the can of worms that might have been opened in the process.
imho. Not recommened if the intension is to pair with S800E
Agree with you that in its current state, the bpi-r4 isn’t ready yet.
For the other devices that you tried that works successfully with the S800E, does any of them rely on sfp.c? If I understand right, sfp.c will halt on a bad EEPROM checksum which appears to be the case for the S800E. Perhaps the behavior in the sfp driver is a factor when initializing i2c.
(For myself, I am trying to use the bpi-r4 as my primary router, though my biggest gripe apart from the S800E issues is that I can only hit about ~6700Mbps before hardware offload, ~8200Mbps after hardware offload. Trying to figure out if the bpi-r4 is the bottleneck)
To me that’s actually great news. I don’t really like to modify/solder hardware if I don’t really have to. I already have the BPI-R4. And in the future I’d like to pair in with a XGS-PON ONU SFP+. Most likely this zaram one.
If it requires a quick hotplug/swap to start the ONU SFP+ or something like that (in addition to the software mod), that won’t be a problem. The BPI-R4 will be running as a router and will be left alone after it is up an running.
i don’t believe sfp.c was used in the other platforms I use. Even if they do the sfp.c is drastically different from the 4x kernels to the 6.x ones. Most will have resorted to proprietary sfp+ codes.
your 8.2Gbps is forwarding on your 10Gbps fiber connection? for xgs-pon based solution 8.2-8.3Gbps is actually the technical limit from what I read.
The hack documented for the S800E does not require swap or hotplug for it to work. And it will work with cold boot, warm reboot, sysupgrade. Well at least I have not seen a case in the last few days where it fails to boot up and come online.
Yeah 8.2Gbps is with forwarding. I did not know about the xgs-pon limitations, thanks for sharing. I assumed that 10Gbps would behave like regular gigabit ethernet (topping out at about 9xx Mbps, so I was expecting approx 9.x Gbps). In this case the bpi-r4 is routing just fine then.
If I get a chance to, I would like to stick the S800E on a sfp breakout, and manually drive it with a regular microcontroller to observe its behavior. I do not have the requisite hardware so that’s on the back burner for now.
Thanks for your suggestion. That’s a possibility, though the noise only appears on the bpir4 capture; the same sfp module on my mellanox card doesn’t exhibit this behavior, so I am wondering if there is some other hardware factors at work here.
I’m curious, does the zaram even start? If not, maybe you can try this solution from @glassdoor Maybe he can share a compiled image, which you could test?
I’d like to use the zaram for Delta or KPN in a few months (when I move to a new house). For now I’m using a cheap SFP (on my BPI-R4) for a Caiway connection. Works flawless.
I had to do some soldering but it shows now in dmesg. but now i have errors
something with the EEPROM. i,m busy trying to find out how to read and interpretate the data coming from the I2C bus but its really frustrating.
I want to use the Zaram for KPN., i have a 4 Gbit connection
I used another sfp+ to RJ45 module with ethernet and that worked flawless.
But this Zaram in combination with the BPI R4 is for me (noob old and windows man)
is undescribable frustrating.
