[RFC] IPQ8074 v1 / Netgear RAX120 v1: interest in support and review prerequisites

[RFC] IPQ8074 v1 / Netgear RAX120 v1: interest in support and review prerequisites

[Zephyr Madera]

Hello ath11k maintainers,

Robert Marko suggested asking here whether there is interest in supporting
IPQ8074 v1 before preparing a formal support series. I own a Netgear
RAX120 v1 and have an experimental OpenWrt port developed with AI
assistance. I would like to make the useful source work available for
review, without presenting it as upstream-ready.

Linux socinfo on the unit reports:

    machine:  IPQ8074
    revision: 1.2
    soc_id:   323

In the OpenWrt discussion, Robert explained that this early silicon was
intentionally left unsupported, differs in peripherals and clocks, does
not comply with the final 802.11ax standard, and lacks publicly available
ath11k firmware. I understand that successful local bring-up does not
resolve those concerns.

The bring-up was rebased to OpenWrt main at:
    edc6b8f160c798cd211893bc5df25aec7cfca838

The tested base uses Linux 6.18.55 and mac80211 backports 7.2. On this one
unit, recorded checks include Q6 startup, both internal PHYs, LAN1
management, and four client cases: 2.4 GHz and 5 GHz with WPA2-PSK and
WPA3-SAE. Those cases covered association, LAN-side DHCP/DNS, ping and a
checksum-verified local HTTPS transfer. These are limited bring-up
results, not standards-conformance, sustained-load or cross-device
qualification.

The source work has been separated for discussion into:
- Two candidate generic ath11k parser corrections: host-sized MAC/PHY
  record allocation and bounds on READY MAC-address array reads.
- Secure WCSS separate-M3 loading and its binding, retaining PAS6.
- IPQ8074 v1 register/descriptor/ring handling and legacy firmware
  startup/event compatibility.
- Separate RAX120v1 board, image and upgrade integration.

The generic corrections have been checked against the pinned OpenWrt
wireless stack, but have not yet been rebased and validated against the
current upstream wireless tree. The v1 development sequence also needs
review and reduction.

The working setup depends on owner-retained HK1.2 firmware and this
unit's calibration. A public, repeatable firmware acquisition path and
redistribution terms are unresolved. Source provenance, attribution and
DCO certification also need completion before formal submission. No
firmware blobs, calibration data, private settings or flashable images
are attached.

Could you advise on three points?

1. Is there any interest in reviewing IPQ8074 v1 support, or do the
   hardware and firmware constraints make this unsuitable for upstream?
2. If there is interest, what minimum firmware availability and hardware
   evidence would you need, and which tree should the initial source
   series target?
3. Independently of v1 support, would it be useful to submit the generic
   parser corrections separately if they still apply to current upstream?

I can follow up with focused source-only patches and sanitized test
evidence. Local button and diagnostic customizations are separate from
this proposed hardware work. I have the router available for coordinated
testing, but cannot claim testing on other IPQ8074 revisions.

Thank you for helping establish whether there is a useful upstream path.

Regards,
John

Re: [RFC] IPQ8074 v1 / Netgear RAX120 v1: interest in support and review prerequisites

[John Macias]

Hello,

A progress update on the IPQ8074 v1 question, in case it helps. Robert,
thank you for the earlier guidance on openwrt-devel. Your summary of why
v1 was left unsupported (early silicon, different peripherals and
clocks, pre-final 802.11ax, no public firmware) gave me a clear list to
work through, and I have tried to check each point rather than assume
the answers.

Everything below is from a single RAX120 v1 (IPQ8074 rev 1.2, SoC ID
323) on OpenWrt main with Linux 6.18.55 and backports 7.2. The work was
done with AI assistance.

1. Pieces that are not v1-specific, sent separately

- READY event MAC-address array bounds, ath11k and ath12k, now v2 for
  ath-next:
  https://lore.kernel.org/all/20261021-rdy-mac-array-bounds-v2-0-cf7f45f868dd@gmail.com/
- The mac_phy_caps stride overflow was already fixed in ath-next
  (7a246c72132e, 4c6eb712a91f); I sent an OpenWrt backport to
  openwrt-devel today.
