ASUS Lyra Trio MAP-AC1750 - successfully booted OpenWrt with functional 5 GHz Wi-Fi (2.4 GHz testing needed)

Hardware information
Specifications:
  • SoC: QCA9563
  • DRAM: 128MB DDR2
  • Flash: 25L256 32MB SPI-NOR
  • LAN/WAN: 2x1000M QCA8334 (labeled as “LAN” and “LAN/WAN” respectively)
  • Wi-Fi 1: QCA9563
  • Wi-Fi 2: QCA9880 (5 GHz band only)
  • Bluetooth: AR3012
  • LED: RGB (each pyramid leg has an LED, but they cannot be independently controlled. For example, if you want the LED to be blue, all three LEDs will have to be blue. You cannot have different colors on each leg.)
MAC addresses as verified by OEM firmware:
LAN and LAN/WAN port     2.4G + 1
2.4G                     Label MAC (stored in factory offset 0x1002)
5G                       2.4G + 2 (stored in factory offset 0x5006)
MTD and GPIO Information (obtained while the device was running OEM firmware):
user@Lyra_Trio:/tmp/home/root# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00010000 "Bootloader"
mtd1: 00010000 00010000 "nvram"
mtd2: 00010000 00010000 "Factory"
mtd3: 01ca0000 00010000 "linux"
mtd4: 01b58600 00010000 "rootfs"
mtd5: 00300000 00010000 "jffs2"
mtd6: 02000000 00010000 "ALL"

user@Lyra_Trio:/sys/firmware# cat /sys/kernel/debug/gpio
GPIOs 0-22, ath79:
 gpio-2   (sysfs               ) in  hi
 gpio-5   (sysfs               ) in  hi
 gpio-7   (sysfs               ) out hi
 gpio-8   (sysfs               ) out hi
 gpio-14  (sysfs               ) out lo
 gpio-15  (sysfs               ) out hi
 gpio-16  (sysfs               ) out hi
Installation
Notes before proceeding:
  • I am not 100% sure if the firmware images are in the correct format. I have backed up the contents of the flash when the device was still running OEM firmware.
  • The code is not perfect and may contain bugs or incorrect sections.

If you acknowledge the risks and would like to try it, please build from this branch.

Windows:

Flashing OpenWrt via ASUS’ firmware restoration tool might work, but I haven’t tested this method yet.

Linux (using Arch Linux and tftp-hpa as an example here):
  1. Set your computer's IP to 192.168.1.10 with a subnet mask of 255.255.255.0.
  2. Press the reset button and plug in the power adapter, keeping the button pressed until the LED shows magenta/purple.
  3. Rename openwrt-ath79-generic-asus_map-ac1750-squashfs-factory.bin to factory.bin and upload it to the device.
$ tftp
(to) 192.168.1.1
tftp> binary
tftp> put factory.bin
tftp> quit
  1. Be patient and wait until the flashing process completes. After a brief period of flashing between magenta and green, there will be a long period of flashing blue. When the LED stays blue and no longer flashes, you can try connecting to the device.
Background

I recently found some blog posts by "Kulska" [1] about OpenWrt on Lyra Trio, which include code for OpenWrt 19.07 [2] and 22.03.0 [3].

The posts are very helpful, and after some adaptation, I managed to get the latest OpenWrt working on Lyra Trio. Note that I am a beginner when it comes to adding OpenWrt support for new devices and have little experience in programming or embedded device development, so please use the code with caution.

Their OpenWrt 19.07 post states that GPIO14 is RED, GPIO15 is GREEN, and GPIO16 is BLUE, but I found that GPIO16 is actually RED and GPIO14 is actually BLUE.

I am not sure about how they flashed OpenWrt. According to their post, you transfer the image to the device and then use dd if=new.bin of=/dev/mtdblock3 to flash, but I am not sure whether the new.bin refers to the initramfs-kernel one or the squashfs-sysupgrade one. After referring to the code of other devices in OpenWrt, I decided to try producing a "factory" one and used the aforementioned tftp method to flash.

I plan to use the device as an AP and have tested only a few things currently. I built an image with LuCI, connected to the device via the "LAN" port, and tried starting Wi-Fi networks.

Issues / Questions
1. 2.4 GHz Wi-Fi not tested

I have trouble with the 2.4 GHz Wi-Fi on my 2 Lyra Trio units. They seem to have a weak signal when receiving and are not broadcasting a detectable network when transmitting.

Previous content, hidden as it is probably hardware issue (Click to view)

I wanted to check the 2.4 GHz Wi-Fi's client function, but the scan returned very few results, as if the antenna had little power or its signal strength was really weak. Next, I checked its AP function, but my phone could not detect the network, even though in LuCI the 2.4 GHz network appeared to be successfully enabled.

