Hello guys,
I have an update on this MT7530. As I mentioned in my initial email
there are two switches that are stacked, so I'm needing to do quite a
bit of patching to mt7530.c to create anything that is going to work.
I'm trying to handle incoming traffic from the MCM ("external") switch
to the on-die switch. It comes in port 4 of the external, where I have a
cable attached, then goes to port 6 which the external is treating as a
CPU port. Then it comes in port 5 of the internal. Here's my values for
the PVC register:
ext 4 0x810001c0 ACC_FRM=all VLAN_ATTR=transparent EG_TAG=consistent
STAG_VPID=0x8100
ext 6 0x00000920 ACC_FRM=all PORT_STAG VLAN_ATTR=user EG_TAG=consistent
PT_OPTION STAG_VPID=0x0
int 5 0x810001e0 ACC_FRM=all PORT_STAG VLAN_ATTR=transparent
EG_TAG=consistent STAG_VPID=0x8100
int 6 0x00000120 ACC_FRM=all PORT_STAG VLAN_ATTR=user EG_TAG=consistent
STAG_VPID=0x0
When PT_OPTION is set on port 6 of the external, it sets the Passthrough
bit on the Special Tag before sending it to the internal switch. When
int 5 has PORT_STAG set, the Passthrough bit is required otherwise it
will drop STAG'd packets. However, when it's set the switch does a weird
stupid thing and it copies the port number from what was received from
the external switch - but it DOESN'T copy the passthrough bit. So you
end up with this:
[ port 4 ][ port 4 +PT ][ packet header ]
And the obvious problem is this is indistinguishable from a packet that
comes from port 4 of the internal switch and has an stag directly under
the eth header.
---
Another angle is to remove the PORT_STAG from internal port 5, and then
you get this:
[ port 5 ][ port 4 +PT ][ packet header ]
In that case you can also remove PT_OPTION from external port 6, but
sending ANY kind of VLAN packet from the outside gets it filtered and
RxFiltering gets incremented. No matter what I do, I can't figure out
how to stop VLAN packets from getting dropped except by putting
PORT_STAG on the receiving port (internal port 5). No configuration of
internal port6 prevents it, even if it's a dumb switch, is still drops them.
Anyone have any ideas?
Thanks,
Caleb
On 28/01/2026 14:26, Caleb James DeLisle wrote:
Update: It turns out the reset controller I was using only reset the
on-die switch, Benjamin found the reset register for the external
switch and now everything is behaving MUCH more like normal. I'd say
at this point I'm no longer stuck.
Thanks,
Caleb
On 27/01/2026 18:26, Caleb James DeLisle wrote:
Would there be any reason not to set BMCR_PDOWN in
mt7530_phy_config_init() so we know they're in a consistent state?
Also if you happen to have an MT7621 sitting there running, would
you mind setting BMCR_ANENABLE | BMCR_ANRESTART with mdio on a
running port to see if it's the same behavior? The port should
immediately die and then go into a loop trying to connect every few
seconds / minutes depending on what it's connected to.
Whoops, spoke too soon. dsa_register_switch() (indirectly) calls
phy_resume() so the phy is up while the port is down. However, adding
this to mt7530_port_enable() does make it work:
if (priv->id == ID_EN751221_EXT && phy)
genphy_soft_reset(phy);
I note that if the port is brought up within seconds of having been
reset, then it seems to work (at least sporadically) despite the
BMCR_ANENABLE bug. I imagine this is something that can be tuned out,
but given it's happening in the bootloader, I don't have much
confidence that I'm going to find the knob to fix it. I've got a
problem with my vendor OS image, but when I get that fixed I'll check
that as well.
In the mean time, if any likely culprits come to mind, do let me know.
Thanks,
Caleb
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
