Can OpenWrt support 802.11ac midband & DFS on router, if OEM firmware does not support it, but underlying chipset and driver supports it?

For Developers
1

Hi,

I have been reading up on how 802.11ac mid-band and DFS is supported in OpenWrt through the ath10k driver. I am not certain I understand everything about how the ath10k driver works, but my understanding is that the open-source ath10k driver works in combination with the binary blobs of the firmware-X.bin and board-X.bin files, along with the router specific information in the ART partition, to overall provide 802.11ac functionality. However, I had a query on how 802.11ac mid-band and DFS works in the schema, which I will try to articulate with the specific example below of the Linksys EA8500 router.

The Linksys EA8500 uses the IPQ8064 CPU + QCA9980 wireless chipset, which is supported by OpenWrt for 802.11ac using the ath10k driver. The OEM software from Linksys does not support 802.11ac mid-band and DFS i.e. for 802.11ac, the OEM software only supports U-NII Band 1 (channels 36-48) and Band 3 ( channels 149-165) in the 5Ghz spectrum. It does not officially support midbands U-NII Band 2A (channels 52-64) and U-NII Band 2C (channels 100-144), which requires DFS support.

However the ath10k driver is documented as supporting 802.11ac mid-band and DFS, leading to my following questions -

  1. If one uses OpenWrt on the Linksys EA8500, then does the ath10K driver enable support for U-NII Band 2A (channels 52-64) and U-NII Band 2C (channels 100-144), which requires DFS support?

  2. If yes, does that mean that the OEM firmware is simply missing the functionality found in open source ath10 driver?

  3. If no, does that mean that support for U-NII Band 2A (channels 52-64) and U-NII Band 2C (channels 100-144) with corresponding DFS support is part of the binary blobs in firmware-X.bin and board-X.bin ? Does this also mean that these binary blobs are not only specific to a router model but also need to be released by vendor (in this case Linksys) with bands 2A and 2C OEM support, before OpenWrt can support these bands on such routers, even though the ath10k driver is open source?

My apologies for the length of this post, as well as if my questions are not articulated correctly above. I am a newbie and trying to learn. Perhaps part of this is my ignorance on the architecture of how the ath10k driver, the firmware-X.bin, the board-X.bin and the ARTpartition work together to provide 802.11ac functionality in OpenWrt. If anybody can be kind enough to help me understand at least that part, perhaps I can then try and figure out the answers to my questions above.

Any and all help would be highly appreciated! Thanks.

2
  1. Yes, (with some caveats, some mitigated; hardware restrictions limiting the frequencies to certain parts of the band (e.g. on tri-radio devices to ch36-64 on radio0 and ch100-169 on radio2) may exist, but not for this device).
  2. Yes, although the proprietary ath_pci driver would offer that feature as well, but Linksys opted not to expose it to the user.
  3. does not apply.
1 Like
3

Does that mean 802.11ac mid-band and DFS support is primarily part of the open source ath10k driver and not in the two binary blobs? Can you please help me understand roughly what is the role of each of those two binary blobs? Thanks.

4

OpenWrt uses the ath10k-ct firmware provided by Candela Technologies (maintained by @greearb under NDA from Qualcomm Atheros), combined with an open source driver that is optimised for running ath10k devices with the -ct firmwares.

OEM software mostly contains outdated firmware blobs that the manufacturer initially received from QCA when they started development, these are usually not updated unless something is seriously broken. Besides, there is also not so much commercial incentive to add features like DFS/TPC that would allow for operation in further frequency bands, when they might as well sell you a new device that is based on a newer ath10k blob and has been certified for these bands (not sure whether this is an issue though, I think many devices actually supported channels higher than 36-48 initially, but later received updates to disable these due to DFS requirements).

The art partition contains mostly calibration data to compensate for manufacturing tolerances of the RF chains and passive components (resistors, capacitors) of the matching network on the individual router's PCB, also stuff like information about power amplifiers (if present) and maximum transmit power.

Not quite sure about the bmi board_id stuff though, it has something to do with finding the appropriate firmware blobs and/or art partition position I think... But we struggled with DIR-842 C3 (that uses different partition layouts regarding art position, but they all run on the same OEM software, so it seems to magically detect that by the board_id (?)...)

1 Like
5

Thank you so much for the detailed explanation you provided. Very helpful.

I have further researched this topic to better understand it. I thought I'd shared it back with you and others who may read this thread in future with similar queries.

Here is my high-level understanding, of the answer to my architecture question. For ath10k-based routers, OpenWrt uses firmware binary blobs (firmware-X.bin), which have actual control of the RF hardware. They are available upstream from either Qualcomm or Candela, and are specific to a WiFi chipset family. These binary blobs determine (if not limit) what RF bands and what RF functionality are availble from the wireless chipset. They are loaded at boot-time by the ath10k driver from /lib/firmware, and are equivalent to an embedded OS that the chipset runs and provides service to higher levels.

In addition, board files (board-X.bin) are also loaded at boot-time by the ath10k driver from /lib/firmware. They contain calibration data for the wireless chipset, which is specific to that specific router model/version (i.e. a specific router board type). It is available upstream to OpenWrt from Qualcomm, as well as can be extracted from OEM firmware and submitted upstream, for distribution downstream subsequently.

Finally, the ART partition contains pre-cal data, which OpenWrt is responsible for loading at boot-time from the ART partition to a pre-cal file in /lib/firmware, which is then subsequently loaded by the ath10k driver into the wireless chipset. This pre-cal data is specific to the individual router. There is no other easy way to get this data (apart from perhaps factory re-calibration) other than from the ART parition, hence the importance of keeping a backup of it, for each individual router.

The combination of firmware, board calibration data and ART pre-cal data (as well as other individual router specific data like MAC address) provides RF services to the ath10k driver, which results in WiFi functionality being available to OpenWrt.

Also, the ath10k driver is available upstream from both Qualcomm and Candela to OpenWrt, corresponding to the upstream firmware blobs from Qualcomm and Candela respectively.

I may be wrong in my understanding above, since I am a newbie still trying to figure it out over the last one day. If so, I would appreciate the experts correcting me on it. Thanks.

1 Like