Will test out your sfp1 moddef0 output low dt changes. The advantage is that dt are applied almost immediately on boot. rc.local happens much much later. So on a cold boot, the connection should come up much faster.
I expect speed and duplex to be negotiated successfully . But flow control will be on auto which will not work for sfp devices i tried previously. And given in my case both sfp are connected to 10G, I rather hardcode it.
No issues pushing line rate for forwarding. As there are 3 ppe engines one each of the gmac. I had previously tested pushing near line rate forwarding between both sfp+ ports on two relatively fast machines with iperf3 --bidir.
For traffic terminating at the bpi-r4, rss/lro are not available yet. So I am maxing out at 6.5Gbps+ on iperf3 receive on the device itself.
Also mtk has been active adding patches to the 6.6 kernel and happy days. HQoS was recently added. And from my limited testing it does improve latency on a 10G fiber thou only modestly as latency was pretty low already.
I canât tell if there is an issue with that entry, but maybe taking one step back would be to try with LEDs instead? Can probably change led_green to use the moddef0 pin instead, and switch it to GPIO_ACTIVE_LOW?
Also curious, in your working hacked devicetree, when the link is up, does anything respond on the i2c bus where the S800E should have been? Still scratching my head on why the S800E doesnât respond on i2c, but at least we can eliminate some possibilities such as bad power supply, or module held in reset.
You need to remove the gpio from the sfp part. But with overlay cannot delete. But you can overwrite the gpio of the sfp with an unused one. Then it is free to hog.
I donât think the polarity is as critical in gpio-hog, ultimately output-low is what we want to keep the mosfet active:
- output-low A property specifying to set the GPIO direction as output with
the value low.
I picked active_high out of habit, in this context, active_low is semantically better since a p-channel mosfet gate/output is inverting in a high-side switch topology.
However, if you are going to try using leds instead of gpio-hog, GPIO_ACTIVE_LOW will make a difference since it provides the polarity context to default-state = "on";
BUT it does not work as intended. this is with a warm boot with S800E already powered on and S800E lost power upon reboot.
gpio-594 ( |sfp1-mod-def0-power-) in hi ACTIVE LOW
And if i change to:
gpios = <82 GPIO_ACTIVE_HIGH>;
then
gpio-594 ( |sfp1-mod-def0-power-) in lo
the above is with a warm reboot with the S800E already powered up. the S800E continues to be power up. I did not test a cold boot as I am pretty sure the S800E will fail to boot up as direction is still input.
what is clear is that the âoutput-lowâ is not working as intended in both case.
Ideas?
current approach is to export gpio 594 and manage it from userland.
@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