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

Arınç ÜNAL arinc.unal at arinc9.com
Wed Mar 30 23:07:18 PDT 2022


On 30/03/2022 05:37, Arınç ÜNAL wrote:
> On 29/03/2022 16:29, Rafał Miłecki wrote:
>> On 12.11.2021 11:56, Arınç ÜNAL wrote:
>>> Asus RT-AC88U is an AC3100 router featuring 9 Ethernet ports over the
>>> integrated Broadcom and the external Realtek switch.
>>>
>>> Hardware info:
>>> * Processor: Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
>>> * Switch: BCM53012 in BCM4709C0KFEBG & external RTL8365MB
>>> * DDR3 RAM: 512 MB
>>> * Flash: 128 MB (ESMT F59L1G81LA-25T)
>>> * 2.4GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC
>>> * 5GHz: BCM4366 4×4 2.4/5G single chip 802.11ac SoC
>>> * Ports: 8 Ports, 1 WAN Ports
>>>
>>> Flashing instructions:
>>> * Boot to CFE Recovery Mode by holding the reset button while power-on.
>>> * Connect to the router with an ethernet cable.
>>> * Set IPv4 address of the computer to 192.168.1.2 subnet 255.255.255.0.
>>> * Head to http://192.168.1.1.
>>> * Reset NVRAM.
>>> * Upload the OpenWrt image.
>>>
>>> CFE bootloader may reject flashing the image due to image integrity 
>>> check.
>>> In that case, follow the instructions below.
>>>
>>> * Rename the OpenWrt image as firmware.trx.
>>> * Run a TFTP server and make it serve the firmware.trx file.
>>> * Run the URL below on a browser or curl.
>>> http://192.168.1.1/do.htm?cmd=flash+-noheader+192.168.1.2:firmware.trx+flash0.trx 
>>>
>>>
>>> Signed-off-by: Arınç ÜNAL <arinc.unal at arinc9.com>
>>
>> Sorry for a late reply, ynezz pinged me on IRC on it recently, I'm going
>> to take what seems clear to me.
>>
>>
>>>   target/linux/bcm53xx/base-files/etc/board.d/01_leds |  6 ++++++
>>>   .../linux/bcm53xx/base-files/etc/board.d/02_network |  3 +++
>>>   .../bcm53xx/base-files/etc/init.d/set_nvram_vars    | 13 +++++++++++++
>>>   target/linux/bcm53xx/image/Makefile                 |  8 ++++++++
>>>   4 files changed, 30 insertions(+)
>>>   create mode 100755 
>>> target/linux/bcm53xx/base-files/etc/init.d/set_nvram_vars
>>>
>>> diff --git a/target/linux/bcm53xx/base-files/etc/board.d/01_leds 
>>> b/target/linux/bcm53xx/base-files/etc/board.d/01_leds
>>> index aba526b9c3..f37fa79d4f 100644
>>> --- a/target/linux/bcm53xx/base-files/etc/board.d/01_leds
>>> +++ b/target/linux/bcm53xx/base-files/etc/board.d/01_leds
>>> @@ -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"
>>> +    ucidef_set_led_netdev "lan" "LAN" "white:lan" "eth1"
>>> +    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"
>>> +    ;;
>>>   esac
>>>   board_config_flush
>>
>> This should be part of DT. You can make power LED enabled by default.
>> You can reference USB ports in DT.
>>
>> I don't think you can point Ethernet interface in LED node at this
>> point - support for that should be added.
> 
> Ok, let me configure only the lan LED here then?
> 
>>
>>
>>> diff --git a/target/linux/bcm53xx/base-files/etc/board.d/02_network 
>>> b/target/linux/bcm53xx/base-files/etc/board.d/02_network
>>> index 6d970e1d0e..822320c0a6 100644
>>> --- a/target/linux/bcm53xx/base-files/etc/board.d/02_network
>>> +++ b/target/linux/bcm53xx/base-files/etc/board.d/02_network
>>> @@ -13,6 +13,9 @@ bcm53xx_setup_interfaces()
>>>       asus,rt-ac87u)
>>>           ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "wan"
>>>           ;;
>>> +    asus,rt-ac88u)
>>> +        ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 extsw" "wan"
>>> +        ;;
>>>       linksys,panamera)
>>>           ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4 lan5 
>>> lan6 lan7 lan8 extsw" "wan"
>>>           ;;
>>> diff --git 
>>> a/target/linux/bcm53xx/base-files/etc/init.d/set_nvram_vars 
>>> b/target/linux/bcm53xx/base-files/etc/init.d/set_nvram_vars
>>> new file mode 100755
>>> index 0000000000..9c2b3ebf4d
>>> --- /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 still don't know what to do about it.
>> Does et0macaddr really break CFE somehow?!
> 
> What I remember from my tests from 2021 is that if it's set to anything 
> other than 00:00:00:00:00:00, CFE will complain about it and won't host 
> the recovery web page. I saw the log on the console which I don't have 
> access to anymore. This might be what I saw:
> https://github.com/RMerl/asuswrt-merlin.ng/blob/6b60627c8c9c5c0271e956c914afb5277f81f9c4/release/src-rt-6.x.4708/cfe/cfe/ui/ui_netcmds.c#L465 
> 
> 
> The Asus firmware sets et0macaddr to 00:00:00:00:00:00:
> https://github.com/RMerl/asuswrt-merlin.ng/blob/acd9e4c4bde858f9411636ac40e7f2cf267de285/release/src/router/rc/init.c#L3229 
> 
> 
> Restoring nvram via CFE makes it unset.
> 
> I wanted to unset it at each boot for fail-safe purposes like the Asus 
> firmware does, in case the user plays around with that variable.
> 
> We need to set the variables for wireless in any case.
> 
>> Why do you need to set both et1macaddr and et2macaddr?
> 
> et1macaddr is for gmac1, et2macaddr is for gmac2. Though we don't use 
> gmac2. We can get rid of it.
> 
>> Should they really use MAC of wireless interfaces? It smells fishy.
> 
> Broadcom's init code sets MAC address of wireless interfaces from 
> etXmacaddr anyway:
> https://github.com/RMerl/asuswrt-merlin.ng/blob/bb7ff5cb667fac6e41d14d983751985670952c10/release/src/router/rc/sysdeps/init-broadcom.c#L3843 
> 
> 
> We just use 0:macaddr & 1:macaddr since these are always properly set, 
> either with CFE's nvram restore or after Asus firmware's nvram changes. 
> The same can't be said for et1macaddr & et2macaddr.
> 
> I've seen your recent change on Luxul XWR-3150 devicetree:
> https://github.com/torvalds/linux/commit/c8442f0fb09ca3d842b9b23d1d0650f649fd10f8 
> 
> 
> I can send a patch to set mac addresses on the devicetree instead.
> 
> In conclusion this is what's left:
> - unset et0macaddr
> - set wireless LED behaviour

Update:

I ran a few tests on my Asus RT-AC88U. I realised resetting nvram will 
create the et1macaddr variable with the original MAC address, et0macaddr 
& et2macaddr will be unset. This gives me leeway for the MAC address 
patch I will submit to upstream later today.

I found out holding the WPS button while power-on will cause CFE to 
restore nvram. That should be enough to keep us from doing any fail-safe 
operations for CFE and bog down on this any further.
I'm going to mention this on the device page for Asus RT-AC88U on 
OpenWrt Wiki.

I found this startup script for nvram quirks of various hardware, 
package/utils/nvram/files/nvram.init.
Seems like the perfect place to put the led behaviour variables for Asus 
RT-AC88U. I'll send another patch for it.

Expect new patches to upstream and OpenWrt.

Arınç



More information about the openwrt-devel mailing list