Date: Sat, 13 Apr 2019 14:20:06 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Matthias Apitz <guru@unixarea.de>, "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD Message-ID: <20190413142006.GA59512@FreeBSD.org> In-Reply-To: <20190412171218.GA16463@FreeBSD.org> References: <20190409160344.GA83271@FreeBSD.org> <20190410152250.GA37191@FreeBSD.org> <20190411092758.GA6899@FreeBSD.org> <20190411104647.GA3864@c720-r342378> <20190411125242.GA64046@FreeBSD.org> <20190411131328.GA4909@c720-r342378> <20190411131859.GA17806@FreeBSD.org> <CAJ-VmokDt0Ss9awPwAf-pk8=s6XqGJyBbfYTAg1BHrVM06HeGQ@mail.gmail.com> <20190411142350.GA71446@FreeBSD.org> <20190412171218.GA16463@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 12, 2019 at 05:12:18PM +0000, Alexey Dokuchaev wrote:
> I've then rebooted back into FreeBSD. Apparently, this AR3012 hardware
> is very fragile, it can be easily left in confused state and won't accept
> further commands, "usbconfig reset" does not help. To avoid this, it is
> better run ./ath3kfw as root, after powercycling machine (to reset the
> card). This got me further:
>
> ath3kfw: opening dev 2.2
> main: state=0x0e
> ROM version: 285343744, build version: 155, ram version: 155, ref clock=1
> ath3k_init_firmware: loading ath3k-1.fw
> ath3k_load_fwfile: file=/home/danfe/ath3k/share/firmware/ath3k/ath3k-1.fw,
> size=246804
> ath3k_load_fwfile: transferring 20 bytes, offset 4096
Looks like there is a bug with the logging, consider this pseudo-patch:
@@ ...
ath3k_debug("%s: transferring %d bytes, offset %d\n",
__func__,
- sent,
- size);
+ size, sent);
> ...
> ath3k_load_fwfile: transferring 65556 bytes, offset 4096
> LIBUSB_FUNCTION: libusb_bulk_transfer enter
> LIBUSB_FUNCTION: libusb_submit_transfer enter
> LIBUSB_FUNCTION: libusb_submit_transfer leave 0
> LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
> LIBUSB_FUNCTION: libusb10_handle_events_sub enter
> LIBUSB_TRANSFER: sync I/O done
> LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
> LIBUSB_FUNCTION: libusb_bulk_transfer leave
> Can't load firmware: err=Timeout, size=4096
> ath3k_load_fwfile: transferring 65556 bytes, offset 4096
I've found seemingly related bug report about Atheros BT devices (ath3k)
failing to work on USB 3.0 buses, while working well on USB 2.0:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1400215
In 2015, a work-around for this problem was committed* to Linux kernel:
author Adam Lee <adam.lee@canonical.com> 2015-01-28
committer Marcel Holtmann <marcel@holtmann.org> 2015-01-29
commit c561a5753dd631920c4459a067d22679b3d110d6
Bluetooth: ath3k: workaround the compatibility issue with xHCI controller
ath3k devices fail to load firmwares on xHCI buses, but work well on
EHCI, this might be a compatibility issue between xHCI and ath3k chips.
As my testing result, those chips will work on xHCI buses again with
this patch.
This workaround is from Qualcomm, they also did some workarounds in
Windows driver.
I've patched ath3kfw tool in a similar way like this:
+#define TIMEGAP_USEC_MIN 50
+#define TIMEGAP_USEC_MAX 100
+
+static inline void
+usleep_range(unsigned long min, unsigned long max)
+{
+ usleep(min); // or usleep(max);
+}
...
while (count) {
+ /* workaround the compatibility issue with xHCI controller */
+ usleep_range(TIMEGAP_USEC_MIN, TIMEGAP_USEC_MAX);
Unfortunately, this hack didn't help, neither with usleep(min) nor with
usleep(max). Error message is the same "Can't load firmware: err=Timeout,
size=4096".
I will try to find a USB 2.0-only laptop which supports mini-PCIe cards
to get more data points, but not sure if I can find one easily. It would
be nice if someone who has pre-xHCI hardware could conduct this test.
./danfe
*) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/ath3k.c?id=c561a5753dd631920c4459a067d22679b3d110d6
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190413142006.GA59512>