Re: Support for QCA9377

[Jay Foster <jayf0ster@roadrunner.com>]

On 5/16/2018 11:27 AM, Kalle Valo wrote:
> + linux-wireless
>
> Jay Foster <jayf0ster@roadrunner.com> writes:
>
>> On 5/15/2018 9:56 PM, Kalle Valo wrote:
>>> Jay Foster <jayf0ster@roadrunner.com> writes:
>>>
>>>> I too have been, off and on, looking for an ath10k driver solution for
>>>> a SparkLAN WUBQ-159ACN USB Wi-Fi adapter, so I have been keeping an
>>>> eye on this mailing list.  I just tried the latest
>>>> ath10k-pending-sdio-usb branch (ath10k-pending-sdio-usb-201804210910
>>>> tag), since I could see that support for the SparkLAN USB 0CF3:9378
>>>> device was just added.  The driver refers to this as the SparkLAN
>>>> WPEQ-160ACN device, but it has the same USB vendor/product ID as my
>>>> WUBQ-159ACN.  They both use the QCA9377 chip.
>>>>
>>>> I got a driver to build with the 4.9 kernel and when it boots, it
>>>> recognizes my Wi-Fi adapter.  Now, I am trying to sort out what to do
>>>> about firmware.  I downloaded the board-2.bin, board.bin,
>>>> firmware-5.bin files from
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0.
>>>> I used the ath10k-fwencoder application from the qca-swiss-army-knife
>>>> tools to also build a firmware file, but I am not clear on what files
>>>> I should be using.  SparkLAN provided, with the qcacld-2.0 wlan
>>>> driver, the following files:
>>>> athsetup.bin, athwlan.bin, cfg.dat, fakeboar.bin, otp.bin, and
>>>> qcom_cfg.ini.  I used the command:
>>>>
>>>> qca-swiss-army-knife/tools/scripts/ath10k/ath10k-fwencoder --create
>>>> --otp ../../../otp.bin --firmware ../../../athwlan.bin
>>>> --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=6
>>>> --features=ignore-otp-result
>>>>
>>>> to create my firmware-usb-6.bin and used the fakeboar.bin for my
>>>> board-usb.bin files.  However, when the driver loads, it is looking
>>>> for a file called ath10k/cal-usb-1-1.2.bin.  Where do I get that
>>>> file?
>>> You can ignore that warning. cal-*.bin are optional files containing the
>>> calibration data, in case you don't have the calibration data in OTP.
>>> But my guess is that in your device you have the calibration data in OTP
>>> so you don't need cal-*.bin.
>>>
>>> Hopefully in 4.18 that warning will be away and users won't get confused anymore.
>>>
>>>>     I tried using the athsetup.bin file for this, but I do not
>>>> think that works.  The driver reports:
>>>>
>>>> /lib/firmware/ath10k/QCA9377/hw1.0# usb 1-1.2: qca9377 hw1.1 SparkLAN
>>>> WPEQ-160ACN target 0x05020001 chip_id 0x00000000 sub 0000:0000
>>>> usb 1-1.2: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 1
>>>> usb 1-1.2: firmware ver  api 6 features ignore-otp crc32 e8985f67
>>>> usb 1-1.2: found invalid board magic
>>>> usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
>>>> usb 1-1.2: invalid hw_params.n_cipher_suites 0
>>>>
>>>> What does invalid board magic mean?
>>> This log means that ath10k first tried to load board-2.bin but it was
>>> corrupted for some reason. Then it found and used board.bin instead.
>> It seems odd that the board-2.bin file I downloaded from
>> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath10k/QCA9377/hw1.0
>> is somehow corrupted.  Does the message mean that the board-2.bin file
>> itself is bad or that it is not appropriate/useful for my particular
>> Wi-Fi device?
> I meant that the file itself is bad, but of course there could be a bug
> lurking somewhere as well. The md5sum should be:
>
> 0234621d41643e46243438b1661c2407  ath10k/QCA9377/hw1.0/board-2.bin
>
> But this does not make any difference for you as the board-2.bin file
> does not have any board files for usb devices yet.
This was my bad.  My file was corrupted.  I fixed it (matches the md5sum 
above), but as you noted, it is of no help for USB devices.

usb 1-1.2: failed to fetch board data for 
bus=usb,vendor=0cf3,device=9378,subsystem-vendor=0000,subsystem-device=0000 
from ath10k/QCA9377/hw1.0/board-2.bin

The driver then goes on and reads from board-usb.bin:
usb 1-1.2: board_file api 1 bmi_id N/A crc32 58a139e9
usb 1-1.2: invalid hw_params.n_cipher_suites 0

>
>> When you say that the driver then used board.bin instead, I think in
>> my case this is board-usb.bin (the same as my fakeboar.bin file from
>> SparkLAN), since my device is a USB device.  I am just trying to be
>> clear on my understanding.
> A good point and you are correct. I forgot that Erik's patches are still
> using that special board-usb.bin. That should be removed before the
> patches get applied upstream as we should get all the board files to
> board-2.bin anyway. (board.bin is just for testing purposes)
>
>>>> The Wi-Fi USB adapter may be installed in any number of different USB
>>>> locations, so why is the USB location (1-1.2) part of one of the
>>>> filenames?
>>> Because there needs to be some way to identify multiple devices on the
>>> same host. But cal-*.bin is mainly meant for AP devices where the
>>> devices have a fixed slot in the PCI bus and the calibration data is
>>> stored in host's filesystem (check openwrt to see how it's used).
>>>
>> I did manage to get a successful Wi-Fi STA mode connection with this
>> driver.  One issue that I don't understand is when the driver attempts
>> to load a FW file that is not present, it fails with error -2 and then
>> reports, "Falling back to user helper".  However, this 'user helper'
>> does not exist/work either, but the driver waits quite a while waiting
>> for it (about half a minute or so).  This causes a delay loading the
>> driver (about half a minute for each missing file).  So, even though
>> the cal files are optional, if they are not there, it significantly
>> delays loading of the driver.  I need to eliminate this delay.  For
>> now, I patched the driver to not attempt to load the
>> pre-cal-usb-<bus>.bin or the cal-usb-<bus>.bin files (that do not
>> exist for my adapter), but there must be a better way to avoid this
>> delay.
> Yeah, that delay is a common problem and not ath10k related. IIRC
> there's a Kconfig option which you can disable to avoid the delay, maybe
> it was CONFIG_FW_LOADER_USER_HELPER_FALLBACK? Not sure though, Google
> should be able to help with that.
>
Thanks.  Selecting CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n did the trick.

Other issues that I have observed (probably FW related):
1) In STA mode, I observe several messages from the driver "received tx 
completion for invalid msdu_id: 0".  A Google search led me to 
https://github.com/erstrom/linux-ath/issues/1, but I did not find a 
resolution.

2) If I reboot, it appears that the USB Wi-Fi adapter is left in a 
broken state, so the device fails to enumerate and the driver won't 
load.  A power cycle is required.

3) AP mode does not work.  The driver reports:
usb 1-1.2: Failed to submit usb control message: -110
usb 1-1.2: unable to send the bmi data to the device: -110
usb 1-1.2: unable to write to the device (-110)
usb 1-1.2: settings HTC version failed
usb 1-1.2: Could not init core: -22
At this point, the device is stuffed again, and requires a power cycle.

Jay



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k