Hi everyone,
I'm trying to unbrick an ASUS RT-AX89U after a failed flash attempt. I have a USB-TTL (UART) serial console cable connected to the board, and I have full access to the bootloader (U-Boot 2016.01, bootloader version 2.1.2.2).
I managed to isolate the correct physical port: the router only establishes an electrical link on port LAN 3 (eth0 PHY4 up Speed :1000 Full duplex). The problem is that it hangs completely when trying to pull the stock firmware via TFTP.
Environment and troubleshooting steps taken so far:
- Server IP (Windows 10 PC): 192.168.50.75 (Manually set with subnet mask 255.255.255.0 and gateway 192.168.50.1).
- Device IP (Router): 192.168.50.1.
- Filename: RT-AX89U.trx located in the root folder of the TFTP server.
- Software tested: Tftpd64 (with Bind active to the
.50.75 IP and only the TFTP Server service enabled) and the Windows native TFTP client via CMD (tftp -i 192.168.50.1 PUT...).
- Security: Windows Defender Firewall is completely turned off (for both Public and Private profiles), and the network adapter has Green Ethernet/Energy Efficient Ethernet disabled, forced manually to 1 Gbps Full Duplex.
U-Boot Serial Console Log:
RT-AX89U# setenv ipaddr 192.168.50.1
RT-AX89U# setenv serverip 192.168.50.75
RT-AX89U# printenv serverip
serverip=192.168.50.75
RT-AX89U# tftpboot 0x4b000000 RT-AX89U.trx
ipq807x_eth_halt: done
eth0 PHY4 up Speed :1000 Full duplex
ipq807x_eth_init: done
switch prereq:0
Using eth0 device
TFTP from server 192.168.50.75; our IP address is 192.168.50.1
Filename 'RT-AX89U.trx'.
Load address: 0x4b000000
Loading: *
As you can see, the router initializes the eth0 interface correctly, identifies the server environment and the filename variables, launches the request, but then hangs indefinitely on the very first asterisk (*). If I try to force a reverse PUT from the Windows CMD while the router is listening, Windows immediately returns "Connection request failed".
Does anyone know if this specific U-Boot requires an extra network initialization command to bridge the ipq807x switch, or if there is a known issue with the ARP buffer size in Windows blocking the incoming traffic?
Thank you very much in advance for your help!
Tftp is a client, the router is acting as a client too.
You could however try to use tftp to verify the functionality of the tftpd64, which is the right tool for this.
You could also try the restoration tool from ASUS.
Quick update:
I have fully double-checked the server setup and environment to rule out common Windows/network issues:
- Disconnected any other network interface (WiFi completely disabled) to avoid routing confusion.
- Hard-blocked Tftpd64 to bind strictly to 192.168.50.75 in the settings.
- Completely disabled Windows Firewall via netsh (
netsh advfirewall set allprofiles state off).
- Removed the Default Gateway on the PC network adapter to avoid Windows APIPA/Unidentified network drops.
Even with the server locked down and listening strictly on .50.75, the Tftpd64 Log Viewer remains completely blank when U-Boot reaches the Loading: * stage. No read requests are hitting the application layer at all, and a reverse PUT via command line still returns connection dropped.
I also attempted to force the hardware ASUS Rescue Mode (holding Reset/WPS during power-on), and while the power LED blinks slowly, the internal switch web server at 192.168.50.1 is unreachable.
It really looks like the ipq807x switch registers or MDIO interfaces are not properly bridging data packets between the physical LAN 3 port (PHY4) and the CPU at the bootloader stage, despite the electrical link being up at 1000Mbps.
Are there any known U-Boot environment variables or specific switch initialization commands I should run from the prompt to unmask or unblock the interface before calling tftpboot?
Update: I managed to boot into the kernel stage and captured the full boot log from the serial console. It seems the system boots up but struggles with the Qualcomm HSL/switch configuration and driver mappings, spamming the same error indefinitely.
Here is the entire console log sequence:
[ 14.487868] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 14.492907] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 14.499187] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 15.527936] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 15.527983] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 15.533024] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 15.539408] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 15.556805] br-lan: port 1(10g-sfp) entered blocking state
[ 15.556846] br-lan: port 1(10g-sfp) entered disabled state
[ 15.561313] nss-dp 3a003000.dp5-syn 10g-sfp: entered allmulticast mode
[ 15.566889] nss-dp 3a003000.dp5-syn 10g-sfp: entered promiscuous mode
[ 15.594084] br-lan: port 2(10g-copper) entered blocking state
[ 15.594131] br-lan: port 2(10g-copper) entered disabled state
[ 15.598947] nss-dp 3a007000.dp6-syn 10g-copper: entered allmulticast mode
[ 15.604801] nss-dp 3a007000.dp6-syn 10g-copper: entered promiscuous mode
[ 16.567829] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 202.727823] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 202.732862] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 202.739130] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 203.767797] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 203.767836] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 203.772874] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 203.779145] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 204.807797] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 204.807827] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 204.812866] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 204.819135] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 205.847799] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 205.847838] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 205.852877] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 205.859147] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev is NULL
[ 206.887796] hsl_phy_phydev_get[775]:ERROR:phy_addr 8 phydev is NULL
[ 206.887827] hsl_phy_phydev_get[775]:ERROR:phy_addr 9 phydev is NULL
[ 206.892867] hsl_phy_phydev_get[775]:ERROR:phy_addr 10 phydev is NULL
[ 206.899135] hsl_phy_phydev_get[775]:ERROR:phy_addr 11 phydev
Additionally, I have confirmed that this router is a B2 hardware revision. The built-in ASUS Firmware Restoration Web UI is known to be broken or behaving differently on B2 compared to the older B1 revision, which explains why the stock rescue utility is completely unreachable even with a slow-blinking power LED.
It looks like the ipq807x HSL driver in this OpenWrt build is unable to map or probe the PHY devices (addresses 8-11) on this specific B2 board layout, causing the network bridge to drop the 10G interfaces and leaving the switch completely inoperable.
Does this point to a missing device tree (DTS) patch or an updated bootloader configuration specifically for the RT-AX89U B2 revision to properly probe the MDIO bus? Any guidance on how to bypass this or force flash via console commands would be highly appreciated!
Dude, don't put 50% of your post in the code snippet.
You should still be able to recover back to stock, using TFTP.
My bad about the formatting inside the code snippet!
To clarify: the main issue I'm facing is that during the U-Boot stage, when I run tftpboot 0x4b000000 RT-AX89U.trx and it hits Loading: *, it hangs indefinitely.
I am tracking this live via the USB-TTL serial console, and my Tftpd64 Log Viewer on Windows remains completely blank. No read requests are hitting the server layer at all, even with Windows Firewall completely disabled via netsh and the PC interface forced to 192.168.50.75 (with no default gateway to avoid APIPA drops).
Since the kernel log shows the ipq807x HSL driver failing to map the PHY devices later on, I suspect U-Boot might also be struggling to route the UDP packets correctly through the LAN 3 port on this B2 revision.
Since TFTP client/server communication is failing to initiate from the router side, do you know of any specific U-Boot environment variables or switch commands I can run from the prompt to manually force the interface open or clear the ARP cache before executing tftpboot?
Assume you've tried all ports ?
I also assume you've used a tftp client from a client, to verify tftp server works ?
There's no == between U-Boot and OpenWRT.
You're totally right, U-Boot and the kernel drivers are completely separate entities. My bad for mixing up their behaviors.
Regarding your points:
- I've been focusing strictly on LAN 3 because it was the only port triggering the "eth0 PHY4 up Speed :1000 Full duplex" message in the log when connected. However, I am going to swap the cable across every single physical LAN and WAN port and run the
tftpboot command on each one to see if U-Boot routes traffic through a different physical map on this B2 board.
- For the TFTP server, Windows network profiles have been tricky; when U-Boot resets the network interface, Windows drops the link status for a split second, which might be breaking the Tftpd64 binding.
I will double-check the server using a local client loopback test to guarantee it's 100% responsive, and then I'll report back after trying the TFTP transfer on every single physical port of the router.