On Mon, Feb 06, 2023 at 11:35:50PM +0300, Arınç ÜNAL wrote:
On 06/02/2023 23:33, Vladimir Oltean wrote:
On Mon, Feb 06, 2023 at 10:41:47PM +0300, Arınç ÜNAL wrote:
One last thing. Specific to MT7530 switch in MT7621 SoC, if port@5 is the
only CPU port defined on the devicetree, frames sent from DSA master appears
malformed on the user port. Packet capture on computer connected to the user
port is attached.
The ARP frames on the pcapng file are received on the DSA master, I captured
them with tcpdump, and put it in the attachments. Then I start pinging from
the DSA master and the malformed frames appear on the pcapng file.
It'd be great if you could take a look this final issue.
What phy-mode does port@5 use when it doesn't work? What about the DSA master?
It's rgmii on port@5 and gmac1.
What kind of RGMII? Plain "rgmii" on both ends, with no internal delays?
With RGMII, somebody must add a skew to the clock signal relative to the
data signals, so that setup/hold times at the other end are not violated.
Either the transmitter or the receiver can add RGMII delays in each
direction of communication, but someone must do it, and no more than one
entity should do it.
So my question would be: could you retry after replacing phy-mode = "rgmii"
with phy-mode = "rgmii-id" on port@5? And if that doesn't change anything
(unlikely but possible), also try "rgmii-txid" and "rgmii-rxid" in port@5?
Don't change the phy-mode on gmac1.
Attachment:
rgmii-id.pcapng
Description: application/pcapng
Attachment:
rgmii-rxid.pcapng
Description: application/pcapng
Attachment:
rgmii-txid.pcapng
Description: application/pcapng