[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