No problem, if you can point out where the magic numbers are in this datasheet.
I’ll save you from searching through it, the nummers are not in this datasheet. They are in another document, also as magic numbers, not labeled.
No problem, if you can point out where the magic numbers are in this datasheet.
I’ll save you from searching through it, the nummers are not in this datasheet. They are in another document, also as magic numbers, not labeled.
Thanks for checking.
Seems this version of datasheet is the only version I could find while searching… So we have to still use magic numbers.
Hi,
No “rollball” is found on my OEM SFP-2.5G-T device. The SFP works fine if i undo the rollball fixup back to the quirk. Maybe my SFP uses a different phy?
i2cdump -y 0 0x56
No size specified (using byte-data access)
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 10 00 79 49 4f 51 ea 19 11 e1 00 00 00 64 20 01 ?.yIOQ????...d ?
10: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 20 00 ..?........... .
20: 00 62 00 00 00 00 00 00 08 2c 00 00 00 00 00 00 .b......?,......
30: 00 00 00 00 00 00 00 00 00 00 00 00 a0 00 00 00 ............?...
40: 09 40 41 c9 4f 51 ea 19 00 20 00 00 00 00 00 00 ?@A?OQ??. ......
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 ..............?.
60: 00 00 20 02 00 04 00 00 70 28 00 00 00 00 00 00 .. ?.?..p(......
70: 00 00 00 00 00 00 00 00 00 00 00 00 30 fc 80 01 ............0???
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 ................
Whereas someone else saw this: At offset 4 it has: 0x001cc849 , which means that we have this PHY at 0x56:
PHY_ID_MATCH_EXACT(0x001cc849),
.name = "RTL8221B-VB-CG 2.5Gbps PHY",
I see offset 4 has: 0x4f51ea19 instead of 0x001cc849 so I need to find which PHY 0x4f51ea19 is.
ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x01 0x00 0x00 0x00 0x00 0x02 0x00 0x00
Transceiver type : SONET: OC-48, short reach
Encoding : 0x05 (SONET Scrambled)
BR, Nominal : 2500MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 300m
Length (62.5um) : 200m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 850nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : SFP-2.5G-T
Vendor rev : 1.0
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : REDACTED
Date code : REDACTED
Hi, How did you know 0x4f51ea19 was a Motorcomm YT8821 ? Is there a list of IDs somewhere? Please can you point me to the url?
Does anyone know how to do a teardown on that, so I can look at the chips? I cannot get the thing apart.
Flip open lid with knife at the pins end.
The problem is that this sfp is also recognized as OEM SFP-2.5G-T where your current quirk breaks functionality.
See SFP interface does not work on you 6.9-rc branch · Issue #118 · frank-w/BPI-Router-Linux · GitHub
I will have a look, maybe do a different quirk / fixup based on seeing 0x4f51ea19 or not.
Google,…
Horrible…
Are you sure it is the aocclink one? There is another user on the forum with one of this brand, but it has a slightly different ID.
Perhaps they are messing with the ID string, depending on the equipment you order it for…
Its not the aocclink one, but the metal casing looks identical, with no screws on it, or under the label.
No brand at all? No other label?
Where did you buy it?
What does/did the label look like?
New image is also working fine with my SFP. Thanks.
Thanks.
Because of the OEM SFP more then one type of PHY under the same vendor name/PN problem, I have submitted the patch-set, but only with 1 original module, not for OEM modules.
Anyway, first see if the patch-set gets accepted, then it is always possible to add fixups for other modules.
So I have received also a SFP module with the YT8821. However it is recognized with a different Vendor PN string:
Vendor name : OEM
Vendor PN : 2.5G-T-Y-RM
So the vendor is messing with the Vendor PN strings, using different values.
It would seem that it is only sometimes the same as other vendor and other hardware.
@ericwoud So it seems that using the Vendor name and Vendor PN is not very reliable. Maybe we should find some other method to base our quirks from? Would using i2c 0x56 offset 4,5,6,7 (The PHYS IDs) be better to base the quirks from? Does your YT8821 have 4f 51 ea 19 there ? I.e. Have the quirks based from an actually PHY ID detected, rather than what appears to be random OEM vendor names?