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

Tue Oct 6 18:11:12 PDT 2026

Hello Robert,

Thanks for the direction. The RAX120 v1 unit reports the following
through Linux socinfo:

    machine:  IPQ8074
    revision: 1.2
    soc_id:   323

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