DR9574 Industrial WiFi7 Multi-Radio Board – One board, four M.2 radio modules, unlimited wireless deployment possibilities.
Built on Qualcomm IPQ9574 with MLO support, dual 10G Ethernet, wide temperature industrial design.
Lower BOM, less cabling cost, fewer maintenance workloads & power consumption for mass AP projects.
Ideal for system integrators, OEM hardware makers & wireless operators serving campuses, mining, smart factory & hospitality networks.
Testing samples & firmware customization available – DM to get your solution evaluation!
QSDK based firmware with QCA drivers is available , 3 card 3 band MLO support !! 4×4 MU MIMO or 2×2 MU MIMO configuration for 3 band MLO available.
https://wifi5.eu/dls/Wallys/DR9574
OpenWRT support available too !!
— working mainline OpenWrt port (10G + Wi-Fi 7 MLO)
Over the past few weeks we’ve brought the board up on a fully mainline stack — mainline Linux 6.12 + OpenWrt + ath12k, no QSDK and no out-of-tree datapath driver — and it now cold-boots from NAND into a working router/AP with both:
– 10G USXGMII ethernet (the AQR113C ports) bringing up a link and passing traffic with a DHCP lease, and
– a 3-link Wi-Fi 7 AP-MLD (one SSID across 6 / 5 / 2.4 GHz, WPA3-SAE) on mainline ath12k, with a real client associating and passing iperf traffic.
Getting the 10G working on mainline required root-causing and fixing an actual upstream kernel bug — a per-port clock that was left at the 10G rate regardless of the negotiated link speed. It’s a small, clean patch I’m preparing for the netdev mailing list, and it should help any IPQ95xx board with an Aquantia USXGMII PHY, not just this one.
Everything is public and reproducible here:
https://codeberg.org/insalata-fresca/openwrt-dr9574
(device tree, the patch set, and a write-up of the root cause.)
Why we think this could be interesting for you : a mainline-based firmware track means a current kernel with ongoing security fixes, an auditable, blob-minimal stack, and upstreamable patches — a strong story for customers who need long support windows, as a complement to the QSDK option.
W've pushed the mainline port further: the four 2.5G QCA8084 LAN ports are now the focus. The four copper PHYs come up and answer on mainline, and the 10G/USXGMII uplink and the 3-link Wi-Fi 7 MLO already work. But the 2.5G ports don't pass traffic yet,and I've traced it to one specific, well-understood gap.
In short: the QCA8084's internal XPCS never becomes reachable over MDIO. The chip's security-control config space (0xC90F000, which holds WORK_MODE and the SerDes/XPCS MDIO address fix-up) is readable but appears write-locked in our mainline bring-up. The driver writes the correct values (work mode 0x2f, XPCS MDIO address 7), but they don't take - so the XPCS stays at a default address, answers nowhere, and everything downstream (per-channel config, link, traffic) is blocked behind it. We are working on the final solution now.
The full write-up and the exact register evidence are on a public WIP page:
Status and the open question:
https://codeberg.org/insalata-fresca/openwrt-dr9574/src/branch/wip-qca8084-2p5g/docs/qca8084-2p5g-status.md
Register evidence (the actual readouts):
https://codeberg.org/insalata-fresca/openwrt-dr9574/src/branch/wip-qca8084-2p5g/docs/qca8084-2p5g-register-evidence.md
Repo root (device tree, 10G and Wi-Fi 7 patches):
https://codeberg.org/insalata-fresca/openwrt-dr9574