Adding OpenWrt support for Archer A6 v3

vrpatil · 2021-01-30T02:51:03.388Z

@123serge123 how to enable mt7621 related code in mt7530?

Added all missing mt7530 specific code from setup_internal_gsw of u-boot rt2880_eth.c into mt7530.c it didnt help, now only missing is there are some mt7621 specific initialization(like below) which are not found in openwrt mt7530.c. is it fine to access MT7621(SOC) registers in openwrt mt7530.c, or is there another location it is handled?

	// reset phy
	regValue = RALINK_REG(RT2880_RSTCTRL_REG);
	regValue = regValue | (1<<2);
	RALINK_REG(RT2880_RSTCTRL_REG) = regValue;
	udelay(1000);
	regValue = regValue & ~(1<<2);
	RALINK_REG(RT2880_RSTCTRL_REG) = regValue;
	udelay(10000);


	/* reduce MDIO PAD driving strength */
	regValue = RALINK_REG(PAD_RGMII2_MDIO_CFG);
	regValue &= ~(0x3<<4);	// reduce Tx driving strength to 2mA (WDT_E4_E2)
	RALINK_REG(PAD_RGMII2_MDIO_CFG) = regValue;

vrpatil · 2021-01-30T03:51:34.595Z

Issue resolved


[    0.698744] libphy: mdio: probed
[    0.702184] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
[    0.708433] mt7530 mdio-bus:1f: Failed dsa_register_switch: -517
[    0.716824] mtk_soc_eth 1e100000.ethernet: generated random MAC address 66:96:d6:67:4d:18
[    0.725863] mtk_soc_eth 1e100000.ethernet eth0: mediatek frame engine at 0xbe100000, irq 21
[    0.736176] mt7621-pci 1e140000.pcie: Parsing DT failed
[    0.743988] NET: Registered protocol family 10
[    0.749810] Segment Routing with IPv6
[    0.753610] NET: Registered protocol family 17
[    0.758367] 8021q: 802.1Q VLAN Support v1.8
[    0.764676] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
[    0.797418] mt7530 mdio-bus:1f: MT7530 Reset Completed!!
[    0.802735] mt7530 mdio-bus:1f: reset mt7530 fixup
[    0.827879] libphy: dsa slave smi: probed
[    0.832391] mt7530 mdio-bus:1f wan (uninitialized): PHY [dsa-0.0:00] driver [Generic PHY]
[    0.841991] mt7530 mdio-bus:1f lan1 (uninitialized): PHY [dsa-0.0:01] driver [Generic PHY]
[    0.851663] mt7530 mdio-bus:1f lan2 (uninitialized): PHY [dsa-0.0:02] driver [Generic PHY]
[    0.861405] mt7530 mdio-bus:1f lan3 (uninitialized): PHY [dsa-0.0:03] driver [Generic PHY]
[    0.871053] mt7530 mdio-bus:1f lan4 (uninitialized): PHY [dsa-0.0:04] driver [Generic PHY]
[    0.880865] mt7530 mdio-bus:1f: configuring for fixed/rgmii link mode
[    0.892060] DSA: tree 0 setup

Following additional code in mt7530 helped


	
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) |= (0x1 << 2);
	udelay(1000);
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) &= ~(0x1 << 2);
	udelay(10000);

	/* Wait for Switch Reset Completed*/
	for(i=0;i<100;i++)
	{
		mdelay(10);
		val = mt7530_read(priv, 0x7800);
		if(val != 0){
			dev_info(priv->dev,"MT7530 Reset Completed!!\n");
			break;
		}
		if(i == 99)
			dev_info(priv->dev, "MT7530 Reset Timeout!!\n");
	}

	//sysRegWrite(RALINK_ETH_SW_BASE+0x200, 0x21056300);//(P1, Auto mode)

	/* reduce RGMII2 PAD driving strength */
	*(volatile u_long *)(PAD_RGMII2_MDIO_CFG) &= ~(0x3 << 4);

	/*RGMII1=Normal mode*/
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x60) &= ~(0x1 << 14);

	/*enable MDIO to control MT7530*/
	val = le32_to_cpu(*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x60));
	val &= ~(0x3 << 12);
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x60) = val;

Now all ETH links are working!!

123serge123 · 2021-01-30T04:36:44.979Z

