[PATCH] bcm53xx: add support for Asus RT-AC88U

[Arınç ÜNAL]

Sorry for the late response.

> On 4 Nov 2021, at 10:20, Rafał Miłecki <rafal at milecki.pl> wrote:
> 
> On 25.10.2021 23:37, Arınç ÜNAL wrote:
>> @@ -8,6 +8,12 @@ netgear,r8000)
>>      ucidef_set_led_usbport "usb2" "USB 2.0" "bcm53xx:white:usb2" "usb1-port2" "usb2-port2"
>>      ucidef_set_led_usbport "usb3" "USB 3.0" "bcm53xx:white:usb3" "usb1-port1" "usb2-port1" "usb4-port1"
>>      ;;
>> +asus,rt-ac88u)
>> +    ucidef_set_led_default "power" "Power" "white:power" "1"
> 
> Do we need that? "power" led seems to be enabled by default by DTS code:
> linux,default-trigger = "default-on";

We actually don't need to configure any LEDs here since everything (except lan for now) is specified on the device tree of the device.

However, the USB port names differ from the device tree (e.g. usb1-port2 -> ehci_port2 & usb4-port1 -> xhci_port1) so I thought having these, along with the power LED, preconfigured on UCI would be helpful to the user.

> 
>> +    ucidef_set_led_netdev "lan" "LAN" "white:lan" "eth1"
> 
> This info should be put in DT but we don't have bindings for that yet.
> 
> 
>> +    ucidef_set_led_usbport "usb2" "USB 2.0" "white:usb2" "usb1-port2"
>> +    ucidef_set_led_usbport "usb3" "USB 3.0" "white:usb3" "usb1-port1" "usb4-port1"
> 
> There is "linux,default-trigger" and "trigger-sources" in DT so this
> shouldn't be needed. If for some reason "usbport" driver doesn't pick
> that on its own - please kindly debug that.

USB LEDs work fine without anything configured on 01_leds.

> 
> 
>> --- /dev/null
>> +++ b/target/linux/bcm53xx/base-files/etc/init.d/set_nvram_vars
>> @@ -0,0 +1,13 @@
>> +#!/bin/sh /etc/rc.common
>> +
>> +START=99
>> +boot() {
>> +    . /lib/functions.sh
>> +
>> +    case $(board_name) in
>> +        asus,rt-ac88u)
>> +            # clear et0macaddr which makes cfe recovery mode inaccessible, set eth1 & eth2 mac addresses and wireless LEDs behaviour variables on nvram
>> +            nvram unset et0macaddr set et1macaddr=$(nvram get 0:macaddr) set et2macaddr=$(nvram get 1:macaddr) set 0:ledbh9=0x7 set 1:ledbh9=0x7 && nvram commit
>> +            ;;
>> +    esac
>> +}
> 
> I'm not sure what to do about this. I don't think OpenWrt is a place
> to automatically fix CFE issues. Recovery mode inaccessibility seems
> like an important problem though.

About et0macaddr, et1macaddr & et2macaddr nvram variables:
et0macaddr is used to set the mac address of eth0 interface
et1macaddr is used to set the mac address of eth1 interface
et2macaddr is used to set the mac address of eth2 interface

The et0macaddr nvram variable either needs to be unset or have the value of "00:00:00:00:00:00". Otherwise, CFE will complain about the MAC address and won't host the CFE recovery webpage.

This is just in case that if the value of et0macaddr is tampered with, we set it back to the correct one.

We need to ensure these variables are always set at the correct value like the Asus firmware does at, I suppose, every boot:
https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/init.c#L3083

I didn't see another way of configuring the nvram variables so I thought using an initscript would work. Ensuring that the correct values of these variables are set at each boot.

> 
> Why do you set Ethernet interfaces to duplicate wireless MACs?

We need to set up et1macaddr & et2macaddr to use the correct MAC addresses for the CPU interfaces. I believe that the Asus firmware does this some other way. On OpenWrt, if we don't set et1macaddr & et2macaddr, the MAC addresses of the CPU interfaces will be random at every boot.

0:macaddr & 1:macaddr survive the CFE NVRAM reset. Each wireless chip is connected to a different CPU. I figured that their MAC addresses are the same so I can just use them to set up the variables for the CPU interfaces.

> 
> Does ledbh9 affect wireless firmware (uploaded by brcmfmac) somehow?

About 0:ledbh9 & 1:ledbh9 nvram variables:
ledbh means LED behaviour
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

> Why do we need that if original Asus firmware doesn't use it? Does
> Asus make Linux control WLAN LEDs? Could we do the same?

The Asus firmware does use these nvram variables:
https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/init.c#L11247

The wireless firmware controls the wireless LEDs, this is the same case on the Asus firmware. So, no.

One odd thing is, compared to others, the wireless LEDs won't lit up at full brightness like they do on the Asus firmware & DD-WRT. I tried a bunch of nvram variables without any difference. It’s still better than nothing.

Arınç