On 5/16/2018 11:27 AM, Kalle Valo wrote:
+ linux-wireless
Jay Foster <jayf0s...@roadrunner.com> writes:
On 5/15/2018 9:56 PM, Kalle Valo wrote:
Jay Foster <jayf0s...@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