Ok. But now mt7530 dsa-driver is system dependent
Let's see step by step:

This code

	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) |= (0x1 << 2);
	udelay(1000);
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) &= ~(0x1 << 2);
	udelay(10000);

is equivalent to original code of mt7530.c:

	/* Reset whole chip through gpio pin or memory-mapped registers for
	 * different type of hardware
	 */
	if (priv->mcm) {
		reset_control_assert(priv->rstc);
		usleep_range(1000, 1100);
		reset_control_deassert(priv->rstc);
	} else {
		gpiod_set_value_cansleep(priv->reset, 0);
		usleep_range(1000, 1100);
		gpiod_set_value_cansleep(priv->reset, 1);
	}

This

	/*enable MDIO to control MT7530*/
	val = le32_to_cpu(*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x60));
	val &= ~(0x3 << 12);
	*(volatile u_long *)(RALINK_SYSCTL_BASE + 0x60) = val;

is equivalent to chages in dts-file:

&ethernet {
        pinctrl-names = "default";
        pinctrl-0 = <&rgmii1_pins &mdio_pins>;
};

No equivalent to:

	/* reduce RGMII2 PAD driving strength */
	*(volatile u_long *)(PAD_RGMII2_MDIO_CFG) &= ~(0x3 << 4);

but I'm not sure that it's so critical.
4. This

	/* Wait for Switch Reset Completed*/
	for(i=0;i<100;i++)
	{
		mdelay(10);
		val = mt7530_read(priv, 0x7800);
		if(val != 0){
			dev_info(priv->dev,"MT7530 Reset Completed!!\n");
			break;
		}
		if(i == 99)
			dev_info(priv->dev, "MT7530 Reset Timeout!!\n");
	}

increase poll interval up to 100*10ms with 10ms delay between register reading. Original code:

	/* Waiting for MT7530 got to stable */
	INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_HWTRAP);
	ret = readx_poll_timeout(_mt7530_read, &p, val, val != 0,
				 20, 1000000);

do the same - poll interval 1000000us (or 1000ms) with 20us delay between attempts. Only diff is 20us delay between attempts of register reading. This change:

	/* Waiting for MT7530 got to stable */
	INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_HWTRAP);
	ret = readx_poll_timeout(_mt7530_read, &p, val, val != 0,
				 10000, 1000000);

make it fully equivalent.

vrpatil · 2021-01-30T04:53:05.908Z

Not sure which one in above triggered it working, but prior to this, I also added in mt7530 below code after your fix . But that alone didnt help.

May be will try to revert changes one by one for SOC specific and find out which is really making a difference.


	mt7530_write(priv, 0x3600, 0x5e30b);//PDMA is not ready,disable FC, Prevent HOL
	mt7530_write(priv, 0x3500, 0x8000);

	/* Enable MT7530 Port 6 */
	val = 0x117ccf; //Enable Port 6 only
	mt7530_write(priv, 0x7804, val);	

	mt7530_write(priv, 0x3500, 0x56300); //MT7530 P5 AN
	
	/* Set MT7530 Port 0/4 to PHY mode */
	val = mt7530_read(priv, 0x7804);
	val &= ~((1<<13)|(1<<6));
	val |= ((1<<7)|(1<<16)|(1<<20));
	mt7530_write(priv, 0x7804 ,val);

	priv->bus->write(priv->bus, 0, 13, 0x1f);  // disable MT7530 core clock
	priv->bus->write(priv->bus, 0, 14, 0x410);
	priv->bus->write(priv->bus, 0, 13, 0x401f);
	priv->bus->write(priv->bus, 0, 14, 0x0);

	priv->bus->write(priv->bus, 0, 13, 0x1f);  // disable MT7530 PLL
	priv->bus->write(priv->bus, 0, 14, 0x40d);
	priv->bus->write(priv->bus, 0, 13, 0x401f);
	priv->bus->write(priv->bus, 0, 14, 0x2020);

	priv->bus->write(priv->bus, 0, 13, 0x1f);  // for MT7530 core clock = 500Mhz
	priv->bus->write(priv->bus, 0, 14, 0x40e);
	priv->bus->write(priv->bus, 0, 13, 0x401f);
	priv->bus->write(priv->bus, 0, 14, 0x119);

	priv->bus->write(priv->bus, 0, 13, 0x1f);  // enable MT7530 PLL
	priv->bus->write(priv->bus, 0, 14, 0x40d);
	priv->bus->write(priv->bus, 0, 13, 0x401f);
	priv->bus->write(priv->bus, 0, 14, 0x2820);

	udelay(20); //suggest by CD

	priv->bus->write(priv->bus, 0, 13, 0x1f);  // enable MT7530 core clock
	priv->bus->write(priv->bus, 0, 14, 0x410);
	priv->bus->write(priv->bus, 0, 13, 0x401f);
	priv->bus->write(priv->bus, 0, 14, 0x1);

	/*Tx Driving*/
	mt7530_write(priv, 0x7a54, 0x44);  //lower driving
	mt7530_write(priv, 0x7a5c, 0x44);  //lower driving
	mt7530_write(priv, 0x7a64, 0x44);  //lower driving
	mt7530_write(priv, 0x7a6c, 0x44);  //lower driving
	mt7530_write(priv, 0x7a74, 0x44);  //lower driving
	mt7530_write(priv, 0x7a7c, 0x44);  //lower driving

	for(i=0;i<=4;i++) 
	{	
	       //turn on PHY
	       val = priv->bus->read(priv->bus, i, 0x0);
	       val &= ~(0x1<<11);
               priv->bus->write(priv->bus, i, 0x0, val);
	}

