I'm currently working on device support for the Ubiquiti UniFi AP HD (UAP-AC-HD - ipq8064). TFTPBoot from U-Boot already works, also ETH is working with the correct MAC addresses. Currently I can't figure out how to get the WiFi cards (2x QCA9994) fully working.
Just loading the ath10k driver without any additional config results in working cards (clients connect successfully) with wrong (random?) MAC addresses.
Adding an entry in 11-ath10k-caldata script with ath10k_patch_mac lines (WiFi MACs are missing in flash, probably generated from ETH MACs) breaks the (default?) BDF loading. But even with the BDFs loaded from vendor firmware ath10k complains about "Invalid EEPROM contents" and "failed to initialise regulatory: -22".
Vendor firmware also has related messages in it's log (ol_regdmn_start: reg-domain param: regdmn=0, countryName=, wModeSelect=FFFFFFFF, netBand=FFFFFFFF, extendedChanMode=0.), but can successfully create WiFi networks.
Related: I didn't find the caldata yet, ETH MACs are stored on an "EEPROM" partition that is empty at the regular ath10k caldata offsets.
Any ideas what to check next? Help is highly appreciated - thanks!
if wifi MAC addresses is the only thing left to fix, you should file your Pull request on github as a draft or "WIP" (work in progress) and ask for help there. We need to see your DTS and the kernel log before and after these things you are trying.
It sounds like the wifi cards have a physical EEPROM with the calibration data and its not in the flash. When you use ath10k_patch_mac in the caldata script, but the caldata is not in flash, you cannot have qca,no-eeprom in the DTS at the same time.
Thanks for your input, unfortunately there's more left to do: I still have to figure out how to flash OpenWrt permanently. Also the device has a USB-C port that I didn't try to use yet.
Once I'll get to the thing booting OpenWrt from it's own flash, I'll open a PR. In the meantime, I can post logs or DTS nodes here if that helps.
I'm recommending opening a PR because it will get you more and better assistance / suggestions faster, with more eyes from developers on your commit so far. There's nothing wrong with opening a PR with WIP in the name or in draft mode. Even if you think you can get your commit perfect before making the PR, they will ask for changes after review anyway.
the only thing I can suggest is to look at a similar commit, this board should be slightly similar to the AP Pro (despite different generation of chips, it may help to see because its from the same company), installation is with TFTP using the reset button...
as for the USB port, it might only supply power, but its not certain. The manual / guide is very ambiguous about it saying "The USB 3C port is reserved for future use."
For now, you can try enabling usb nodes in the DTS, and make sure you have the necessary packages like kmod-usb-ohci kmod-usb2 kmod-usb3. Also, it may be possible that a GPIO output controls the USB power. If you have a multimeter you can try to trace the pinouts of the USB port instead, to see if the data lines actually go anywhere near the SOC.
can you post a fw_printenv? ( printenv from uboot better if not setup yet in OS @ package/boot/uboot-envtools/files/ipq806x patchpossiblyrequired for this relatively simple )
I only tested WLAN <-> LAN throughput which was stable at around 500 MBit/s on average and 650 MBit/s peak (iperf3, same room, around 2 m distance to AP, 2x2 client).
Is it similar result to what I achieved. I had to enable hardware flow offload to make it possible. I wonder if it is possible to handle ~1Gb/s between the eth0/eth1 ports.
I’m finding that the Ethernet port labeled SECONDARY doesn’t actually work under OpenWrt. This is the one that comes up as eth0 in OpenWrt. ifconfig shows transmits (but nothing shows up at the other end of the cable) and no receives. I’m using a current trunk build.
There is the same situation. But for now I don't mind as I don't use the second port. Another issue is, The exact model of the wifi card is specified on the AC-LR device, but not on the HD device. It looks like 80211acn. 160 mhz not working. I tried changing the country settings, changing the channel. It didn't work. I am currently getting the same performance as the AC-LR. Max 400mbps. However, HD is a much more powerful device. Is there a possibility that this will be fixed in future versions of openwrt? I am using Snapshot version 21.2.
This is purely cosmetic and has no functional effects. OpenWrt maintains a small database of common PCI IDs as part of iwinfo itself (not lspci, as more commonly used on big distros), whenever your IDs are not known to OpenWrt it falls back to generic mac80211 identification instead. This string isn't used anywhere by the system, aside from putting a nicely identifiable label into the webinterface - so it really is merely cosmetic, without any functional implications.
First of all, many thanks to the developers for the Openwrt support on the device. I am using ath10k non ct firmware. Wireless speed is 300 megabits when I use 160 mhz. When I use 80 mhz it is 500 megabits. The adapter I am using is Intel AX200. What do I need to do to use 80+80 mhz? Does anyone have information? And will it increase to 1 gigabit wireless speed this way? With stock firmware I can reach 1 gigabit speed with the same AX200 card.