System log excerpt: (Click to view)
[Mar 8, 2026, 1:27:16 AM UTC] daemon.notice: hostapd: Set MLD config: [ ]
[Mar 8, 2026, 1:27:16 AM UTC] daemon.notice: hostapd: Reload all interfaces
[Mar 8, 2026, 1:27:16 AM UTC] daemon.notice: wpa_supplicant[1610]: Set MLD config: [ ]
[Mar 8, 2026, 1:27:17 AM UTC] daemon.notice: hostapd: Reloaded settings for phy phy1
[Mar 8, 2026, 1:27:17 AM UTC] daemon.notice: netifd: radio1 (3423): wifi-scripts: Starting
[Mar 8, 2026, 1:27:17 AM UTC] daemon.notice: netifd: radio1 (3423): command failed: Not supported (-122)
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Set MLD config: [ ]
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Reload all interfaces
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: wpa_supplicant[1610]: Set MLD config: [ ]
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Reloaded settings for phy phy1
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: wpa_supplicant[1610]: Set new config for phy phy1
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Set new config for phy phy1: /var/run/hostapd-phy1.conf
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Reload config for bss 'phy1-ap0' on phy 'phy1'
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Configuration file: Reading configuration file '<inline>'
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: netifd: Network device 'phy1-ap0' link is down
[Mar 8, 2026, 1:27:18 AM UTC] kern.info: [  504.998992] br-lan: port 2(phy1-ap0) entered disabled state
[Mar 8, 2026, 1:27:18 AM UTC] kern.info: [  505.162134] br-lan: port 2(phy1-ap0) entered blocking state
[Mar 8, 2026, 1:27:18 AM UTC] kern.info: [  505.167981] br-lan: port 2(phy1-ap0) entered forwarding state
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: netifd: Network device 'phy1-ap0' link is up
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: hostapd: Reloaded settings for phy phy1
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: netifd: radio1 (3423): wifi-scripts: Configuring 'phy1' txantenna: 4294967295, rxantenna: 4294967295 distance: 0
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: netifd: radio1 (3423): wifi-scripts: Preparing interface: phy1-ap0 with MAC: (MAC address redacted)
[Mar 8, 2026, 1:27:18 AM UTC] daemon.notice: wpa_supplicant[1610]: Start pending MLD interfaces
[Mar 8, 2026, 1:27:19 AM UTC] daemon.warn: odhcpd[1839]: No default route present, setting ra_lifetime to 0!
[Mar 8, 2026, 1:27:20 AM UTC] daemon.info: dnsmasq[1]: read /etc/hosts - 12 names
[Mar 8, 2026, 1:27:20 AM UTC] daemon.info: dnsmasq[1]: read /tmp/hosts/dhcp.cfg01411c - 4 names
[Mar 8, 2026, 1:27:20 AM UTC] daemon.info: dnsmasq[1]: read /tmp/hosts/odhcpd.hosts.lan - 2 names
[Mar 8, 2026, 1:27:20 AM UTC] daemon.info: dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses

It is showing 4294967295 for the number of antennas (?), which might indicate some issues with my code.

By the way, the MAC address for 2.4 GHz Wi-Fi is correct (matches OEM firmware and label).

5 GHz Wi-Fi works fine; my phone can connect and the MAC address is also correct.

2. Activating Multiple GPIOs for Combined Colors

The OEM firmware (and firmware recovery/TFTP flashing) supports LED colors including cyan, magenta, yellow, and white.

For example, in the GPIO information under the "Hardware Information" section, the device is displaying a yellow LED (GPIO 15 and 16, red and green combined).

If you know of any methods to activate multiple GPIOs simultaneously, please share!


Thank you very much for reading and testing. Any help would be greatly appreciated, and I look forward to your feedback.


  1. Also known as "Saren" on PTT, a popular Taiwanese BBS forum. If you're a PTT user, please help contact them to facilitate attribution if support for this device is added to OpenWrt. ↩︎

  2. https://kulska.blogspot.com/2022/08/openwrt-1907-asus-lyra-trio-map-ac1750.html ↩︎

  3. https://kulska.blogspot.com/2022/10/openwrt-22030-asus-lyra-trio-map-ac1750.html ↩︎

This is most likely a deathblow to any QCA device.

You have to find ath9k calibration block in system partitions, usually something at multiple of 1k/2k offset starting with at least partial mac address.
Can you binwalk either kernel from flash or oem upgrade file and reach and decompile their dts? Thar should give some clues.

ath10k is not that bad, rest of SoC is a can of slugs - slow cpu does not make much throughput, nor slow ram adds much speedup from flow offload.

You can dump kernel partition via asus firmware

ssh user@192.168.50.1 "cat /dev/mtdXro" > kernel.bin

0x440 bytes at offset 0x1000
see the place in hexdump....

I restored the device to original firmware and reset everything, but 2.4 GHz Wi-Fi still doesn't work. Admittedly, I didn't test the 2.4 GHz Wi-Fi in OEM firmware (before the very first flashing of OpenWrt), therefore it may be hardware issue, not the firmware issue.

I have another Lyra Trio, so I'll test the other unit at a later time to see if it works.

The other unit is running OEM firmware and has never been flashed with OpenWrt, but unfortunately its 2.4 GHz Wi-Fi is also non-functional.

If you have a fully functional unit, I'd appreciate it if you could adopt and upstream the patch.