Wallys DR9074-6E(PN02.7) QCN9074 refuses to work on 6GHz band

[Mariusz]

I am just relying on what I am told by their support, really wanted to
deploy a 6E SoftAP for my home lab and expected some hackery but this
is like an early dev sample kind of environment with most stuff in the
works.

For the time being this is exactly what I did with hardcoding board_id
into the driver: /drivers/net/wireless/ath/ath11k/qmi.c:2234:
ab->qmi.target.board_id = 0xA2;
After this no more board.bin hackery is needed and correct firmware is
loaded from board-2.bin. This of course means I cannot use any other
ath11k card in the system as it would be forced to this id but that's
not an issue. My objective is to have only 6E add on to my network.

Now correctly reported:
[ 1525.142906] ath11k_pci 0000:07:00.0: chip_id 0x0 chip_family 0x0
board_id 0xa2 soc_id 0xffffffff
[ 1525.142909] ath11k_pci 0000:07:00.0: fw_version 0x270206d0
fw_build_timestamp 2022-08-04 12:48 fw_build_id
WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

and the correct FW is loaded with 6Ghz channels enabled.


Debug is no longer showing any errors, hostapd is not reporting
anything wrong everything pretends to work but it does not in
practice. What puzzles me is that raw dump of wireless frames off
AX210 client shows there is beacon transmission from the module but
for whatever reason the client ignores it as a valid AP option.

airodump-ng -C 6115 -i wlan0mon --bssid C4:4B:D1:D0:00:7E

Freq 6115 ][ Elapsed: 0 s ][ 2022-11-18 13:48

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

C4:4B:D1:D0:00:7E -46 12 0 0 33 54e WPA3 CCMP SAE dupa

On Sat, 19 Nov 2022 at 16:16, Robert Marko <robert.marko at sartura.hr> wrote:
>
> On Sat, Nov 19, 2022 at 2:40 PM Mariusz <enebeo at gmail.com> wrote:
> >
> > I have contacted Wallys again but I am skeptical about resolution.
> > They don't consider board_id an issue and provided the same response,
> > on integrated systems it is due the bootloader to set it properly so
> > it is not fused and obviously not included in x86 scenario.
>
> Hi, this is not really the case, how would the bootloader set the board_id
> which is supposed to be fused on the device so FW would report the correct one?
> You can only workaround that by hardcoding it in the driver or on non-x86
> in DTS and force-loading the correct BDF that way.
>
> > Since this
> > is a private project I doubt QCA will support my efforts and free
> > access to their portals gives nothing. Found online some SDK for
> > version ath10k/IPQ8074 and athtestcmd to deal with OTP/fusing but
> > that's far beyond home project effort.
> >
> > Tried also to compile it in OpenWRT with moderate success. ath11ko /
> > qrtr.ko modules are built but the module never goes past power on
> > success.
> > mhi mhi0: Requested to power ON
> > mhi mhi0: Power on setup success
> > mhi mhi0: Wait for device to enter SBL or Mission mode
> >
> > Even the newest kernel in OpenWRT master development branch 5.16 is
> > quite behind and backporting anything is another non-trivial task.
>
> ath11k won't work in OpenWrt master currently, I have been supporting IPQ807x
> and recently PCI version as well out-of-tree with hopes of getting it soon into
> OpenWrt once 6.1 backports become available as that gets rid of like 300-ish
> backported patches.
>
> Regards,
> Robert
> >
> > On Fri, 18 Nov 2022 at 15:06, Sven Eckelmann <sven at narfation.org> wrote:
> > >
> > > On Friday, 18 November 2022 13:48:43 CET Mariusz wrote:
> > > > Mine is from a different supplier - Wallys - and I bought it 2 weeks
> > > > ago but not sure how old their stock is. PCB looks slightly different
> > > > than Pinapple's. Is it likely to have the same issue?
> > >
> > > It definitely has the same issue (because you reported that board_id is
> > > 255/0xff) but I have no idea whether Wallytech ever fixed it. At least I was
> > > never in contact about this problem with them. But sending around precompiled
> > > kernel module binaries (for an unknown kernel build), with some hacks to fix
> > > their hardware production errors (missing module id fusing in the OTP for
> > > their separately sold modules), doesn't make me confident that they are able
> > > to solve this problem correctly.
> > >
> > > In their defense, QCA doesn't make it really easy. It seems like their
> > > reference designs with Pine on 6Ghz are (mostly?) for (embedded Linux) APs
> > > which use the normal flash (NOR or NAND) to store the calibration data. And
> > > for these devices, they use the devicetree (or various other hacks) to load
> > > the correct board data.
> > >
> > > Wallystech has to find the correct document on createpoint which describes the
> > > process. It was something like "module" "board id" "fusing". But it is not the
> > > "Board ID Fusing for 802.11ax WLAN AP Chipsets" which only describes the way
> > > how you would to it for thei internal wifi of the IPQ807x/IPQ60xx/... SoC.
> > > You/they are searching for the corresponding document for Pine IPQ9074. Most
> > > likely hidden in some QDART documents.
> > >
> > >
> > > Regarding the problem that some countries are not allowing 6GHz: You have to
> > > either get a firmware from QCA which has it enabled or you modify the BDFs
> > > ("board-" files in the board-2.bin) to enable 6GHz in the (enabled) embedded
> > > REGDB of the BDFs for the specific country. Unfortunately, the data structures
> > > of the BDF are not officially documented and you would need an official QSDK/
> > > ATH.11.X release from QCA to fetch the bdf2txt.py, txt2bdf.py and the
> > > corresponding template for your BDF to extract and modify it.
> > >
> > > Kind regards,
> > >         Sven
> >
> > --
> > ath11k mailing list
> > ath11k at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/ath11k
>
>
>
> --
> Robert Marko
> Staff Embedded Linux Engineer
> Sartura Ltd.
> Lendavska ulica 16a
> 10000 Zagreb, Croatia
> Email: robert.marko at sartura.hr
> Web: www.sartura.hr