OpenWrt Support for Asus RT-AC88U

Good Morning,

DSA driver

I didn't add anything beside the port 5 definition in the DTS file.

The Linksys EA9500 patch mail starts with "...The external switch BCM53125 currently works as "dumb switch ..." so I thought that it may be possible to access the external switch through that one port on the internal switch. Like it is on the Merlin firmware, where the external switch can't be configured using robocfg but the ports can be used anyway.

And that's how it works for now, no DSA config for the rtl8365mb. My DTS file is yours (from May) with the port 5 as pasted and USB vcc-gpio added (but for both usb2 & usb3).

I'll update to your latest/updated commit and see if I can get the rtl8365mb DTS patch to work this week (but today I'm mostly out of the house). That's will be just for fun of course, it's better to wait until the rtl8365mb patch is included in the kernel.

1 Like

swconfig & DSA branches

Both branches have proper commits on them now. All done there!

DSA

I tried the dsa cpu port fix and can confirm switch works fine under DSA! I made the patches and included them under a commit. This commit which was very recently merged into master fixes this issue. Therefore I'm removing it.

The next commit includes the least modification on the kernel configuration. We have to disable swconfig at least for broadcom switches, otherwise it will conflict with definitions on dsa whilst compiling.

arm-openwrt-linux-muslgnueabi-ld: drivers/net/dsa/b53/b53_common.o: in function `b53_switch_alloc':
/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/dsa/b53/b53_common.c:2598: multiple definition of `b53_switch_alloc'; drivers/net/phy/b53/b53_common.o:/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/phy/b53/b53_common.c:1646: first defined here
arm-openwrt-linux-muslgnueabi-ld: drivers/net/dsa/b53/b53_common.o: in function `b53_switch_detect':
/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/dsa/b53/b53_common.c:2638: multiple definition of `b53_switch_detect'; drivers/net/phy/b53/b53_common.o:/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/phy/b53/b53_common.c:1663: first defined here
arm-openwrt-linux-muslgnueabi-ld: drivers/net/dsa/b53/b53_common.o: in function `b53_switch_register':
/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/dsa/b53/b53_common.c:2705: multiple definition of `b53_switch_register'; drivers/net/phy/b53/b53_common.o:/home/user/master/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx_generic/linux-5.10.61/drivers/net/phy/b53/b53_common.c:1730: first defined here

Connecting broadcom switch to realtek switch

I tried the change on DTS, this works too! So it's port 0 on realtek switch (we don't actually know this yet, sw0port0 is just a name to call the node) and port 5 on broadcom switch.

If I get it right, this is as if I plugged a cable to one of the ports on realtek switch and the broadcom switch. So I can reach the realtek switch on the interface we labeled as "extswitch". Pretty cool.

For now, this router's got access to a managed and an unmanaged switch until we include the DSA driver for rtl8365mb.

DSA driver for rtl8365mb

I'm off to explore the upcoming dsa driver for rtl8365mb!

According to this from the driver, port 4 is the CPU port number that we need to define on device tree:

+/* Port mapping macros
+ *
+ * PORT_NUM_x2y: map a port number from domain x to domain y
+ * PORT_MASK_x2y: map a port mask from domain x to domain y
+ *
+ * L = logical port domain, i.e. dsa_port.index
+ * P = physical port domain, used by the Realtek ASIC for port indexing;
+ *     for ports with internal PHYs, this is also the PHY index
+ * E = extension port domain, used by the Realtek ASIC for managing EXT ports
+ *
+ * The terminology is borrowed from the vendor driver. The extension port domain
+ * is mostly used to navigate the labyrinthine layout of EXT port configuration
+ * registers and is not considered intuitive by the author.
+ *
+ * Unless a function is accessing chip registers, it should be using the logical
+ * port domain. Moreover, function arguments for port numbers and port masks
+ * must always be in the logical domain. The conversion must be done as close as
+ * possible to the register access to avoid chaos.
+ *
+ * The mappings vary between chips in the family supported by this driver. Here
+ * is an example of the mapping for the RTL8365MB-VC:
+ *
+ *    L | P | E | remark
+ *   ---+---+---+--------
+ *    0 | 0 |   | user port
+ *    1 | 1 |   | user port
+ *    2 | 2 |   | user port
+ *    3 | 3 |   | user port
+ *    4 | 6 | 1 | extension (CPU) port
+ *
+ * NOTE: Currently this is hardcoded for the RTL8365MB-VC. This will probably
+ * require a rework when adding support for other chips.
+ */
+#define CPU_PORT_LOGICAL_NUM	4
+#define CPU_PORT_LOGICAL_MASK	BIT(CPU_PORT_LOGICAL_NUM)
+#define CPU_PORT_PHYSICAL_NUM	6
+#define CPU_PORT_PHYSICAL_MASK	BIT(CPU_PORT_PHYSICAL_NUM)
+#define CPU_PORT_EXTENSION_NUM	1

