> 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 <s...@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
