Hi Caleb,
On Tue, Feb 10, 2026 at 10:07:55PM +0100, Caleb James DeLisle wrote:
> Welp, that didn't take long.
>
> It turns out when I remove PORT_STAG on the receiving side (internal port
> 5), the switch mistakes the first 2 bytes of the stag for a length, and if
> the packet is actually shorter than that length, it drops. So 0004 worked
> fine, but 0104 didn't until I sent a longer packet.
>
> Clearing L2LEN_CHK on the AGC register works around the issue and packets
> are received in full with correctly stacked stags.
>
> If I can make the passthrough bit copy, or stop it from copying the port
> number when I have PORT_STAG set, that would be of course superior, but if I
> have to use the hack to get the feature then I'll send the patchset like
> that.
This whole arrangement is kinda similar to good-old MT7620 which also
had an on-die MT7530 with only FE ports and a single RGMII which can be
used to connected an external MT7530. In this case it is common to use
muxing to patch the external switch directly to the GMAC, as in that
case usually all other ports of the internal MT7530 are anyway unused.
The same should be possible on the EcoNet platform, but of course only
makes sense if there are either two GMACs which are both connected to
the in-die switch with one of on a port of the on-die MT7530 which can
be muxed directly to the TRMGII connecting the MCM MT7530.
This obviously has the disadvantage that traffic between the two switch
instances will then have to go via the CPU, but if PPE offloading is
similar to that in MediaTek SoCs it could be offloaded and at least not
waste CPU cycles (but still compete for the limited bandwidth with
traffic from/to WiFi or PON interface).
The main question whether it makes sense to use muxing to directly patch
the MCM MT7530 to a GMAC (if possible at all) is kinda how many TP PHY
ports the whole package got and how they are commonly used.
Cheers
Daniel
>
> Thanks,
>
> Caleb
>
>
> On 10/02/2026 20:25, Caleb James DeLisle wrote:
> > 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
