I believe this affects validating the connection between phy and mac.
I do set the port to TP in the patch-set, but it needs to be done here:
The patch-set from my stable branch is not the latest. The latest is branch net-next-realtek-phy-v4. I’ll see if I can update it in the rolling-stable branch, when I have some time for it.
…I cannot connect to your ftp server…
:: Synchronizing package databases...
ericwoud 32.1 KiB 18.9 KiB/s 00:02 [######################################################] 100%
core 229.1 KiB 70.6 KiB/s 00:03 [######################################################] 100%
extra 9.2 MiB 1440 KiB/s 00:07 [######################################################] 100%
alarm 57.3 KiB 129 KiB/s 00:00 [######################################################] 100%
aur 10.2 KiB 5.76 KiB/s 00:02 [######################################################] 100%
error: failed retrieving file 'ericwoud.db' from ftp.woudstra.mywire.org : Failed to connect to ftp.woudstra.mywire.org port 21 after 10002 ms: Timeout was reached
error: target not found: peekpoke-git
error: target not found: ssh-fix-reboot
error: target not found: hostapd-launch
headcrab@debian:~/code/buildR64arch$ ping ftp.woudstra.mywire.org
PING ftp.woudstra.mywire.org (128.242.250.155) 56(84) bytes of data.
^C
--- ftp.woudstra.mywire.org ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12281ms
I’m just trying it now, it seems to be ok. Maybe my internet provider had trouble, but this doesn’t happen very often.
Edit:
It would seem I have been moved my Ip number
Reply from 84.106.48.54
It has been resolved automatically by dhclient
I’ll make sure ethtool and i2c-tools are included in the next image…
I’ve created a fresh archlinuxarm image for the R3, it includes the latest patch-set for the module.
https://www.woudstra.mywire.org/images/
Or you could just use the old image and update the linux-bpir64-git package.
If you could both test your module with this patchset also, that would be great!
This patch-set is very different from the one you tried before, but the result should be the same. It is this version I’ll be trying to upstream soon again.
New image still works nicely. And speed manual override by ethtool also works:
[root@bpir3 ~]# ethtool -s lan4 speed 100 duplex full autoneg on
[ 359.425270] mt7530-mdio mdio-bus:1f lan4: Link is Down
[ 359.649321] brlan: port 6(lan4) entered disabled state
[ 363.639281] mt7530-mdio mdio-bus:1f lan4: No phy led trigger registered for speed(100)
[ 379.079286] mt7530-mdio mdio-bus:1f lan4: No phy led trigger registered for speed(100)
[ 379.079642] mt7530-mdio mdio-bus:1f lan4: Link is Up - 100Mbps/Full - flow control rx/tx
[ 379.095369] brlan: port 6(lan4) entered blocking state
[ 379.100511] brlan: port 6(lan4) entered forwarding state
Besides, you could change your patches to set actual register/bit names according to datasheet here rather than using magic numbers.
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…