let me send diff of my changes for you to check

mpratt14 · 2021-01-30T05:22:07.877Z

seems to be a slight difference here as well, OEM code has a delay after both steps

consider this if the other change to read poll interval does not work

	/* Reset whole chip through gpio pin or memory-mapped registers for
	 * different type of hardware
	 */
	if (priv->mcm) {
		reset_control_assert(priv->rstc);
		usleep_range(1000, 1100);
		reset_control_deassert(priv->rstc);
		usleep_range(10000, 11000);
	} else {
		gpiod_set_value_cansleep(priv->reset, 0);
		usleep_range(1000, 1100);
		gpiod_set_value_cansleep(priv->reset, 1);
		usleep_range(10000, 11000);
	}

vrpatil · 2021-01-30T10:19:34.628Z

@mpratt14 issue is in reset of the chip.
I tried all combinations to disable each of SOC specific lines, its only the below line(s) + Reset fix from @123serge123, which are required to make things work

       *(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) |= (0x1 << 2);
       udelay(1000);
       *(volatile u_long *)(RALINK_SYSCTL_BASE + 0x34) &= ~(0x1 << 2);
       udelay(10000);

Something wrong in below reset logic, this seems not working


	/* Reset whole chip through gpio pin or memory-mapped registers for
	 * different type of hardware
	 */
	if (priv->mcm) {
		reset_control_assert(priv->rstc);
		usleep_range(1000, 1100);
		reset_control_deassert(priv->rstc);
		usleep_range(10000, 11000);		
	} else {
		gpiod_set_value_cansleep(priv->reset, 0);
		usleep_range(1000, 1100);
		gpiod_set_value_cansleep(priv->reset, 1);
		usleep_range(10000, 11000);		
	}

123serge123 · 2021-01-30T10:43:12.688Z

It's very possible that is the main reason (arch/mips/ralink/reset.c - system dependent reset controller):

static int ralink_assert_device(struct reset_controller_dev *rcdev,
                                unsigned long id)
{
        u32 val;

        if (id < 8)
                return -1;

        val = rt_sysc_r32(SYSC_REG_RESET_CTRL);
        val |= BIT(id);
        rt_sysc_w32(val, SYSC_REG_RESET_CTRL);

        return 0;
}

static int ralink_deassert_device(struct reset_controller_dev *rcdev,
                                  unsigned long id)
{
        u32 val;

        if (id < 8)
                return -1;

        val = rt_sysc_r32(SYSC_REG_RESET_CTRL);
        val &= ~BIT(id);
        rt_sysc_w32(val, SYSC_REG_RESET_CTRL);

        return 0;
}

