Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Apr 2019 11:44:25 -0700
From:      Adrian Chadd <adrian.chadd@gmail.com>
To:        Alexey Dokuchaev <danfe@freebsd.org>
Cc:        "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org>
Subject:   Re: Atheros AR5B22 WLAN+Bluetooth support on FreeBSD
Message-ID:  <CAJ-VmomspHeZBKnZ2Y1uM3N3M1Mbx8T5GDrEZ0mNz2uoLw4FxA@mail.gmail.com>
In-Reply-To: <20190413142006.GA59512@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> <20190413142006.GA59512@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hm, is this a problem with our usb3 stack itself?

If you send me a pull request against ath3k I'll merge it into my git tree
just for completeness.

Maybe we need to loop in hps@ with a bunch of usbdump output to see what
the transactions look like...



-adrian


On Sat, 13 Apr 2019 at 07:21, Alexey Dokuchaev <danfe@freebsd.org> wrote:

> 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
> _______________________________________________
> freebsd-wireless@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org
> "
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomspHeZBKnZ2Y1uM3N3M1Mbx8T5GDrEZ0mNz2uoLw4FxA>