I'm done backporting the driver to linux 5.10. You can see the commit for the driver on this branch:

Only thing left to do is to specify the switch on the device tree and hope it works.

@scatman75 Are you around? We got USB and the realtek switch working! Can you test this release?

Good Morning @arinc9 I'll give the realtek-work-asus_rt-ac88u branch a go later today. Thanks for your great work, I'm still very happy you have made this port!

I also gave your latest DSA and SWCONFIG commits a go and they work as they should.
One thing that didn't work was the USB LED trigger, for that I had to compile my own kernel. But I assume that is because of the config being as minimal as possible.

Have you done some network perfomance tests with the DSA driver? For me it's about 20 to 40% slower then the SWCONFIG driver. To be expected I assume since DSA doesn't support some hardware offloading yet.
The DSA performance with the 5.10 kernel is about 10 to 20% slower than with the 5.4 kernel.

I haven't done any serious testing with documenting it, though.

1 Like

This doesn't work me as well. What did you do (which packages?) to solve this?

I haven't done any sort of performance test on DSA yet. We're going to put this sort of information on the device wiki, so your findings would be very helpful.

Device Tree Specification of RTL8365MB

We need to figure out the GPIO IDs for mdc-gpios, mdio-gpios, reset-gpios & interrupts

		compatible = "realtek,rtl8365mb";
		/* 7 = MDIO (has input reads), 6 = MDC (clock, output only) */
		/* reset-gpios: 14? */
		mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
		mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
		reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;

I assumed the GPIO IDs for mdc-gpios & mdio-gpios according to the rtl8365mb driver from Asuswrt tarball smi.c source code:

/*******************************************************************************/
/*  I2C porting                                                                */
/*******************************************************************************/
/* Define the GPIO ID for SCK & SDA */
rtk_uint32  smi_SCK = 6;    /* GPIO used for SMI Clock Generation */
rtk_uint32  smi_SDA = 7;    /* GPIO used for SMI Data signal */

There's also the PHY ID. I don't know whether to include it on device tree.

/*******************************************************************************/
/*  MDC/MDIO porting                                                           */
/*******************************************************************************/
/* define the PHY ID currently used */
#define MDC_MDIO_PHY_ID     0  /* PHY ID 0 or 29 */

Current device tree:

	switch@1 {
		compatible = "realtek,rtl8365mb";
		/* 7 = MDIO (has input reads), 6 = MDC (clock, output only) */
		/* reset-gpios: 14? */
		mdc-gpios = <&chipcommon 6 GPIO_ACTIVE_HIGH>;
		mdio-gpios = <&chipcommon 7 GPIO_ACTIVE_HIGH>;
		reset-gpios = <&chipcommon 14 GPIO_ACTIVE_LOW>;
		dsa,member = <0 1>;

		switch_intc: interrupt-controller {
			/* GPIO 15 provides the interrupt */
			interrupt-parent = <&chipcommon>;
			interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
			interrupt-controller;
			#address-cells = <0>;
			#interrupt-cells = <1>;
		};

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;
				label = "lan8";
				phy-handle = <&phy0>;
			};

			port@1 {
				reg = <1>;
				label = "lan7";
				phy-handle = <&phy1>;
			};

			port@2 {
				reg = <2>;
				label = "lan6";
				phy-handle = <&phy2>;
			};

			port@3 {
				reg = <3>;
				label = "lan5";
				phy-handle = <&phy3>;
			};

			port@4 {
				reg = <4>;
				label = "cpu";
				ethernet = <&sw0_p5>;
				phy-mode = "rgmii";

				fixed-link {
					speed = <1000>;
					full-duplex;
				};
			};
		};

		mdio {
			compatible = "realtek,smi-mdio", "dsa-mdio";
			#address-cells = <1>;
			#size-cells = <0>;

			phy0: phy@0 {
				reg = <0>;
				interrupt-parent = <&switch_intc>;
				interrupts = <0>;
			};

			phy1: phy@1 {
				reg = <1>;
				interrupt-parent = <&switch_intc>;
				interrupts = <1>;
			};

			phy2: phy@2 {
				reg = <2>;
				interrupt-parent = <&switch_intc>;
				interrupts = <2>;
			};

			phy3: phy@3 {
				reg = <3>;
				interrupt-parent = <&switch_intc>;
				interrupts = <3>;
			};
		};
	};

