Remove the above (managed = "in-band-status";
) from both 2.5G PHY sections if you want link status to come from the external PHY (rather than internal MT7986 SGMII SerDes PCS).
Thank you very much for your suggestion, now the eth1 port can work normally in 2.5g mode. Port lan4 (connected to mt7531 p5) log prints normally, but no network communication.
[ 63.205036] mt7530 mdio-bus:1f lan4: Link is Up - 1Gbps/Full - flow control rx/tx
[ 63.212535] br-lan: port 5(lan4) entered blocking state
[ 63.217760] br-lan: port 5(lan4) entered forwarding state
[ 63.223621] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Hey @Amadeus have you ever got lan4 to work?
With the Netgear WAX206 there's a similar situation where the (only) one RTL8221B is connected via Mediatek mt7530 switch, port5 (it's the WAN port). And although OpenWrt states in the log that everything is fine, the wan port isn't working at all.
Checking the Netgear OpenWrt 17.01 source code they added a patch which get's the RTL8221's IRQ and handles it as an extension of the mt7530.
/Thomas
Currently the port lan4 can only work normally when the link speed is 2.5G.
root@OpenWrt:/# ethtool lan4
Settings for lan4:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 5
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Link detected: yes
root@OpenWrt:/# ethtool -i lan4
driver: dsa
version: 5.15.71
firmware-version: N/A
expansion-rom-version:
bus-info: platform
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
This is the output of eth1 negotiated normally, seems to be related to auto-negotiation:
root@OpenWrt:/# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 7
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
Thanks a lot @Amadeus, it turned out that the RTL8221B configuration for the Netgear WAX206 was exactly like the Whitebox-X board @lynxis added.
It now works and the ethtool
output match yours. And we got the same limitation in that network traffic works only if the link speed is 2.5Gt.
If I change the phy-mode
for port@5 to 'sgmii' it works in all modes up to 1G ... but not higher.
ethtool
does report the correct link details in every case but no network traffic in some cases.
If phy-mode
is set to sgmii
for port@5 then ethtool
reports Supports auto-negotiation: Yes
. If set to 2500base-x
it's Supports auto-negotiation: No
.
I assume that's a software limitation. Although I'm not knowledgeable enough to know if 2500base-x
does allow auto-negotiation or not. Or if sgmii
should be able to handle 2.5G interfaces.
I solved this by porting the driver from WAX206 and setting the PHY to Rate Adaptor Mode and setting it to a fixed link in the device tree. You can see my post here.
If you are not using TP-Link XDR6086 or TP-Link XDR6088, you will need to change the PHY register number from my code because it just hardwired it.
Thanks, but these are a bit redundant. Do you know which registers to be modified to open the Rate Adaptor Mode?
IDK, sorry. I tried to consult Realtek FAE, but they said I should have NDA signed before getting the document.
Also this device will need proper support for interface-mode switching PHYs and also adapting in-band autonegotiation setting. I'm currently working on getting all this supported in upstream Linux and would appreciate review and testing. Once it's all upstream, we can backport to Linux 5.15 for OpenWrt.
work-in-progress tree is here:
(one of the) upstream submission(s) is here:
https://lore.kernel.org/linux-arm-kernel/cover.1675984550.git.daniel@makrotopia.org/
I also encountered this Phy on a Netgear WAX220. This device has a single ethernet port, but the Phy shows up as 0x00 and 0x06 for some reason.
Anyways, I'm struggling with the reset and getting the link. Apparently GPIO 5 and 6 somehow influence the reset. GPIO 6 makes both addresses disappear completely from the MDIO, GPIO 5 needs to be high in order to get a link. If I specify GPIO 6 as reset GPIO the Phy no longer gets a connection to my 1Gbit/s Ethernet card, the link simply stays down but the Phy shows up on the MDIO.
Any idea what might be going on and why I have 2 phy adresses showing up on the MDIO?
I think this may be the historical bug of realtek phy. On some router with mt7621 + rtl8211x, the realtek phy will preempt the phyad 0 of the mdio-bus, causing the port 0 of the mt7530 to fail to work. We don't need to pay attention to this on mediatek, it's not on the same mdio-bus as mt7531. So the actual address should be 0x6.
Thanks! Any idea why it doesn't get a link if I reset it properly? What I am trying right now is this:
ð {
status = "okay";
gmac0: mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
phy-handle = <&rtl8221b_phy>;
phy-mode = "2500base-x";
};
mdio: mdio-bus {
#address-cells = <1>;
#size-cells = <0>;
};
};
&mdio {
#address-cells = <1>;
#size-cells = <0>;
rtl8221b_phy: ethernet-phy@6 {
phy-mode = "2500base-x";
compatible = "ethernet-phy-id001c.c849";
reg = <6>;
reset-gpios = <&pio 6 GPIO_ACTIVE_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&pio>;
interrupts = <46 IRQ_TYPE_LEVEL_HIGH>;
reset-assert-us = <100000>;
reset-deassert-us = <100000>;
};
};
Edit: If I set the eth to sgmii and remove the phy-mode from the phy it gets a link again but no traffic going through.
Afaik many RealTek PHYs do that, address 0 is used as broadcast ("to all RealTek PHYs in the system") while in your case address 6 is the individual PHY.
There is also way to program the PHY so it won't answer to address 0 at all, but I currently to find the part in the documentation mentioning that.
Don't worry, it's not important. It was just weird seeing that. This unit has only the realtek on the MDIO bus, so it shouldn't matter at all. I only need to figure out how to make it forward data now....
@Amadeus I just tried your patch to see if it helps with this device aswell but that didn't help: No link if phy-mode = "2500base-x";
is specified, if phy-mode = "sgmii";
is specified there is a link but no traffic flowing.
For some reason when specifying
fixed-link {
speed = <2500>;
full-duplex;
pause;
};
for the gmac and remove the reset declaration from the phy it starts to work, even though I have the AP connected to a 1Gbit/s NIC. I am not seeing anything on any other MDIO address, so I assume there isn't a switch installed in this device? But what is doing the conversion between 1Gbit/s and 2.5 Gbit/s? The phy? And by resetting it I disable that feature?
You can disassemble the machine or use mdio-tools to confirm whether the switch exists. If you use fixed-link, the interface will be up by default, regardless of the actual situation.
I did disassemble it but didn't find any switch. It's a single ethernet port only, so a switch doesn't make sense. mdio-tools only shows 0 and 6, if 0 is the broadcast there's only the phy.
The fixed-link is the only way I can make it work: If I use sgmii I get a link but no traffic, if I use 2500base-x I get no link at all. I was hoping that maybe you have a clue why that could be the case.