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 <[email protected]>
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ç
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
