Link seems to be broken, trying to find doc with the name
Ahh,Discourse overiddes it and forces https
ftp.mqmaker.com/WiTi/Docs/Software/MT7621_ProgrammingGuide_GSW_v01.pdf
1 Like
Thanks a million, robimarko! Section 2.20.2.2 looks like our section.
so far, no success. I tried both values 0 and 1 for bit 20 in 7804
[root@dory openwrt]# git diff
diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c b/target/linux/ramips/files-4.14/drivers/net/ether
index 9d5fe6e..ec6d53e 100644
--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c
+++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c
@@ -71,7 +71,7 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct device_node *np)
u32 i;
u32 val;
- /* wardware reset the switch */
+ /* hardware reset the switch */
fe_reset(RST_CTRL_MCM);
mdelay(10);
@@ -114,12 +114,22 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct device_node *np)
/* Set switch max RX frame length to 2k */
mt7530_mdio_w32(gsw, GSW_REG_GMACCR, 0x3F0B);
- /* Enable Port 6, P5 as GMAC5, P5 disable */
- val = mt7530_mdio_r32(gsw, 0x7804);
- val &= ~BIT(8);
- val |= BIT(6) | BIT(13) | BIT(16);
- mt7530_mdio_w32(gsw, 0x7804, val);
-
+ val = mt7530_mdio_r32(gsw, 0x7804);
+ val &= ~BIT(8); /* 0 = Enable Port 6 */
+ val |= BIT(16); /* 1 = change HW-TRAP */
+ mt7530_mdio_w32(gsw, 0x7804, val);
+
+ /* Port 5 setup */
+ val = mt7530_mdio_r32(gsw, 0x7804);
+ val &= ~BIT(6); /* 0 = Enable Port 5 */
+ val |= BIT(7); /* 1 = Port 5 interface mode: RGMII */
+ val &= ~BIT(13); /* 0 = Port 5 Internal PHY */
+ val |= BIT(20); /* 1 = Port 5 Internal GPHY0 */
+ val |= BIT(16); /* 1 = change HW-TRAP */
+ mt7530_mdio_w32(gsw, 0x7804, val);
+
+ printk("the cake is a lie 001 eth mt\n");
+
val = rt_sysc_r32(0x10);
val = (val >> 6) & 0x7;
if (val >= 6) {
root@OpenWrt:~# swconfig dev switch0 port 5 get link
port:5 link:down
this combination didn't work either:
/* Port 5 setup */
val = mt7530_mdio_r32(gsw, 0x7804);
val &= ~BIT(6); /* 0 = Enable Port 5 */
val &= ~BIT(7); /* 0 = Port 5 interface mode: GMII/MII */
val |= BIT(13); /* 1 = Port 5 connects to GMAC5 */
val |= BIT(16); /* 1 = change HW-TRAP */
mt7530_mdio_w32(gsw, 0x7804, val);
Few questions, I noticed when compiling that the AR803X did not get included in my build, even though I set it to enabled. Do you see the driver in your build?
Also, if you look at the very beginning of this post, the required functions in the driver to be able to read link status aren't in the driver, afaik.
So using ethtool or swconfig will not work for switch0 (mt7530), I imagine there has to be a new switch(1) that will be published once the "external phy" is able to be loaded as the AR803X. Or does this not make any sense?
I have been wondering about this for a while too. The MT7621 has two gmacs. One of them is connected to the switch, but the second might be connected to the AR8033. If this is the topology, then I'm afraid there is more work to do than a few quick hacks. See this message from blogic:
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg41853.html
1 Like
I tried to enable it, but there's no indication in dmesg that it recognized the chip. We discussed it with Robie yesterday: if I plug in or out the optical cable, the eth5 LED is correspondingly on or off. So, our guess is that AR8033 does not need to communicate with the CPU, and is doing its job by default. We only need to find a way to interface with its GRMII or GMII interface.
So far, I tried various combinations of registers on the switch to activate P5, but swconfig is always reporting the link down.
But: with the latest update as above, now the eth5 LED is blinking rapidly instead of a steady light. So, it seems like my manipulations did have some effect, but not totally successful.
As Bjørn indicated, there's still a possibility that the second GPHY on MT7621 is actually connected to AR3033. But how then would we explain this LED blinking now?
Unfortunately the stock firmware does not provide any indication on the hardware topology, and it's just showing the Ethernet interfaces. Robie has searched through the GPL part, but could not find anything relevant, so it seems to be a binary module speaking to the hardware.
I found this forum in Russian, and in message #378 the guy says he traced the wires on the board, and AR8033 is doing a dummy RGMII/SGMII conversion, and is directly attached to MT7621. So, we need to enable the second GE port on MT7621. I'll check, maybe I can do at least a proof of concept of what John is mentioning in Bjorn's link.
Awesome work researching.
Is that patch based on the driver used by OpenWRT?
nope, it's the same Russian guy producing his own firmware for a number of routers. Nothing related to OpenWRT, and the files are totally different from what we have in 4.x mainline kernel. I'm reading through to try to understand the logic, and I also wrote to the guy, maybe he would be willing to help a bit in pointing in the right direction.
Thats for the Padavan firmware, Andy Padavan the is the guy.
I remember searching for clues when I was reverse engineering Xiaomi R3.
But what he uses to me looks like is mostly based on Mediatek SDK with really old kernel.
Have you had a look at this:
Robi has sent me this excellent picture that actually completes the puzzle.
GPIO_MODE bit 15 needs to be set to 1 (GPIO for talking to AR8033)
GPIO_MODE bits 12:13 should be zero (already set in existing driver)
SYSCFG1 bits 15:14 should be set to 0 (GRMII mode on)
probably something else, need to look up in Padavan's driver.
1 Like
Here's a new version that doesn't work 
I need assistance in device tree configuration. I found that the other PHY should be at offset 00, but somehow the driver doesn't pick it up. Probably I did something wrong in the DTS.
diff --git a/target/linux/ramips/dts/UBNT-ERX-SFP.dts b/target/linux/ramips/dts/UBNT-ERX-SFP.dts
index 7de3780..c3becfe 100644
--- a/target/linux/ramips/dts/UBNT-ERX-SFP.dts
+++ b/target/linux/ramips/dts/UBNT-ERX-SFP.dts
@@ -22,3 +22,15 @@
};
};
};
+
+
+ðernet {
+ mdio-bus {
+ phy00: ethernet-phy@00 {
+ reg = <0x00>;
+ phy-mode = "rgmii";
+ };
+ };
+};
+
+
diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c b/target/linux/ramips/files-4.14/drivers/net/ether
index 9d5fe6e..75a0c7c 100644
--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c
+++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/gsw_mt7621.c
@@ -193,6 +193,13 @@ static void mt7621_hw_init(struct mt7620_gsw *gsw, struct device_node *np)
_mt7620_mii_write(gsw, i, 0, val);
}
+ /* enable RGMII2 in GPIO mode */
+ /* gpio mux - RGMII2=GPIO mode */
+ rt_sysc_m32(BIT(15), 1, SYSC_GPIO_MODE);
+ /* set GMAC2 RGMII mode */
+ rt_sysc_m32(3 << 14, 0, SYSC_REG_CFG1);
+
+
/* enable irq */
mt7530_mdio_w32(gsw, 0x7008, 0x1f);
val = mt7530_mdio_r32(gsw, 0x7808);
Hm,
MDIO and MDC clocks are also needed.
As well as defining GPIO pins that are used for that RGMII connection.
Also,there need to be some I2C to certain pins of the SFP
but that was for another driver. What bugs me, is that fe_probe in mtk_eth_soc.c was only called once. So, something is wrong with my DTS file:
diff --git a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/mtk_eth_soc.c b/target/linux/ramips/files-4.14/drivers/net/ethe
index d0d88b9..e8a1513 100644
--- a/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/mtk_eth_soc.c
+++ b/target/linux/ramips/files-4.14/drivers/net/ethernet/mtk/mtk_eth_soc.c
@@ -1502,6 +1502,9 @@ static int fe_probe(struct platform_device *pdev)
struct clk *sysclk;
int err, napi_weight;
+ printk("mtk fe_probe: name=%s resource=%p\n",
+ pdev->name, pdev->resource);
+
device_reset(&pdev->dev);
match = of_match_device(of_fe_match, &pdev->dev);
root@OpenWrt:~# dmesg | grep mtk
[ 1.987087] [mtk_nand] probe successfully!
[ 2.021267] mtk fe_probe: name=1e100000.ethernet resource=8fd5da80
[ 3.509018] mtk_soc_eth 1e100000.ethernet: loaded mt7530 driver
[ 3.521548] mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 19
[ 5.003864] mtk_soc_eth 1e100000.ethernet eth0: port 1 link up
[ 7.585164] mtk_soc_eth 1e100000.ethernet: PPE started
[ 11.285582] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x6060000c, 0x10c = 0x80818
[ 19.882379] mtk_soc_eth 1e100000.ethernet: PPE started
root@OpenWrt:~#
I would expect that fe_probe would be called twice with different resource pointers.
It would be great if you got rid of including e50.dtsi and instead move everything into SFP dts.
That way you wont call ethernet alias twice.
ðernet is just alias for the ethernet node in mt7621.dtsi
You can see how they defined the main phy
what I have discovered so far:
mtk_eth_soc.c initializes Ethernet ports if SOC--specific driver provides port_init function.
But soc_mt7621.c does not provide such a function, so individual MACs on the 7621 cannot be initialized. It provides only switch_init and switch_config functions, and switch_config instructs the driver to look for the switch on PHY port 0x1f.
Also in Mediatek's PDF for 7621, there's no indication why Phy 0x1f is used, and what's the number of the other Gigabit interface.
So, we need help of John Crispin to move any further.
1 Like
I have no idea how to get in touch with John Crispin. Tried to email, but had no responses. This thread has been here too for a long time already and didn't get attention until you came along. It would be nice to have some core developers guide us through a bit, even just to make sure that any patch follows correct guidelines and requirements to prevent any rework later