Switch cannot be probed properly with the current device tree:

[    1.598858] realtek-smi switch@1: failed to get RESET GPIO
---
[    3.015528] realtek-smi switch@1: deasserted RESET
[    3.021171] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[    3.028193] realtek-smi switch@1: unable to register switch ret = -517
---
[    3.405527] realtek-smi switch@1: deasserted RESET
[    3.411165] realtek-smi switch@1: found an RTL8365MB-VC switch (ver=0x0040)
[    3.418449] DSA: tree 0 already setup! Disjoint trees?
[    3.423607] realtek-smi switch@1: unable to register switch ret = -17
[    3.430137] realtek-smi: probe of switch@1 failed with error -17

Any ideas how we figure out the GPIO ID for reset-gpios?

@arinc9 I unfortunately have no idea how to get the GPIO ID reset.

I played around with different values for the switch reset and have messed up the switch. With the help of the firmware restoration tool I installed Merlin and tried to back to OpenWrt but I don't geht a login. Will try tomorrow.

@patient0 Good morning.

We can include the packages on the makefile since this is a core feature of the router. Please let me know.

GPIO 2 breaks the router for some reason. Get rid of that, if you have it on the device tree.

Sorry, forgot to answer the ledtrig question: I did include the kmod-usb-ledtrig-usbport not as an module but fix (with an '*' not 'M'). I think that was all but I have to be honest I did also include Wireguard and a few tools I wanted in my base image. So I'll have verify.

Switch Reset

Yep, I pretty early found out that GPIO 2 messes up the OS and a reboot is necessary.

I did use GPIO 10 - the switch reset - instead of 14 and the router keeps rebooting itself.
I did flash Merlin after that Merlin run fine but yesterday I wasn't able to connect to the router after flashin OpenWrt.

Edit/Add: What .config file did you use? Not the default OpenWrt one I assume.

Addition 2: Tested the minimal compilation and indeed adding kmod-usb-ledtrig-usbport solved it. So, removing .config, running make defconfig and then add CONFIG_DEFAULT_kmod-usb-ledtrig-usbport=y (plus chose RT-AC88U as a target).
After installing that image you of course have to add luci and the corresponding luci-app-ledtrig-usbport, that worked for me.

Hold on, I misunderstood. I was refering to the LED button which switches LEDs off/on.
I already stated this about triggering the LEDs for USB ports:

I'm not sure why you're having trouble there.

I do use the default .config. I just choose RT-AC88U and enable luci-ssl on menuconfig.


I'm trying a bunch of GPIO IDs, one by one, for reset-gpios. You can track the progress on the Notion link. I'm going to have to mail Alvin (the developer of the DSA driver for rtl8365mb) and ask for guidance if I can't figure it out.

Ok, I'll try again by not changing anything with the default .config file, thanks.


:+1: Did you try with only setting gpio-reset and no interrupts and stuff - like they did for Linksys EA9500. It's a different second switch but the same primary.
And the hardware init seems to be generally ok otherwise we would be able to use the RTL8365mb as a dump switch.


