QCA6174 on Asus Z170I Pro Gaming

Tue Jan 19 10:26:24 PST 2016

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?

/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ł
>