[RFC] Netgear RAX120 v1 OpenWrt bring-up: source preparation and review direction

[Robert Marko]

On Wed, 7 Oct 2026 at 03:11, Zephyr Madera <dencity7 at gmail.com> wrote:
>
> Hello Robert,
>
> Thanks for the direction. The RAX120 v1 unit reports the following
> through Linux socinfo:
>
>     machine:  IPQ8074
>     revision: 1.2
>     soc_id:   323

Yeah, so its using the v1 SoC which intentionally is unsupported both
in OpenWrt and
in upstream.

Cause that is basically preproduction silicon that even has different
peripherals, clocks
not to mention that it's NOT compliant with the ratified/final 802.11ax at all.

So it's intentionally not supported, nor the ath11k FW is publicly
available for it.

So, for a start send the patches to the ath11k mailing list or at
least ask if they are interested
in supporting it at all.

Cause, honestly I know only of maybe 2 boards that were sold with the
v1 SoC, both in really
small quantities due to price, Asus AX89X A1/2 revision and this RAX120v1.

Regards,
Robert

>
> These values were read from the device, rather than inferred from the
> product name.
>
> The local port has now been rebased from 25.12 to OpenWrt main, pinned at:
>     edc6b8f160c798cd211893bc5df25aec7cfca838
>
> The tested build uses Linux 6.18.55 and mac80211 backports 7.2. It has
> been built and installed on this unit, with authenticated post-upgrade
> access and matching kernel/rootfs readback. This is a pinned
> main-based development build, not a claim of support in an official
> release.
>
> Validation during the main-based bring-up has covered:
> - LAN1 management at 1 Gbit/s, Q6 startup and both internal PHYs.
> - Four client cases: 2.4 GHz and 5 GHz, each with WPA2-PSK and
> WPA3-SAE; association, LAN-side DHCP/DNS, ping and a checksum-verified
> local HTTPS transfer.
> - Cooling spot checks and normal reboot with saved settings preserved.
> - WPS-triggered OpenWrt Ethernet failsafe over LAN1, followed by
> return to normal boot with settings unchanged. This tests OpenWrt
> failsafe, not bootloader recovery from an unbootable kernel.
>
> The latest userspace image also includes LuCI and clean OpenWrt
> factory defaults while retaining the required v1 hardware support.
> Installation preserved the existing configuration; the kernel and all
> 81 kernel modules remained unchanged. LuCI's HTTPS login page was
> checked. Local button customizations are tracked separately from the
> proposed upstream hardware work; the physical factory-reset erase test
> is still pending.
>
> The source discussion draft has been separated into four topics:
> 1. Two candidate generic ath11k parser fixes: host-sized MAC/PHY
> record allocation and bounds on READY MAC-address array reads.
> 2. Secure WCSS separate-M3 loading and its binding, retaining PAS6.
> 3. IPQ8074 v1 hardware and legacy firmware ABI support, including
> descriptor/ring handling.
> 4. RAX120v1 board DTS, DSA, image and upgrade integration.
>
> The four-topic baseline reconstructs the 27 recorded source files. The
> two generic changes were also checked independently of the v1 changes
> against the pinned OpenWrt wireless stack; reordering them preserved
> all 69 tested ath11k source/header hashes. They have not yet been
> rebased to Linux wireless-next, and the historical v1 patch sequence
> still needs review and reduction.
>
> The build still depends on owner-retained HK1.2 firmware and this
> unit's calibration. Firmware acquisition/redistribution, source
> provenance, contributor attribution and DCO certification remain work
> before formal submission. An independent byte-identical firmware
> rebuild has not been demonstrated. No firmware, calibration,
> credentials or flashable image is being sent with this reply.
>
> WAN DHCP/Internet/NAT, every Ethernet socket and multi-gig speed, cold
> power cycling, sustained-load testing and bootloader recovery remain
> unqualified. Automatic last-good-image rollback is not implemented.
> These are single-unit, AI-assisted bring-up results, with source and
> test records available for a focused review.
>
> Does this topic split make sense, and should the v1-specific
> ath11k/firmware compatibility work be discussed here first or directly
> with the wireless maintainers? I can provide the relevant source-only
> discussion material and sanitized evidence in the preferred format.
>
> Regards,
> John
>
>
> On Tue, 06 Oct 2026 14:48:26 +0200, Robert Marko <robimarko at gmail.com> wrote:
> > On Tue, 6 Oct 2026 at 02:49, John <dencity7 at gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > I would like to contribute development work for the Netgear RAX120 v1 so
> > > that it can be reviewed and maintained by the community. This is an
> > > initial request for review direction, not a claim of upstream readiness
> > > or a firmware release. The work was developed with AI assistance.
> > >
> > > A local port based on OpenWrt v25.12.5, commit
> > > f0a60eee2fe051741c643ea6118718aae1ef17fb, was installed on one RAX120 v1.
> > > Historical testing recorded persistent startup, both internal Wi-Fi bands,
> > > WPA2/WPA3 client traffic, DHCP/DNS and wired management.
> >
> > For a start, switch your base from 25.12 to the main branch.
> >
> > >
> > > The source reconstruction includes board/image/upgrade integration,
> > > remoteproc changes and 22 ath11k development patches. In a new offline
> > > check, an aggregate patch reproduced all 27 recorded modified files with
> > > exact SHA256 matches. Five fan-policy tests also passed. This is source
> > > reconstruction, not an independent clean firmware build.
> > >
> > > The driver work includes v1-specific register/descriptor/ring handling
> > > and legacy firmware startup/event compatibility. The installed system
> > > uses per-device calibration and owner-retained HK1.2 firmware inputs.
> > > These inputs, private configuration and flashable images are not being
> > > submitted. The source and tests still need provenance/licensing cleanup,
> > > a public per-device input procedure, a current-target rebase, feed pins,
> > > and documented installation/recovery and factory MAC layout.
> >
> > Wait, what is the SoC in the RAX120v1?
> >
> > Regards,
> > Robert
> > >
> > > I propose splitting generic ath11k corrections from RAX120v1 device
> > > support rather than submitting the entire development aggregate as one
> > > patch. Would that be the useful starting point, and which maintainers or
> > > current development tree should I coordinate with?
> > >
> > > I can follow up with individual source patches, reproducible tests and
> > > the precise validation limits as they are made ready. I am not attaching
> > > the mixed development archive to this initial message.
> > >
> > > Regards,
> > > John
> > >
> > > _______________________________________________
> > > openwrt-devel mailing list
> > > openwrt-devel at lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel