You can look in the git or read out sysfs in /sys/firmware/devicetree/base for the sfp nodes and then the milliwatts setting…same structure as in dts
You can try this tree as daniel added the missing parts
1 Like
@frank-w i’m trying to follow the tutorial here
so i indicated the dangole git link
and i’m geting some warning when i run ./scripts/feeds install -a
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/busybox/Makefile' has a build dependency on 'libpam', which does not exist
WARNING: Makefile 'package/boot/kexec-tools/Makefile' has a dependency on 'liblzma', which does not exist
WARNING: Makefile 'package/network/services/lldpd/Makefile' has a dependency on 'libnetsnmp', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a dependency on 'libpam', which does not exist
WARNING: Makefile 'package/utils/policycoreutils/Makefile' has a build dependency on 'libpam', which does not exist
well i go ahead, lets see what happen
So I took a bit of a closer look at the TL-SM410U 2.5G RJ-45 SFP module:
So unsurprisingly there is a RealTek 2.5G PHY (RTL8221B) and a microcontroller connecting to both the PHY and the I2C bus on Moddef2~3.
However, unlike with OEM SFP-2.5G-T module I had no luck accessing the PHY with @ericwoud’s patcheset. The normal MDIO access addresses are not present on the I2C bus:
root@OpenWrt:/# i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
As expected we got the EEPROM at 0x50:
root@OpenWrt:/# i2cdump 1 0x50
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x50, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 04 07 00 00 00 00 00 00 40 00 01 1f 00 00 00 ???......@.??...
10: 00 00 00 00 54 50 2d 4c 49 4e 4b 20 20 20 20 20 ....TP-LINK
20: 20 20 20 20 00 00 00 00 54 4c 2d 53 4d 34 31 30 ....TL-SM410
30: 55 20 20 20 20 20 20 20 31 2e 30 20 00 00 00 73 U 1.0 ...s
40: 00 18 00 00 31 32 31 35 34 4a 36 30 30 30 38 36 .?..12154J600086
50: 34 20 20 20 32 31 30 36 30 36 20 20 00 00 00 96 4 210606 ...?
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff 53 46 50 2d 54 0c 64 ff ........SFP-T?d.
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
0x51~0x53 return only ff, at least when accessing with read byte operation.
0x54 is a but more interesting and could be for RollBall access (but that doesn’t work, at least not with the 0xffffffff password hard-coded in the SFP driver in Linux)
root@OpenWrt:/# i2cdump 1 0x54
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x54, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
70: ff ff ff ff ff ff ff ff ce 00 00 00 00 00 00 ff ........?.......
80: 12 dc 00 ce 00 00 00 00 00 00 86 00 02 01 01 00 ??.?......?.???.
90: 84 ff 00 01 05 00 00 00 00 00 00 00 00 00 00 00 ?..??...........
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
The microcontroller is a Nuvoton N76E003AT20 which is on i8051 CPU with a bit of flash, RAM, I2C, UART, SPI, PWM, ADC, …
So unless we get some help, are lucky guessing or manage to extract the content of the flash memory of that uC it will be difficult.
Looking at i2c addresses, this is quite different. Guess this won’t be RollBall…
Did you try all of the mdio-i2c protocols?
MDIO_I2C_MARVELL_C22,
MDIO_I2C_C45,
MDIO_I2C_ROLLBALL,
But the other protocols assume that there is something present at 0x56… (SFP_PHY_ADDR =22)
I would try each and see if any valid ID is found in this code:
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
{
struct phy_c45_device_ids c45_ids;
u32 phy_id = 0;
int r;
c45_ids.devices_in_package = 0;
c45_ids.mmds_present = 0;
memset(c45_ids.device_ids, 0xff, sizeof(c45_ids.device_ids));
if (is_c45)
r = get_phy_c45_ids(bus, addr, &c45_ids);
else
r = get_phy_c22_id(bus, addr, &phy_id);
if (r)
return ERR_PTR(r);
/* PHY device such as the Marvell Alaska 88E2110 will return a PHY ID
* of 0 when probed using get_phy_c22_id() with no error. Proceed to
* probe with C45 to see if we're able to get a valid PHY ID in the C45
* space, if successful, create the C45 PHY device.
*/
if (!is_c45 && phy_id == 0 && bus->read_c45) {
r = get_phy_c45_ids(bus, addr, &c45_ids);
if (!r)
return phy_device_create(bus, addr, phy_id,
true, &c45_ids);
}
return phy_device_create(bus, addr, phy_id, is_c45, &c45_ids);
}
EXPORT_SYMBOL(get_phy_device);
At least can see if mdiobus_read() or mdiobus_c45_read() is successful reading something for any of the protocols…
Also set a long delay
sfp->module_t_wait = msecs_to_jiffies(secs * 1000);
Some modules need like 25 seconds before the phy can be accessed at all…
But it may turn out, there is no protocol build in at all to access all mmd registers via i2c…
Does anyone here have a TL-SM410U working at 1Gbps ?
mine only support 2.5Gbps, so when i connect it to a 1Gbps nic, it doesn’t work.
root@OpenWrt:~# ethtool sfp2
Settings for sfp2:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/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: Yes
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Link detected: yesDid you connect it to 2.5Gbps ? That should work and then 1Gbps should also work, even though you cannot see it is supported. The module uses rate-adaptor mode to convert to lower speeds. The host has no idea which speed is really connected. This was also the case with the OEM module.
The TL=SM410U is however not supported by my ‘RollBall’ patch series, as the module does not have a RollBall controller to communicate with. Until now there is no know way to communicate with the rtl8221b on the module.
The module will work, or it will not, no refined control over it.
I suggest using the OEM SFP 2.5G-T module instead. Same PHY chip, but this has the RollBall controller on it and have full control over the PHY, once the patch set is applied…
Note: It will not work in a 1Gbps SFP cage (media-converter). It can connect with a 1Gbps connection on the other side of the cable.
yes, it works with my 2.5g NIC, but not with my 1G NIC.
When using my 1G NIC i can’t ping the BPI if i connect it to the TL-SM410U.
So, I got a TP Link TL-SM410U from eBay, from China today. I plugged it in to SFP1 and to TP Link TLSG108-M2 switch. The 2.5GB LED link status is lit, I am guessing this works? Have to get a USB-C 2.5GB Ethernet adapter for the laptop to test. Any recommended model that works with linux? I guess I can scp, or something, files back and forth to the BPI-R3 to test the speed?
How do I set port properties in OpenWRT? Jumbo frames, MTU, lock port speed, etc. ?
I have used the rtl8156, bought it from:
Works ok, can manually change to 1000, 100 and 10, set it to auto for 2500 (somehow not manually). Also doubt if it reports all advertisements of link partner correctly, but this could have been my own experimenting to blame…
As for sfp module and linux/openwrt support I really suggest to use the OEM 2.5G module, instead of the tp-link one. The OEM module has RollBall protocol mdio-i2c bridge, so every register of the PHY is accessible, just as if it is a fixed PHY on the board. (Of course I recommend this one as I patched the driver accordingly) The tp-link has the very same PHY chip, but until now, no means to access it directly. Maybe someone figures it out at one time, if at all possible. But with an even cheaper alternative, I guess nobody will put much effort in that.
1 Like
I have a RTL8156b too,bought on amazon
I guess you can set options in openwrt with ethtool too.
1 Like
I use this on my macbook air D-Link DUB-E250
For reference connected to the OEM 2.5G sfp module on the bpi r3 defult setting on openwrt
Laptop, ubuntu 23.04, performance similar to the internal 2.5gb NIC only difference is with a higher ping.
1 Like
It would seem DUB-E250 is also a rtl8156. You could check with dmesg
Yes, is realtek rtl8156.
dmesg | grep -i USB
[ 25.074649] usb 4-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 25.096455] usb 4-1: New USB device found, idVendor=2001, idProduct=b301, bcdDevice=31.00
[ 25.096467] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=6
[ 25.096471] usb 4-1: Product: DUBE250 2.5GbE Adapter
[ 25.096474] usb 4-1: Manufacturer: D-Link
[ 25.096476] usb 4-1: SerialNumber: 001000008
[ 25.154653] usbcore: registered new interface driver cdc_ether
[ 25.184236] cdc_ncm 4-1:2.0 eth0: register 'cdc_ncm' at usb-0000:00:0d.0-1, CDC NCM (NO ZLP), 78:98:e8:00:00:00
[ 25.184758] usbcore: registered new interface driver cdc_ncm
[ 25.193134] usbcore: registered new interface driver cdc_wdm
[ 25.198169] usbcore: registered new interface driver cdc_mbim
$ ethtool -i enx7898e8
driver: cdc_ncm
version: 6.2.0-33-generic
firmware-version: CDC NCM (NO ZLP)
expansion-rom-version:
bus-info: usb-0000:00:14.0-2
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
1 Like
Just received from Amazon:
The box says, chipset: Realtek RTL8156B
@dangowrt Did you find a way to open these SFP housings, without permanent damage? I have another module, which I would like to examine…
Seems it was quite easy to open it up. Somehow I found a SFP module with a RTL8213B inside. But I haven’t been able to figure out how to communicate with it. I’m afraid this is not supported also by the module.
I’ve ordered now a module with a Marvell 88E1111 inside to have a 1G SFP. The PHY should be accesable and supported by kernel.
Yes, those work great, I got a few AJYA and Finisar ones with Marvell 88E1111 PHY inside, for all of them the PHY gets detected.
@dangowrt I like your pics of the TL-SM410U. How did you open the case of the SFP? Is there a screw somewhere?
Relevant ICs are RealTek RTL8112B 2.5 PHY chip (as expected) and Nuvotun N76E003AT20 8051-compatible microcontroller. To find out how to access the PHYs MDIO bus we will need to somehow know the firmware inside the Nuvoton uC which will be difficult unless someone has a good idea…
Edit: Note that this is TL-SM410U Ver 2.0 (see label). I also got Ver 1.0 here but didn’t take it apart (yet).
1 Like