[OpenWrt-Devel] ath10k TPC reg. domain incorrect?

Sam Samy to.swami1 at gmail.com
Tue May 14 18:00:12 PDT 2019


> Yes, the implemented method for reading the data is not correct for the
> wave 2 cards (and maybe also other). You can try the attached hack. At
> least this worked in 2017 when I've poked around in the stuff with
> Christian Lamparter.

Latest code already seem to be doing this.

Thanks

On Tue, May 14, 2019 at 1:33 AM Sven Eckelmann <sven at narfation.org> wrote:
>
> On Monday, 13 May 2019 22:58:00 CEST Sam Samy wrote:
> >  I installed master branch openwrt onto Asus MAP-AC2200 AP. It has tri
> > band. Its based on IPQ4019 DK04 QCA reference platform. 2 radios
> > (2Ghz/5Ghz) on AHB bus and one 5GHZ on PCIe bus. Its generally working
> > fine except one problem in 5Ghz. On both the 5Ghz radios the RSSI is
> > pretty low on any 5Ghz channel I put it in.  In one feet range I see -60dB
> > RSSI, where as the stock firmware that came with the AP gives an RSSI
> > of -36dB at one foot distance.The downstream transmit rates are MCS8/9
> > for most part. The 2Ghz is working fine.
>
> It could be the boarddata which contains more than the targetpower and CTLs
> (and thus not necessarily visible in tpc_stats). As first check, test whether
> your board-2.bin has the md5sum 34c1e73e609a27eb9848fdc89cbc2be7 for
> /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin. Also check that the correct
> BDF (with the variant string is loaded). But this should only affect
> the QCA4019 5GHz PHY because the QCA9886 boarddata is generated here using the
> pre-cal data from art (unsure whether this is valid or not for this board and
> bootup sequence).
>
> You can just check with the ath10k-bdencoder [0] from qca-swiss-army-knife
> whether the board files from board-2.bin are the ones which also your stock
> firmware is loading.
>
> The next big problem are filters in the rx/tx chains [1]. The ieee80211-freq-
> limit in the DTS file should assist you and not allow you to chose the wrong
> channel/frequency for a specific PHY. But maybe the author accidentally
> switched the settings in the board and actually wanted the lower 5GHz channels
> on the SoC 5GHz PHY and the the upper 5GHz channels on the PCIe card? This
> would be at least worth a try.
>
> > What is the reg. domains 0x20 and 0x58 value points to?
>
> It is 20 (0x14) and not 0x20. Same for 58 (0x3a)
>
> Btw. the regd numbers from QCA can be checked in regd_common.h [2]. The
> mapping in regDomainPairs is not necessarily correct because someone has to
> take them from the newest proprietary driver and use them to update the ath*k
> stuff.
>
> >   Looks like ./sys/kernel/debug/ieee80211/phy2/ath10k/cal_data is junk
> > for both the 5Ghz radios even though the
> > pre-cal-pci-0000:01:00.0.bin/pre-cal-ahb-a800000.wifi.bin is correct.
>
> Yes, the implemented method for reading the data is not correct for the
> wave 2 cards (and maybe also other). You can try the attached hack. At
> least this worked in 2017 when I've poked around in the stuff with
> Christian Lamparter.
>
> Kind regards,
>         Sven
>
> [0] https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-bdencoder
> [1] https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=41a86debe3c0a01e075e749d0bb1c6d631e35c32
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/tree/drivers/net/wireless/ath/regd_common.h?id=5fad78689a9229d08ea11af53e48de3c2a845ea3#n29



More information about the openwrt-devel mailing list