QCA6174 on Asus Z170I Pro Gaming

Wed Jan 20 02:28:37 PST 2016

On 19 January 2016 at 19:26, Per Östlund <perost86 at gmail.com> wrote:
> After some more testing it seems that 5 GHz isn't working. iw shows that the
> card is capable of using the channel my router is set to (channel 36), and
> iw event says it's scanning the correct frequence. But it doesn't find my
> router, and none of the other handful of APs using 5 GHz in range. Any clues
> on what the issue might be?

Hmm.. My suspicion is you might still be running off of wrong board
data. Can you double check? Perhaps there's a narrower matching rule
somewhere else which picks a different eeprom file.

Otherwise maybe it's somehow related to regulatory. Kernel logs may
contain some useful info.

You might want to enable debugging by either:
 * load ath10k_core with param debug_mask=0xffffff3f
 * echo 0xffffff3f > /sys/module/ath10k_core/parameters/debug_mask

You can try looking at the logs and look for scanning events and mgmt
rx events while scan is running. From the prints you should be able to
tell when certain frequencies are visited and if any frames are
reports are interleaved between visits. Perhaps FW reports them but
driver fails to deliver them up the stack for some reason..

Michał

>
> /Per
>
>
> On 2016-01-19 09:59, Per Östlund wrote:
>>
>> I could've sworn that the driver failed completely when it couldn't find
>> firmware-5.bin, but when cold booting the machine I now see that it actually
>> falls back to another firmware as you say. Anyway, looking at the ini file
>> as you suggested told me that eeprom_ar6320_3p0_NFA344a.bin was the correct
>> file. Replacing /lib/firmware/ath10k/QCA6174/hw3.0/board.bin with it made
>> the wifi spring to life, and I get usable performance (~80 Mbit/s). Thanks a
>> lot for the help!
>>
>> /Per
>>
>> On 2016-01-19 09:39, Michal Kazior wrote:
>>>
>>> On 18 January 2016 at 19:39, Per Östlund <perost86 at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I'm trying to get the wifi on my Asus Z170I Pro Gaming to work, but
>>>> haven't
>>>> had any luck so far.
>>>>
>>>> lspci says:
>>>> Network controller [0280]: Qualcomm Atheros QCA6174 802.11ac Wireless
>>>> Network Adapter [168c:003e] (rev 32)
>>>> Subsystem: ASUSTeK Computer Inc. Device [1043:86cd]
>>>>
>>>> I'm using the 4.4 kernel, on Arch Linux 64-bit (linux-4.4-3 package from
>>>> testing repo). Out of the box ath10k doesn't work at all, complaining
>>>> that
>>>> it can't find firmware-5.bin. Copying firmware-4.bin to firmware-5.bin
>>>> gets
>>>> me further, with dmesg saying this:
>>>
>>> Please, don't do that. It's pointless.
>>>
>>> ath10k has a fallback system. If it doesn't find firmware-5.bin it'll
>>> look for -4, -3, -2 as well. The message you see in the kernel log is
>>> just a side effect of how to kernel API works at this time.
>>>
>>>
>>>> [ 4237.917517] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>>>> irq_mode 0
>>>> reset_mode 0
>>>> [ 4238.139726] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>>> [ 4238.139742] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>> ath10k/QCA6174/hw3.0/firmware-5.bin failed with error -2
>>>> [ 4238.139745] ath10k_pci 0000:05:00.0: could not fetch firmware file
>>>> 'ath10k/QCA6174/hw3.0/firmware-5.bin': -2
>>>> [ 4238.202052] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>> ath10k/QCA6174/hw3.0/board-2.bin failed with error -2
>>>> [ 4240.318396] ath10k_pci 0000:05:00.0: qca6174 hw3.2 (0x05030000,
>>>> 0x00340aff sub 1043:86cd) fw WLAN.RM.2.0-00180-QCARMSWPZ-1 fwapi 4 bdapi
>>>> 1
>>>> htt-ver 3.26 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
>>>> features
>>>> wowlan,ignore-otp,no-4addr-pad
>>>
>>> You have the hw3.2. It is sensitive to board data files (board.bin /
>>> board-2.bin).
>>>
>>>
>>>> [ 4240.318399] ath10k_pci 0000:05:00.0: debug 0 debugfs 1 tracing 0 dfs
>>>> 0
>>>> testmode 0
>>>> [ 4243.317764] ath10k_pci 0000:05:00.0: could not suspend target (-11)
>>>> [ 4243.378790] ath: EEPROM regdomain: 0x6c
>>>> [ 4243.378794] ath: EEPROM indicates we should expect a direct regpair
>>>> map
>>>> [ 4243.378796] ath: Country alpha2 being used: 00
>>>> [ 4243.378797] ath: Regpair used: 0x6c
>>>> [ 4243.380678] ath10k_pci 0000:05:00.0 wlp5s0: renamed from wlan0
>>>
>>> Looks okay.
>>>
>>>
>>>> [ 4365.040838] ath10k_pci 0000:05:00.0: pci irq msi interrupts 1
>>>> irq_mode 0
>>>> reset_mode 0
>>>> [ 4365.264862] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>> ath10k/cal-pci-0000:05:00.0.bin failed with error -2
>>>> [ 4365.327022] ath10k_pci 0000:05:00.0: Direct firmware load for
>>>> ath10k/QCA6174/hw3.0/board-2.bin failed with error -2
>>>
>>> Looks like you reloaded the driver and nothing actually happened in
>>> between. Perhaps your syslog (or journald I suppose) filtered some
>>> messages?
>>>
>>>
>>>> The interface can't be brought up though:
>>>> # ip link set wlp5s0 up
>>>> RTNETLINK answers: Resource temporarily unavailable
>>>
>>> The kernel log doesn't really match what you're doing here.
>>>
>>> The error is EAGAIN (11). This is very likely due to a FW timeout
>>> which would be seen in the kernel log.
>>>
>>> The most common reason FW times out on QCA6174 hw3.2 is incorrect
>>> board file. The reason is the default board.bin doesn't work with
>>> hw3.2 and the board-2.bin doesn't include the proper mappings either
>>> yet (see the other thread in the archives - there's a lot of similar
>>> complaints).
>>>
>>>
>>>> I've tried various other firmwares (kvalo's, and other ones in the pull
>>>> requests for his repo), but they either give me a "found invalid board
>>>> magic" error or doesn't work any better than the one I got with the
>>>
>>> That's what you get when you rename files however you like. You
>>> probably wanted to use board.bin as board-2.bin file, right? This
>>> won't work.
>>>
>>>
>>>> linux-firmware package. I tried extracting the firmware myself from the
>>>> Windows drivers from Asus, which had both qca61x4_1_1_2.bin and
>>>> qca61x4_2_2.bin, using the instructions from [1]. The first failed with
>>>> "failed to receive control response completion, polling..", the second
>>>> worked as well as the one in linux-firmware.
>>>
>>> You encoded the binary incorrect probably.
>>>
>>> The problem you're facing isn't firmware problem per se. It is board
>>> file problem most likely.
>>>
>>>
>>>> The Asus driver also comes with a lot of eeprom-files, and I didn't know
>>>> which one to use. So I wrote a script that copied each one to
>>>> /lib/firmware/ath10k/QCA6174/hw3.0/board-2.bin and reloaded the driver,
>>>> but
>>>> all of them failed with the invalid board magic error.
>>>
>>> Yada yada. board-2.bin is TLV formatted. The eeprom files are
>>> basically board.bin files (the API1 board files). You need to remove
>>> board-2.bin and use the eeprom files from windows driver as board.bin.
>>>
>>> You can actually figure out which one to use if you look at the .inf
>>> file in the windows driver. There's a section containing mappings for
>>> vendor/product ids (including subsystem ids, which is 1043:86cd in
>>> your case which can be seen in both ath10k print and lspci).
>>>
>>>
>>> Michał
>>
>>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k