Thanks Sven for detailed information. Answers inline.. > 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).
The board-2.bin md5sum matches to the one you mentioned above. The openwrt pre-cal-ahb-a000000.wifi.bin/pre-cal-ahb-a800000.wifi.bin files md5sum did not match the one in board-2.bin. I replaced it with stock bin files and now it matches. Atleast for the AHB radios cal_data matches with bin file. The stock AHB boarddata files does not seem to match the one in the flash that openwrt is extracting. But still the openwrt tpc_stats does not match with stock firmware tpc. Its still has low power limits. AHB board-2.bin: ============= ~/ath10k-fw-tools/qca-swiss-army-knife/tools/scripts/ath10k$ ./ath10k-bdencoder -i board-2.bin FileSize: 24324 FileCRC32: 4329f4ee FileMD5: 34c1e73e609a27eb9848fdc89cbc2be7 BoardNames[0]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=20,variant=ASUS-MAP-AC2200' BoardLength[0]: 12064 BoardCRC32[0]: d7d6a9ea BoardMD5[0]: 238abb9e48096f217531b5a40398595b BoardNames[1]: 'bus=ahb,bmi-chip-id=0,bmi-board-id=21,variant=ASUS-MAP-AC2200' BoardLength[1]: 12064 BoardCRC32[1]: 9c975c5b BoardMD5[1]: ea158f8c0d5ddd11bb32e7d7a7979e4c PCIe board-2.bin: * There is no ASUS variant in this file in openwrt. * ============= ~/ath10k-fw-tools/qca-swiss-army-knife/tools/scripts/ath10k$ ./ath10k-bdencoder -i board-2.bin FileSize: 84928 FileCRC32: d65c17b1 FileMD5: 600730b0f0672c22ef2cfab32fda2a71 BoardNames[0]: 'bus=pci,bmi-chip-id=0,bmi-board-id=16' BoardLength[0]: 12064 BoardCRC32[0]: 165f27d1 BoardMD5[0]: c0fd21abadf20443153780b57f4c46a5 BoardNames[1]: 'bus=pci,bmi-chip-id=0,bmi-board-id=17' BoardLength[1]: 12064 BoardCRC32[1]: ccfed209 BoardMD5[1]: dbf42e5d3cf1680ab1d718354d493214 BoardNames[2]: 'bus=pci,bmi-chip-id=0,bmi-board-id=18' BoardLength[2]: 12064 BoardCRC32[2]: a7f0e9d9 BoardMD5[2]: ec1ff2be1b61ae53d8752fe6b1b0fa2e BoardNames[3]: 'bus=pci,bmi-chip-id=0,bmi-board-id=23' BoardLength[3]: 12064 BoardCRC32[3]: 795cc344 BoardMD5[3]: 1ae64807b2a91269878574aa1cabc185 BoardNames[4]: 'bus=pci,bmi-chip-id=0,bmi-board-id=24' BoardLength[4]: 12064 BoardCRC32[4]: 9ec997a9 BoardMD5[4]: f9828e262a6827c772f62ec0bc7306ae BoardNames[5]: 'bus=pci,bmi-chip-id=0,bmi-board-id=25' BoardLength[5]: 12064 BoardCRC32[5]: 04d9857f BoardMD5[5]: 37cc0eda80791408a9f2c436bf976a4a BoardNames[6]: 'bus=pci,bmi-chip-id=0,bmi-board-id=16,variant=OM-A62' BoardLength[6]: 12064 BoardCRC32[6]: bbfad0fc BoardMD5[6]: 6cb4b86098bf996215bb579e7c0cdb9d How do I create a board-2.bin from a Jason file to add the Asus variant? > 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. This did not make a difference. > 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. I have not tried this yet. I will update later today. Thanks On Tue, May 14, 2019 at 1:33 AM Sven Eckelmann <[email protected]> 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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