ignore reset id < 8. We need id=2 (mt7621.dtsi):

                       switch0: switch@1f {
                                compatible = "mediatek,mt7621";
                                #address-cells = <1>;
                                #size-cells = <0>;
                                reg = <0x1f>;
                                mediatek,mcm;
                                resets = <&rstctrl 2>;
                                reset-names = "mcm";

svanheule · 2021-01-30T11:07:11.119Z

I can confirm that the following patch fixes switch bring-up on cold-boot (on the EAP235-Wall):

--- linux-5.4.89.orig/arch/mips/ralink/reset.c
+++ linux-5.4.89/arch/mips/ralink/reset.c
@@ -27,7 +27,7 @@ static int ralink_assert_device(struct r
 {
 	u32 val;
 
-	if (id < 8)
+	if (id !=2 && id < 8)
 		return -1;
 
 	val = rt_sysc_r32(SYSC_REG_RESET_CTRL);
@@ -42,7 +42,7 @@ static int ralink_deassert_device(struct
 {
 	u32 val;
 
-	if (id < 8)
+	if (id !=2 && id < 8)
 		return -1;
 
 	val = rt_sysc_r32(SYSC_REG_RESET_CTRL);

@blogic, git blames you for this reset controller code. Do you know/remember why reset lines < 8 are illegal?

Edit: the DTS also uses reset line 6, so this will also not actually be toggled

github.com

openwrt/openwrt/blob/eb11cd9ea3822b34df6260b1dd40fc4f0866b804/target/linux/ramips/dts/mt7621.dtsi#L458


	ethernet: ethernet@1e100000 {
		compatible = "mediatek,mt7621-eth";
		reg = <0x1e100000 0x10000>;
		clocks = <&sysclock>;
		clock-names = "ethif";
		#address-cells = <1>;
		#size-cells = <0>;
		resets = <&rstctrl 6 &rstctrl 23>;
		reset-names = "fe", "eth";
		interrupt-parent = <&gic>;
		interrupts = <GIC_SHARED 3 IRQ_TYPE_LEVEL_HIGH>;
		mediatek,ethsys = <&ethsys>;
		gmac0: mac@0 {
			compatible = "mediatek,eth-mac";
			reg = <0>;

svanheule · 2021-01-30T14:39:22.816Z

Looking further into the MT7621 resets, it appears the SDK's reset definitions don't match those in OpenWrt

c6u-gpl/mtk_ApSoC_5050/linux-3.10.14.x/arch/mips/include/asm/mach-ralink/rt_mmap.h

#elif defined (CONFIG_RALINK_MT7621)

//Reset Control Register
#define RALINK_SYS_RST			(1<<0)
#define RALINK_MCM_RST			(1<<1)
#define RALINK_HSDMA_RST		(1<<2)
#define RALINK_FE_RST			(1<<6)
...

OpenWrt:

mt7621.dtsi
243:			resets = <&rstctrl 5>;
244-			reset-names = "hsdma";
--
458:		resets = <&rstctrl 6 &rstctrl 23>;
459-		reset-names = "fe", "eth";
--
495:				resets = <&rstctrl 2>;
496-				reset-names = "mcm";

vrpatil · 2021-01-30T16:03:12.267Z

svanheule:

I can confirm that the following patch fixes switch bring-up on cold-boot (on the EAP235-Wall):

Same here, mt7530 changes are no more required.
Anyone planning to push a patch for this fix?

Borromini · 2021-01-30T16:05:54.079Z

Svanheule pinged blogic for another set of eyes, it's wiser to wait for that I think.

Borromini · 2021-01-31T09:52:49.170Z

@gvl @vrpatil We're seeing the 3 dBm problem also on the MT7613BEN on the EAP235-Wall v1, does the GPL archive (or your stock firmware) have an MT7613BEN EEPROM by any chance? If so can you see if that helps if you use it in OpenWrt? A lot of low power reports with mt76 talk about EEPROM values.

Stock EAP235-Wall v1 firmware seems to have /etc_ro/wireless/mt7663e/MT7613BE_iPAiLNA_eeprom.bin. I have no idea how OpenWrt would use that, though, I see eeprom locations in the MT7621 DTSes but on idea how/if they relate.

vrpatil · 2021-01-31T12:15:05.620Z

The OEM contains a file named /etc/MT7613E_EEPROM.bin.
Not sure at this moment if this file is parsed or radio partition calibrated values are read properly.

I haven't given attention to detailed wifi testing, if you can describe the issue will try to check if is occurring here too.

Borromini · 2021-01-31T12:50:25.589Z

gvl reported he only saw 3 dBm in LuCI and we're seeing the same. Radio transmit power seems very weak (OK signal close by (0,5m ±), deteriorates quickly when you distance yourself from the AP, and connection seems to cut.

@gvl Can you share what you're seeing on your 5 GHz radio?

musashino · 2021-01-31T13:22:46.088Z

The eeprom data in flash specified by mediatek,mtd-eeprom may not be used.
Could you try the following change?

github.com/musashino-build/openwrt

mt76: add a patch to show debug output for mt7615

committed 02:24AM - 28 Jan 21 UTC

musashino205

+28 -0

Currently, mt7615e driver in mt76 doesn't seem to support eeprom data in flash properly.

github.com

openwrt/mt76/blob/8696919d9aae9b673f916bca41c5e1671eec5b0e/mt7615/eeprom.c#L335-L342


	ret = mt7615_check_eeprom(&dev->mt76);
	if (ret && dev->mt76.otp.data) {
		memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
		       MT7615_EEPROM_SIZE);
	} else {
		dev->flash_eeprom = true;
		mt7615_cal_free_data(dev);
	}

github.com

openwrt/mt76/blob/8696919d9aae9b673f916bca41c5e1671eec5b0e/mt7615/eeprom.c#L82-L93


static int mt7615_check_eeprom(struct mt76_dev *dev)
{
	u16 val = get_unaligned_le16(dev->eeprom.data);
	switch (val) {
	case 0x7615:
	case 0x7622:
		return 0;
	default:
		return -EINVAL;
	}
}

gvl · 2021-01-31T15:28:20.949Z

@musashino yeah, you're correct.

I added the patch and I saw this:

[   13.633397] mt7615e 0000:02:00.0: use only otp data for mt7615e driver

I went a little bit further and added 0x7663 in mt7615_check_eeprom().

diff --git a/mt7615/eeprom.c b/mt7615/eeprom.c
index adc797d..80c4d70 100644
--- a/mt7615/eeprom.c
+++ b/mt7615/eeprom.c
@@ -86,6 +86,7 @@ static int mt7615_check_eeprom(struct mt76_dev *dev)
        switch (val) {
        case 0x7615:
        case 0x7622:
+       case 0x7663:
                return 0;
        default:
                return -EINVAL;

This seems to fix the TX power problem

root@OpenWrt:/# iwinfo wlan1 txpowerlist
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
   3 dBm (   1 mW)
   4 dBm (   2 mW)
   5 dBm (   3 mW)
   6 dBm (   3 mW)
   7 dBm (   5 mW)
   8 dBm (   6 mW)
   9 dBm (   7 mW)
  10 dBm (  10 mW)
  11 dBm (  12 mW)
  12 dBm (  15 mW)
  13 dBm (  19 mW)
  14 dBm (  25 mW)
  15 dBm (  31 mW)
  16 dBm (  39 mW)
  17 dBm (  50 mW)
  18 dBm (  63 mW)
  19 dBm (  79 mW)
* 20 dBm ( 100 mW)

gvl · 2021-01-31T15:34:48.933Z

@Borromini

The driver reports max TX power only up to 3 dBm. It's not completely unusable but you have to be very close to the device, like a couple of meters away in the same room. I remember iperf showing results close to 400mbps with Intel 8265 client.

root@OpenWrt:/# iwinfo wlan1 txpowerlist
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
*  3 dBm (   1 mW)
root@OpenWrt:/#

See my previous response. What @musashino suggested seems to fix that problem. At least the driver reports up to 20dBm now.

vrpatil · 2021-01-31T16:12:57.611Z

gvl:

iwinfo wlan1 txpowerlist

I confirm the same issue with 5G radio with Archer A6 v3

root@OpenWrt:/# iwinfo wlan1 txpowerlist
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
*  3 dBm (   1 mW)
root@OpenWrt:/#

update: patch improved the situation showing available power upto 23dBm (199mW), but haven't checked it with real 5G device yet.

update2: Even after above reported values, signal strength drops significantly in a distance of 5-7ft. And also network speed by 60%.

svanheule · 2021-01-31T16:15:35.401Z

Adding the extra case for 0x7663 does fix the reported Tx power issue. The actual signal strength doesn't appear to be that much better though. I still have to be in the same room to get a reliable connection. Do you know if the integrated amplifiers are supported on this chip?

gvl · 2021-01-31T16:26:38.236Z

I've no idea, tbh.