Motorcomm YT8821 on SFP module

Banana Pi Router design
25

I guess, because, as long as the phy is not being attached by the kernel, there is no problem…

Because all vendors can change these values, this will become a more common problem with these OEM modules I think.

26

@ericwoud Maybe in the detection code in the kernel, have it detect Read Only 0x56, and treat all transceivers like that the same, ignoring the name fields. We could add module parameters to the sfp.ko module, so that a user could statically configure the quirk/fixup to use for each slot, bypassing any sfp auto-detect logic.

E,g, modprobe sfp type=0,1

0 meaning first sfp slot, use auto-detect

1 meaning second sfp slot, use quirk 1 etc.

Then users could select quirks without even needing to recompile the kernel.

We use that approach for the Linux Sound ALSA because new variants are arriving all the time, and it allows us to get the user sound working, until the permanent quirk is added for that specific motherboard.

27

Why do you need to lock the i2c bus? Just unbind the SFP device in /sys/bus/platform/drivers/sfp/. For example if your device is called sfp-1, you do

echo sfp-1 >/sys/bus/platform/drivers/sfp/unbind

You can list bound devices by listing the symlinks in that folder.

28

This is cool! Is this tool available for experiments?

29

The tool does just that now :wink:

30
31

Any news about this?

32

I have no news on the yt8821 nor the sfp module.

33

I noticed that some modules seems to fail to work without rollball quirk on current openwrt snapshot, any idea about it? @ericwoud

34

For Rollball it is a fixup, not a quirk.

Do you have a YT8821 module or a rtl8221b? This is the topic for the YT8821.

Maybe this for the rtl8221b:

But I do not use openwrt myself.

35

My module is rtl8221, and they are also 8221… That’s the weird thing,

Edit: found the problem, wrong br.nominal value settings

36

Hello, I would like to ask if that change would be helpful to improve sfp with motorcom chipset

37

Hi Dan,

We were not successful communicating with the phy on the sfp module at all. The author of the yt8821 driver has hardwired an yt8821 to the BPI-R3, he did not use a RollBall sfp module.

Perhaps Marek has made some progession, I do not know.

1 Like
38

Hey, Stupid question: is it possible to change somehow the SFP module that would be recognized not as OEM but that it contains yt8821? Another question: do you have also an issue with upload on that module? Is it possible somehow to improve usage of that module? On the BPI-R4, when I connect to the WAN interface, I have 940/940Mbit, but which SFP with yt8821 it is just 900/550Mbit

EDIT: I tried to change the module name from OEM to something else, like:

curl -LO https://github.com/ericwoud/i2csfp/releases/download/aarch64/i2csfp
chmod +x i2csfp
./i2csfp /dev/i2c-3  eepromfix -V OEM -N SFP-2.5G-T

Seems to be recognized same as earlier. If changing SFP module name can help, I will move discussion to another thread ([BPI-R4] and SFP or I2csfp - sfp debugging via i2c)

EDIT: For those who read and don’t know what to do, first you need to find a password to be able to change the value (via bruteforce). If you are lucky, no bruteforce would be needed.

39

Just changing the name will not help.

You could try fiddling with ethtool --pause parameters, see if any options will improve the speed.

40

Maybe it is not needed. Probably my ISP got some troubles. Today bandwidth seems to be normal. Sorry for the noise.

Edit: speed for upload is like 80% what I have on wan

41

Try testing it with a local connection using iperf3

42

Just curious: what system are you using? Normally you should also be affected (I mean if you are using OpenWRT). By disabling sqm, I got 40% of the maximum upload bandwidth.

43

Archlinux Arm on BPI-R3 mostly

44

So definitely there is an issue with YT8821 and OpenWRT Snapshot (24.10) that is working on kernel 6.6.

For connection LAN<->WAN (network 1/1 Gbps, HW offload), I have 940/938Mbps (so it is correct).

For connection Wireless<->WAN(network 1/1Gbps, HW offload, WO disabled, AX, 160Mhz, 5GHz), I have 860/210Mbps (where testing network via iperf3 or librespeed-go that is running on the BPI-R4, for local connection I have 1640/1100Mbps, so definitely it is not wireless issue).

To get better performance, I can enable SQM with fq_codel + piece_of_cake, then the results are 908/730Mbps. I have done many speed tests, many tests even for dedicated servers - each time results are same.

So when I switch back to use port WAN (not sfp one), results are 915/890Mbps. I just want to share the results with others. Maybe it will help someone to avoid buying SFP with that chipset (for now).

EDIT: Found temporary “solution”: enabling flow control (ethtool -A eth2 rx on tx on) seems to improve upload, but download goes slower - I can accept that. Finally results after enabling flow control: 850/940Mbps

To make flow control enabled after upgrade:

cat <<EOF > /etc/rc.local
if ethtool -a eth2 | grep -i rx | grep -q off; then echo "Setting flow control..."; ethtool -A eth2 rx on tx on; ip link set eth2 down; sleep 2; ip link set eth2 up ; fi
exit 0
EOF