The buttons trigger scripts in /etc/rc.button and there is no script for brightness_zero yet. And I haven't found a way to switch 'em all off. Well, we can switch off the ones defined in uci/luci but e.g. not the WiFi LEDs (which still don't work for me).

Update: this morning for no reason the two WiFi LEDs half work (without flasing anything new). They don't switch off if I switch off WiFi and the brightness is only half as the other LEDs.

These are required properties for Realtek SMI :frowning:. EA9500 uses broadcom switches, therefore they use different properties. Device tree won't compile if I take out the required properties like reset-gpios & interrupt-controller. It probably will but won't have any effect.

Yup, the bootloader initialises realtek switch just fine. I sent a mail to Alvin. I don't have anything else to try so I'm going to wait for their response.

I think we can mess around with this Quantenna SDK in the future.

@patient0 I figured out why the wireless LEDs weren't working.

When you switch from other firmware to OpenWrt, the nvram variables below stay intact. But after resetting NVRAM, they won't be added back.

  • 0:ledbh9 -> Behaviour of 2.4GHz LED
  • 1:ledbh9 -> Behaviour of 5GHz LED
  • 0x7 makes the wireless LEDs on, when radios are enabled, and blink when there's activity
  • 0x88 makes the wireless LEDs off by default and blink when there's activity
nvram set 0:ledbh9=0x7 set 1:ledbh9=0x7 && nvram commit

After reboot, wireless LEDs will start working.

Found 0x88 by looking around at merlin's source code:
https://github.com/RMerl/asuswrt-merlin.ng/search?p=2&q=ledbh9

If you compare them to others, the wireless LEDs won't lit up at full brightness. I tried a bunch of nvram variables without any luck. I'm letting this go for now.


I plan to implement this as an initscript to keep setting these variables every time the device boots. Whether the user clears the nvram or not.

Hi @arinc9, interesting find ... thanks a lot for having a look at it.

I did add this nvram setting and now indeed the wireless LED are on with half the brightness as the others. They don't switch off when I switch of wireless (with values 0x7) though.

I just realised that too. I suppose this is the best we can get with a closed source wireless firmware controlling the LEDs.

@arinc9
Sorry for not replying earlier. But I've been very busy lately.

Has anyone tried to setup a wireless guest network via VLAN? I followed the mini tutorial, available under Mini tutorial for DSA network config, sections Multiple networks (using VLANs) and VLAN tagged traffic.

PVID 1: home network
PVID 2: guest network

Relevant part of /etc/config/network

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'extsw'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'
        option vlan_filtering '1'

config bridge-vlan
	option device 'br-lan'
	option vlan '1'
	list ports 'lan1:u*'
	list ports 'lan2:u'
	list ports 'lan3:u'

config bridge-vlan
	option device 'br-lan'
	option vlan '2'
	list ports 'lan1:t'
	list ports 'lan4:u'

config interface 'lan'                         
        option device 'br-lan'                 
        option proto 'static'                  
        option netmask '255.255.255.0'
        option ip6assign '60'         
        option ipaddr '192.168.100.250' 
        option gateway '192.168.100.1'  
        option broadcast '192.168.100.255'
        list dns '192.168.100.1'

config interface 'guest'                         
        option device 'br-lan'                 
        option proto 'static'                  
        option netmask '255.255.255.0'
        option ip6assign '60'         
        option ipaddr '192.168.103.250' 
        option gateway '192.168.103.1'  
        option broadcast '192.168.103.255'
        list dns '192.168.103.1'


Relevant part of /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path '18000000.axi/bcma0:7/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'HT20'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'HOME'
        option encryption 'psk2'
        option key 'KEY1KEY1KEY1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'HOME'
        option encryption 'psk2'
        option key 'KEY1KEY1KEY1'

config wifi-iface 'wifinet2'                                                   
        option device 'radio0'                                                 
        option mode 'ap'                                                       
        option ssid 'GUEST'                                               
        option encryption 'psk2'                                               
        option key 'KEY2KEY2KEY2                     
        option network 'guest'

The thing is, that without VLANs the LAN part of the router as well as the WLAN part are working well. With configured VLANs no wireless connection is possible. The clients get connected and than disconnect.

With the "old" swconfig setup I did not experience these problems. Or maybe am I missing something?
Maybe one of you guys can setup a guest WLAN and report back.

Hey @scatman75,

Thanks for giving it go despite being busy.

Looking through the tutorial I do see a difference: for your interfaces 'lan' and 'guest' there's no VLAN defined. E.g. in the tutorial 'home' interface the device 'br-lan.1' - for VLAN 1 - is used. You do use the device 'br-lan' for both interfaces so there is no chance of knowing which interface uses which VLAN.

Since I haven't tested VLANs myself yet with the DSA driver VLANs still may not work but I'd think it won't work with the above configuration.
I'll try VLANs today or tomorrow

Thank you very much for your quick reply. You are absolutly right. Without the PVID attached to the bridge, there is no chance of making it work. Since I wrote the lines by hand, I forgot attaching the PViD to the bridge br-lan. In the router's configuration these PVIDs are set.

Thank you very much for your offer of testing this kind of setup.

You can create a VLAN without any switch ports configured for it. E.g. VLAN 3:

Then attach wireless interfaces to the network, which will be automatically included in the bridge. I actually explained this on this wiki page.

End result with two wireless interfaces:

@scatman75 @patient0 None of my devices will connect to both Wi-Fi bands with WPA2-PSK. I get wrong password even though it's correct. Anyone of you have this problem?

@arinc9 I have not yet implemented the VLAN example. In my normal setup without VLAN, WPA2-PSK over 2.4GHz and 5GHz works fine