Open Alkorin opened 10 years ago
The bt doesn't (yet?) work on this chip, super annoying. Discussion here https://github.com/lwfinger/rtl8723be/issues/2
This post is even more annoying!! At a minimum, you absolutely MUST be using "new" branch of the git repo at http://github.com/lwfinger/rtl8723au_bt.git. I'm not sure if it works, but it is the only place where the proper firmware and configuration files exist. Your log shows that you were not using that repo.
Thanks for your answer lwfinger.
I already use the "new" branch of the git. I just updated the repo and here is the log : http://pastebin.com/WFk2XW7V
If I did something wrong, please let me know.
Have you checked the output of dmesg?
Here it is : http://pastebin.com/KhZfhLLH
I do not see any errors in that output. I have no idea why it is not working.
I'll try to install another OS (windows 8?) to see if hardware works :/
I'm sorry to be annoying, but I did try the exact setup as per https://github.com/lwfinger/rtl8723be/issues/2 and it did not work for me. I will try again and produce some debug info.
Did your hardware already worked with another OS ?
yep mine works on win 8.1
Same hardware [gigabyte-brix-celeron-n2807 with an AzureWave AW-NB159H mini-pci card]
NO BT ! (but the wifi works)
The BT driver in kernel 4.0-rc2, or the kernel branch of http://github.com/lwfinger/rtl8723au_bt.git should work with RTL8723BE. At least they work with my hardware.
O.K. will test it. Thank you @lwfinger !
Will test it too
I've quickly compiled 4.0.0-rc2 to make a test, didn't worked, will try your branch
Let's try :
# git clone https://github.com/lwfinger/rtl8723au_bt.git
# cd rtl8723au_bt/
# git checkout kernel
# git branch
* kernel
master
# make
make -C /lib/modules/3.16.0-4-amd64/build M=/root/git/rtl8723au_bt modules
make[1]: Entering directory '/usr/src/linux-headers-3.16.0-4-amd64'
Makefile:10: *** mixed implicit and normal rules: deprecated syntax
make[1]: Entering directory `/usr/src/linux-headers-3.16.0-4-amd64'
CC [M] /root/git/rtl8723au_bt/btusb.o
Building modules, stage 2.
MODPOST 1 modules
CC /root/git/rtl8723au_bt/btusb.mod.o
LD [M] /root/git/rtl8723au_bt/btusb.ko
make[1]: Leaving directory '/usr/src/linux-headers-3.16.0-4-amd64'
# make install
depmod -a /lib/modules/3.16.0-4-amd64
installed revised btusb
# modprobe -rv btusb
rmmod btusb
# hciconfig
# modprobe -v btusb
insmod /lib/modules/3.16.0-4-amd64/kernel/drivers/bluetooth/btusb.ko
# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 54:27:1E:C3:F2:4A ACL MTU: 820:8 SCO MTU: 255:16
UP RUNNING PSCAN
RX bytes:1263 acl:0 sco:0 events:129 errors:0
TX bytes:23804 acl:0 sco:0 commands:129 errors:0
# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
2: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
# hcitool scan
Scanning ...
Nothing discovered :/
Extract of dmesg:
[ 967.497554] usbcore: deregistering interface driver btusb
[ 967.497689] Bluetooth: hci0 urb ffff8800b7bb9100 failed to resubmit (2)
[ 967.497793] Bluetooth: hci0 urb ffff8800b7bb9040 failed to resubmit (2)
[ 988.031694] usbcore: registered new interface driver btusb
[ 988.036472] Bluetooth: hci0: hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723
[ 988.036691] usb 1-2: firmware: direct-loading firmware rtl_bt/rtl8723b_fw.bin
If you have any idea :)
I really will have to boot windows one day to be sure hardware is working correctly :s
I did a dump with tcpdump of USB traffic, looks like the device says : nothing found :/ http://demo.ovh.eu/download/ae5a1eeb1c428fbfabc1f7a7268ced96/bt.pcap
I've digged a little bit, avec loading firmware, hci0 becomes :
Bluetooth: hci0: hci_ver=06 hci_rev=0e2f lmp_ver=06 lmp_subver=9f73
But here (https://github.com/lwfinger/rtl8723au_bt/commit/727f0b01e50ffb48fc0bac6ce27a6718697335a3) you say:
the version read by HCI_OP_READ_LOCAL_VERSION changes from 0x8723 to 0x3083.
For unknown reasons, the lmp_subver changes after the firmware loads. I have no way of predicting what the new version will be. It seems to be different for everyone.
Hi, same here. I've tested with same negative results... Nothing discovered... That's really annoying because more and more people are using the same chip. Cheers,
Please post your lsusb output. There is a possibility that your chip has a strange ID and it is not recognized. In addition, I need your dmesg output.
All I can say is that using kernel 4.0-rc2 with the firmware installed, it just works.
I'm installing Win8 tu check hardware, will reboot later
Hum, it's not a USB dongle, it's integrated on a gigabyte-brix-celeron-n2807 with an AzureWave AW-NB159H mini-pci card. [IEEE 802.11b/g/n RTL8723BE combo module.]
So here is the output of lspci ~$ lspci 00:00.0 Host bridge: Intel Corporation ValleyView SSA-CUnit (rev 0e) 00:02.0 VGA compatible controller: Intel Corporation ValleyView Gen7 (rev 0e) 00:13.0 SATA controller: Intel Corporation ValleyView 6-Port SATA AHCI Controller (rev 0e) 00:14.0 USB controller: Intel Corporation ValleyView USB xHCI Host Controller (rev 0e) 00:1a.0 Encryption controller: Intel Corporation ValleyView SEC (rev 0e) 00:1b.0 Audio device: Intel Corporation ValleyView High Definition Audio Controller (rev 0e) 00:1c.0 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1c.1 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1c.2 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1c.3 PCI bridge: Intel Corporation ValleyView PCI Express Root Port (rev 0e) 00:1f.0 ISA bridge: Intel Corporation ValleyView Power Control Unit (rev 0e) 00:1f.3 SMBus: Intel Corporation ValleyView SMBus Controller (rev 0e) 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
This Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter is a combo Wifi/BT. The wifi works well but not the BT.
@Akhenaton I thing @lwfinger knows it, look here https://github.com/lwfinger/rtl8723au_bt/commit/727f0b01e50ffb48fc0bac6ce27a6718697335a3
It should be the same hardware, so it should work ...
This enables bluetooth support in the Gigabyte Brix GB-BXBT-2807 which has this RTL8723BE USB device
Yes, "should" work.... I'm going to try to de/reinstall... Thanks for the help. (I saw other threads here : https://github.com/lwfinger/rtlwifi_new/issues/18 and here https://bbs.archlinux.org/viewtopic.php?id=194053)
On my side, Win8.1 installed, drivers from http://www.gigabyte.fr/products/product-page.aspx?pid=5038#dl installed, BT works.
Now rebooting linux
Hey, it works !
4.0.0-rc2 => ok git + 3.16.7-ckt4-3 from debian => ko
Dunno if installing Windows did something :s
@Akhenaton: The PCI device for the RTL8723BE includes a USB device that implements the BT device. I really meant it when I asked for the output of lsusb. Of course, if you really do not want help, that would ease my load a lot.
@Alkorin: What git branch are you using with 3.16.7? In any case, you should use 4.0-rc2.
I'm truly sorry, i had to switch to others duties for a moment and forgot the lsusb.... very sorry.
~$ lsusb Bus 002 Device 002: ID 18a5:0408 Verbatim, Ltd Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth (mouse) Bus 001 Device 003: ID 03f0:0024 Hewlett-Packard KU-0316 Keyboard Bus 001 Device 002: ID 13d3:3410 IMC Networks Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I tried to compile the rtl8723au_bt but got some errors.... I have a 3.13.0-46-generic #77-Ubuntu SMP Mon Mar 2 18:23:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux kernel
And..... be sure i do really want to help. But my knowledge is quite limited... Again sorry.
Ok, i did a cold reboot => don't work anymore with 4.0-rc2...
I've to reboot on 3.16.7 with git branch "kernel" first and then reboot on 4.0-rc2 to make scan working
I did some tests and saw this (hciconfig -a)
After cold reboot on 4.0-rc2 I have:
LMP ... Subversion: 0x8723
=> scanning doesn't work
After hot reboot on 3.16.7 with git branch "kernel" I have:
LMP ... Subversion: 0x9f73
=> scanning doesn't work
After hot reboot on 4.0-rc2 I have:
LMP ... Subversion: 0x9f73
=> scanning works !
I'll check which firmware is loaded with 4.0-rc2 ...
@lwfinger are you sure Bluetooth: btusb: Add Realtek 8723A/8723B/8761A/8821A support
is merged in 4.0.0-rc2 ?
# md5sum linux-4.0-rc2/drivers/bluetooth/btusb.c
e1ef7a8382ee485dc7e6f02bec3ca5f8 linux-4.0-rc2/drivers/bluetooth/btusb.c
# git show 1f2bc8d:btusb.c | md5sum
e1ef7a8382ee485dc7e6f02bec3ca5f8 -
# git show 1f2bc8d
commit 1f2bc8dae35e07d4b09cd15901f786d5a747aafc
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Tue Feb 10 19:29:39 2015 -0600
btusb: Add unpatched 3.19 kernel version to kernel branch
Looks like btusb.c from 4.0.0-rc2 is the same as the file in your repo before your patches ?
Last test : 3.19-1 kernel with firmware previously loaded by your patched btusb.c => it works
Yes, 4.0-rc2 does not have the patches. I misread the commit log. Apparently the revisions for the Realtek devices will not appear until kernel 4.1. :(
It appears that any unpatched recent kernel will work on warm reboot because the firmware has already been loaded. For cold reboot, the patches are needed, otherwise the firmware is not loaded.
@Akhenaton: If you do not post the errors you are getting when you try to build, how can I suggest fixes? Why are you so secretive?
Unsure about 4.1 I just tested rc and fw loading code is only in bluez next staging area ...
Where to track upstreaming effort of fw files ? thoses ones :
https://github.com/dsd/linux-firmware/commit/d90ad18a2f935ad6663d973554961981f071a63e
I think the new driver will first appear in 4.2-rc1. The kernel branch of the rtl8723au_bt repo has this code. I will confirm with Daniel Drake that the firmware has been submitted to the linux-firmware repo.
FYI, code landed into linux-next , next is to get rtl_usb/* firwmares from @dsd
4.2 should be fine for those 3 changes (later one is for lenovo/g40-30 )
I'll track status on my note page :
@rzr FYI this is what we ship to clients with Kernel 3.13( Ubuntu 14.04.0 ) based on the 'new' branch :
I have similar hardware, and I'm on a variant of the Lenovo Yoga 2 13. The kernel module in use in rtl8723be. After going through this bug report, I'm happy that I need to wait for the next (4.2) kernel.
Currently on 4.1, the fw is non-existent. At least that's what the driver says.
[17756.372184] Bluetooth: hci0: rtl: examining hci_ver=06 hci_rev=000b lmp_ver=06 lmp_subver=8723 [17756.372191] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin [17756.372230] usb 1-7: Direct firmware load for rtl_bt/rtl8723b_fw.bin failed with error -2 [17756.372234] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_fw.bin
BTW, I see the referenced src code in linux-next explicitly prints "rtl_bt/rtl8723b_fw.bin". Where as, right now, my /lib/firmware has no such folder. I'm assuming the kernel (installer scripts) takes care of installing the fw files in the exact location.
The firmware has been submitted to linux-firmware and accepted on May 8, 2015. Getting the latest firmware in a system is not the responsibility of the kernel. It just loads the file if it exists. The file is part of user space, thus it is the distro's responsibility to prepare a package to install it. Either complain to your distro, or run the commands
git clone git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git sudo cp -a linux-firmware/rtl_bt/ /lib/firmware/.
I've a gigabyte-brix-celeron-n2807 with an AzureWave AW-NB159H mini-pci card. It's an IEEE 802.11b/g/n RTL8723BE combo module.
With a 3.16 debian kernel wifi works out of the box. The BT is recognized too, but the computer can't be discovered by a phone and the hcitool scan command doesn't return any devices.
I tried your module too, it looks the same :
lsmod | grep bluet
bluetooth 357417 21 bnep,rtk_btusb rfkill 18867 4 cfg80211,bluetooth
dmesg
[ 778.707088] usbcore: registered new interface driver btusb [ 778.710899] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x8723 [ 778.710915] rtk_btusb: check_fw_version : read_ver_rsp->status = 0x0 [ 778.710924] rtk_btusb: check_fw_version : read_ver_rsp->hci_ver = 0x6 [ 778.710932] rtk_btusb: check_fw_version : read_ver_rsp->hci_rev = 0xb [ 778.710940] rtk_btusb: check_fw_version : read_ver_rsp->lmp_ver = 0x6 [ 778.710948] rtk_btusb: check_fw_version : read_ver_rsp->manufacturer = 0x5d [ 778.710957] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x8723 [ 778.710965] rtk_btusb: check_fw_version : patch_entry->lmp_subver = 0x8723 [ 778.712728] rtk_btusb: rtk_get_eversion : eversion->status = 0x0, eversion->version = 0x1 [ 778.712744] rtk_btusb: load_firmware start ,lmp_version = 0x8723 [ 778.712888] usb 1-2: firmware: direct-loading firmware rtl8723b_config.bin [ 778.713060] usb 1-2: firmware: direct-loading firmware rtl8723b_fw.bin [ 778.713133] rtk_btusb: This is not 8723a, use new patch style! [ 778.713145] rtk_btusb: gEVersion=1 [ 778.713154] rtk_btusb: opcode = 0x0 [ 778.713162] rtk_btusb: length = 0x1 [ 778.713169] rtk_btusb: data = 0x1 [ 778.713178] rtk_btusb: lmp_version is 8723, project_id is 8723, match! [ 778.713187] rtk_btusb: fm_version = 0x1e2f3083 [ 778.713195] rtk_btusb: number_of_total_patch = 2 [ 778.713203] rtk_btusb: chipID = 2 [ 778.713210] rtk_btusb: patch_length = 0x4ba8 [ 778.713218] rtk_btusb: start_offset = 0x4c80 [ 778.713225] rtk_btusb: buf_len = 0x4be3 [ 778.713267] rtk_btusb: Fw: exists, config file: exists [ 778.713275] rtk_btusb: load_firmware done [ 778.713297] rtk_btusb: patch_entry->fw_len = 19427 [ 778.713308] rtk_btusb: download fw (0)/(78) ... [ 778.797043] rtk_btusb: download fw (77)/(78) [ 779.143178] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x3083 [ 779.143195] rtk_btusb: check_fw_version : read_ver_rsp->status = 0x0 [ 779.143204] rtk_btusb: check_fw_version : read_ver_rsp->hci_ver = 0x6 [ 779.143213] rtk_btusb: check_fw_version : read_ver_rsp->hci_rev = 0x1e2f [ 779.143221] rtk_btusb: check_fw_version : read_ver_rsp->lmp_ver = 0x6 [ 779.143232] rtk_btusb: check_fw_version : read_ver_rsp->manufacturer = 0x5d [ 779.143236] rtk_btusb: check_fw_version : read_ver_rsp->lmp_subver = 0x3083 [ 779.143240] rtk_btusb: check_fw_version : patch_entry->lmp_subver = 0x8723 [ 779.143245] rtk_btusb: patch download success!
hciconfig -a hci0
hci0: Type: BR/EDR Bus: USB BD Address: 54:27:1E:C3:F2:4A ACL MTU: 820:8 SCO MTU: 255:16 UP RUNNING PSCAN ISCAN RX bytes:1768 acl:0 sco:0 events:128 errors:0 TX bytes:20755 acl:0 sco:0 commands:127 errors:0 Features: 0xff 0xff 0xff 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'brix' Class: 0x00010c Service Classes: Unspecified Device Class: Computer, Laptop HCI Version: 4.0 (0x6) Revision: 0x1e2f LMP Version: 4.0 (0x6) Subversion: 0x3083 Manufacturer: Realtek Semiconductor Corporation (93)
hcitool scan
Scanning ...
Any idea ?