- The secure WCSS separate-M3 loading, as an RFC on top of v14 of the
  WCSS secure PIL series:
  https://lore.kernel.org/all/20261025042100.1356088-1-dencity7@gmail.com/

2. Firmware availability

The HK1.2 firmware is included in NETGEAR's own public RAX120 downloads
(http://downloads.netgear.com/files/GDC/RAX120/). Six public releases
contain a complete HK1.2 set, in two builds:

  V1.2.1.22, V1.2.2.24, V1.2.3.28, V1.2.8.40:
    WLAN.HK.2.0-01792-QCAHKSWPL_SILICONZ-1.379352.1.389278.1
  V1.2.9.52, V1.2.10.56:
    WLAN.HK.2.0-01792-QCAHKSWPL_SILICONZ-1.379352.1.536141.4

I have a small script that an owner can run to download one of these
official images, check it against a pinned SHA-256 and extract the q6/m3
firmware and board file, without running anything from the image and
without touching per-device calibration. Repeated runs give
byte-identical results. This follows the b43-fwcutter model: the owner
fetches from the vendor and nothing is redistributed. NETGEAR's terms
do not explicitly cover extraction, so I am not suggesting adding these
files to linux-firmware. Both firmware builds work on the unit.

3. 802.11ax

I have no way to show conformance with the final standard and do not
claim it. What I can report is interoperability: a 27-case client test
on both bands, with an Intel AX200 and, for the two-client cases, a
MediaTek MT7925. It covers WPA2-PSK, WPA3-SAE and mixed mode at 20, 40
and 80 MHz on 5 GHz and 20 MHz on 2.4 GHz, plus reassociation, AP
restart, radio restart, channel reload, two clients on one band, one
client per band, and a bounded load case. All 27 ran; 23 pass. The
other 4 asked for 40 MHz on 2.4 GHz and came up at 20 MHz, which
hostapd logs as 20/40 coexistence with overlapping BSSes, so that is
expected behaviour rather than a fault. MU-MIMO, OFDMA, TWT and 160 MHz
are untested. If the draft-era HE behaviour is a concern, I would be
glad to hear whether an HE-disabled v1 profile would be a reasonable
starting point.

4. Silicon, peripherals and clocks

The v1 Wi-Fi block does differ from hw2.0, and each out-of-tree driver
change is tied to a specific documented or measured difference: ring
register offsets, TCL descriptor layout and DSCP maps, 16-bit ring size
fields, REO fragment-destination bits, RX TID/NSS field positions, four
WBM release rings, copy-engine interrupt offsets and tables, a shorter
INIT resource encoding, a 9-word VDEV start response, a CALDB request
with coldboot calibration off, a reported high_5ghz_chan of 6100, and
zero NSS in RX metadata for HT EAPOL frames. Each sits in a separate v1
path so existing hardware is unaffected.

Outside the Wi-Fi block:

- cpufreq does not recognise SoC ID 323 and falls back to a 1.38 GHz
  cap. I have left that alone, since the v1 voltage/CPR behaviour is not
  verified.
- The APSS watchdog appears to count about 20 times slower than the
  32768 Hz that qcom-wdt assumes (a 20 s pretimeout fired after about
  409 s).
- On a small fraction of boots (5 of 300 in the last long run), transmit
  on one QCA8075 port stopped while everything else kept working, and
  only a full reset cleared it. A PSGMII init change that gates the
  channel clocks, runs the soft reset and calibration, then resets the
  QCA8075 SERDES (closer to the vendor SDK sequence) gave 0 events in
  the following 200 boots. That run also changed the Wi-Fi driver, so
  it does not prove the cause, and I have not posted it yet.

I have not compared the remaining SoC peripherals register by register.

5. Questions

I would value your view on two points, and I am happy to be told if v1
is simply not something the project wants to carry:

1. Would owner-side extraction from the vendor's public images be an
   acceptable firmware story for IPQ8074 v1, or is redistributable
   firmware a firm prerequisite?
2. Is v1 support something you would consider reviewing, perhaps
   starting with an HE-disabled profile?

I can share the extraction script, hashes, measurements and the v1
series in whatever form is most convenient. No firmware or calibration
files are attached.

Thank you for your time.

John