TonyMac32 Posted June 25, 2017 Posted June 25, 2017 Update May-15-2018: pushed today, Bluetooth patches to support bt in default and next kernels from boot, no user intervention ( "It just works" ). Thank you again to @Myy and @Jyu Ho for their work. Spoiler Trying to get the Bluetooth working, I've had a few different issues, I've labelled them per kernel: Default: Running "hci_attach" locks up the board after config and loading firmware. UPDATE June-25-2017: Disabling DMA on uart0 resolved the issue as theorized below. UPDATE Feb-22-2018: Services added loading Bluetooth automatically on boot, takes reboot after firstrun. New image due out soon. Released and available. Anyone wanting to lend a hand there, it should only require some debugging of the hci_attach and possibly trying to use the one from the "factory" image. I saw a patch from Rockchip removing the DMA from the bluetooth UART, I will do the same and test (or anyone else can if they beat me to it). [Done] The source for the rtk_hciattach is here. Command (must be run at every boot) <--- in "Default" kernel (4.4), this is handled by systemd rtk_hciattach -n -s 115200 ttyS0 rtk_h5 Next/Dev: Some changes have been made to the device tree and kernel config (not yet submitted), however the rfkill system is not tied in, @Myy has done a lot of work on this, forward-porting the rockchip bt rfkill driver and digging into the source code, progress has been made, but the hci_attach tool still times out. I took the liberty of trying it manually, switching the GPIO's in userspace, and was able to get the initial communication necessary for the 3-wire handshake and the config to be downloaded to the BT, however it hangs at firmware (tried 2 different proposed firmwares without luck). It looks like the rfkill driver is still not properly controlling the GPIO's, as all I did was lift reset and wakeup on the device and was able to get communication to start. I will update the dev kernel for anyone interested in trying it out there, I'll leave Next alone until some progress is made. That's all I have for now, I will update this OP as anything important changes/comes up.
TonyMac32 Posted June 26, 2017 Author Posted June 26, 2017 Default kernel can now operate the bluetooth radio with the DMA disabled on UART0. Successfully connected to a bluetooth speaker and played music (it was connected as a headset, but I was more worried about it working at all). Will update patches presently.
TonyMac32 Posted June 27, 2017 Author Posted June 27, 2017 Was messing with the dev kernel, decided to just pop the unchanged rfkill driver from Rockchip in there to see if it would work. Well, it didn't (the silence of your surprise is deafening). It did, however, do something, which is more than can be said for any other option other than my messy userspace GPIO hackery: Same results on dmesg as we were getting with @Myy's code: root@tinkerboard:~/rtk_hciattach# dmesg | grep "BT_RFKILL" [ 1.569459] [BT_RFKILL]: Enter rfkill_rk_init [ 1.570052] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: uart_rts_gpios = 139. [ 1.570098] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,reset_gpio = 149. [ 1.570167] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_gpio = 146. [ 1.570196] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_host_irq = 151. [ 1.570311] [BT_RFKILL]: Request irq for bt wakeup host [ 1.570344] [BT_RFKILL]: BT_WAKE_HOST IRQ fired [ 1.570395] [BT_RFKILL]: ** disable irq [ 1.570434] [BT_RFKILL]: bt_default device registered. So Device tree is parsed properly, gpio messages/etc all match the results when you get with the 4.4 kernel and the same driver EXCEPT we're lacking any log of UART0_RTS, that doesn't bode well. Try rtk_hciattach anyway: Spoiler Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H5 Realtek Bluetooth :Realtek hciattach version 3.1 Realtek Bluetooth :3-wire sync pattern resend : 1, len: 8 Realtek Bluetooth :Get SYNC Resp Pkt Realtek Bluetooth :Get SYNC pkt-active mode Realtek Bluetooth :3-wire config pattern resend : 1 , len: 10 Realtek Bluetooth :Get CONFG pkt-active mode Realtek Bluetooth :Get CONFG resp pkt-active mode Realtek Bluetooth :H5 init finished Realtek Bluetooth :RTK send HCI_VENDOR_READ_RTK_ROM_VERISION_Command Realtek Bluetooth :Received reliable seqno 0 from card Realtek Bluetooth :receive hci command complete event with command:1001 Realtek Bluetooth :Read Local Version Information with Status:0 Realtek Bluetooth :HCI Version 0x06 Realtek Bluetooth :HCI Revision 0x000b Realtek Bluetooth :LMP Subversion 0x8723 Realtek Bluetooth :RTK send HCI_VENDOR_READ_RTK_ROM_VERISION_Command Realtek Bluetooth :Received reliable seqno 1 from card Realtek Bluetooth :receive hci command complete event with command:fc6d Realtek Bluetooth :Read RTK rom version with Status:0 Realtek Bluetooth :LMP Subversion 0x8723 Realtek Bluetooth :EVersion 1 Realtek Bluetooth :IC: RTL8723BS Realtek Bluetooth :Firmware/config: rtl8723b_fw, rtl8723b_config Realtek Bluetooth :config offset(00f4),length(08) Realtek Bluetooth :config baud rate to :4928002, hwflowcontrol:5f, 1 Realtek Bluetooth :config offset(0027),length(01) Realtek Bluetooth :config offset(00fe),length(01) Realtek Bluetooth :config offset(01e3),length(01) Realtek Bluetooth :config offset(00db),length(01) Realtek Bluetooth :config offset(01df),length(01) Realtek Bluetooth :config offset(01e2),length(01) Realtek Bluetooth :config offset(0085),length(01) Realtek Bluetooth :config offset(0161),length(01) Realtek Bluetooth :Get config baud rate from config file:4928002 Realtek Bluetooth :Load FW OK Realtek Bluetooth :rtk_get_fw_project_id: opcode 0, len 1, data 1 Realtek Bluetooth :fw_ver 0x1e4cc3ff, patch_num 2 Realtek Bluetooth :chip id 0x0001 Realtek Bluetooth :chip id 0x0002 Realtek Bluetooth :patch length is 0x5dd4 Realtek Bluetooth :start offset is 0x5680 Realtek Bluetooth :Svn version: 14422 Realtek Bluetooth :Coexistence: BTCOEX_20150119-5844 Realtek Bluetooth :fw: exists, config file: exists Realtek Bluetooth :Total len 24088 for fw/config Realtek Bluetooth :baudrate in change speed command: 0x2 0x80 0x92 0x4 Realtek Bluetooth :Received reliable seqno 2 from card Realtek Bluetooth :receive hci command complete event with command:fc17 Realtek Bluetooth :Change BD Rate with status:0 Realtek Bluetooth :final_speed 1500000 Realtek Bluetooth :hw flow control enable Realtek Bluetooth :iEndIndex:95 iLastPacketLen:148 iAdditionpkt:5 It got pretty far, but then self destructed in spectacular fashion: Spoiler Realtek Bluetooth :Received reliable seqno 6 from card Realtek Bluetooth :rtk_hw_cfg.rx_index 99 Realtek Bluetooth :Send end packet 228 Realtek Bluetooth :Send FW last command Realtek Bluetooth :hci_download_patch tx_index:100 rx_index: 99 Realtek Bluetooth ERROR: Out-of-order packet arrived, got(6)expected(7) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(6)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: patch timerout, retry: Realtek Bluetooth :3-wire download patch re send:0 Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) Realtek Bluetooth ERROR: Out-of-order packet arrived, got(7)expected(0) So, something is quite obviously *Very* angry. It's important to note that in the Rockchip 4.4 kernel BT_RFKILL sends messages about uart0_rts. That did not happen here, the logic behind it doing that involves Spoiler static void rfkill_rk_pm_complete(struct device *dev) { struct rfkill_rk_data *rfkill = g_rfkill; struct rfkill_rk_irq* wake_host_irq; struct rfkill_rk_gpio* rts; struct pinctrl *pinctrl = rfkill->pdata->pinctrl; DBG("Enter %s\n",__FUNCTION__); if (!rfkill) return; wake_host_irq = &rfkill->pdata->wake_host_irq; rts = &rfkill->pdata->rts_gpio; if (gpio_is_valid(wake_host_irq->gpio.io)) { LOG("** disable irq\n"); disable_irq(wake_host_irq->irq); } if (pinctrl != NULL && gpio_is_valid(rts->io)) { DBG("Enable UART_RTS\n"); gpio_direction_output(rts->io, rts->enable); pinctrl_select_state(pinctrl, rts->default_state); } } It's evident it's failing the if() statements, I'm too tired to figure out why at the moment, Anyone else have experience with this sort of thing? TBH this looks like all they're using this for is to toggle the gpio, the rfkill driver has been modified so that it doesn't actually control power to anything. There is no question I prefer Myy's method, 1 file and hopefully magic happens, but I obviously haven't completely come to grips with how RK is doing this.
Myy Posted June 27, 2017 Posted June 27, 2017 The RFKill system, in this example, is detected and enabled like this in rfkill-bt.c : #ifdef CONFIG_OF static struct of_device_id bt_platdata_of_match[] = { { .compatible = "bluetooth-platdata" }, { } }; MODULE_DEVICE_TABLE(of, bt_platdata_of_match); #endif //CONFIG_OF Basically, if there's a DTS node "compatible" with bluetooth-platdata, the driver will get loaded and the whole probing process will start. The DTS reading and detection is performed by the 'platform_driver' detection mechanism. static struct platform_driver rfkill_rk_driver = { .probe = rfkill_rk_probe, .remove = rfkill_rk_remove, .driver = { .name = "rfkill_bt", .owner = THIS_MODULE, .pm = &rfkill_rk_pm_ops, .of_match_table = of_match_ptr(bt_platdata_of_match), }, }; Basically, it will call rfkill_rk_probe and starts the whole thing. Now, the rfkill system already has some hooks. Notably one that is used in a lot of other drivers, including the HCI driver : static const struct rfkill_ops rfkill_rk_ops = { .set_block = rfkill_rk_set_power, }; In this example, rfkill-bt.c, rfkill_rk_set_power is called everytime an RFkill block request is sent. The RFkill callbacks are defined here https://github.com/torvalds/linux/blob/master/include/linux/rfkill.h. Basically, the function will receive 'true' when blocked and 'false' when unblocked. The HCI driver defines the same kind of function and callback here : https://github.com/torvalds/linux/blob/master/net/bluetooth/hci_core.c#L1988 The HCI driver defines the flag HCI_RFKILLED when blocked. This flag is then read by other functions to determine if they should operate or not. Concerning the Rockchip GPIO Bluetooth RFKILL system, the thing is, I still don't know why there's YET another GPIO driver. There's already a GPIO driver that seems to work fine on Intel platform. The detection is performed through ACPI, which is only used to get the GPIO numbers through ACPI tables, instead of DTS files. https://github.com/torvalds/linux/blob/master/net/rfkill/rfkill-gpio.c#L73 I'll continue with the rfkill-bt driver until it works, and then see if it's not possible to just add DTS detection method to rfkill-gpio. This would be cleaner and simpler, IMHO.
TonyMac32 Posted June 27, 2017 Author Posted June 27, 2017 12 minutes ago, Myy said: I'll continue with the rfkill-bt driver until it works, and then see if it's not possible to just add DTS detection method to rfkill-gpio. This would be cleaner and simpler, IMHO. I agree that GPIO would be simpler/cleaner, the ASUS kernel has the entire power setting portion of the driver disabled. My uncertainty is involving the RTC pin, I could enable it via gpio or disable the check as an experiment. In this circumstance I pulled the dependent headers and the rfkill_bt.c file. I'm not sure if something setting up the RTS happens to be in the gpio rfkill file, I'll look into that tonight.
x86demon Posted July 6, 2017 Posted July 6, 2017 Hi, @TonyMac32. Was this kernel already released or where it may be downloaded? I\m looking for kernel with workable wifi, bluetooth and ability to enable additional modules like USB webcam support. With TinkerOS 1.8 bluetooth A2DP is totally unusable
TonyMac32 Posted July 7, 2017 Author Posted July 7, 2017 The Legacy 4.4 kernel has the wifi and bluetooth, , although I have to warn you I have not tried A2DP with it. Remember WiFi and BT are sharing a single antenna, that will result in some less than amazing throughput if using both simultaneously. You will probably also want to change the default frequency governor, and I have not tried using any webcams with the board.
Tido Posted July 15, 2017 Posted July 15, 2017 In case you haven't read about it: TinkerOS_Debian V1.9 (Beta version) 18. Don't hold libsbc1 at 1.3-1 and update to latest libsbc1 since the issue for A2DP has been resolved. 1
TonyMac32 Posted July 16, 2017 Author Posted July 16, 2017 Of course they aren't sharing their work on Github because "beta". I've got some emails to write I guess...
Myy Posted August 15, 2017 Posted August 15, 2017 So, in order to tackle this Tinkerboard issue, I'm trying to write a small Out-Of-Tree driver "bluetooth" driver that focus on enabling and disabling the right GPIO pins, using the RFKILL system as a control system. It does NOT do the UART/HCI communication part, as this should be delegated to BlueZ IMHO. Currently, the code needs to be double checked and then tested (in this order). The point of this driver is to be able to maintain it easily, and so has been heavily commented. Feel free to remove the comments if your own forks. The Makefile needs to be edited in order to use your own kernel tree path, and your own cross-compiler prefix. Once done, just type make to compile the module. This driver needs a different DTS section than the Rockchip one, in order to avoid conflicts, confusion and other issues with the Rockchip "rfkill-bt" driver. So, if anyone with a Tinkerboard has some time to spare, and have enough GPIO knowledge to be sure that the GPIO defined in the DTS and the code are the good one, etc...; Feel free to test my driver. If the driver seem to load correctly, check with the rfkill programs if you can unblock the "bt-gpio" device. Then, if you can, try this hacked HCI attach version or use the latest HCI attach tool provided by BlueZ to set up the device.
TonyMac32 Posted August 15, 2017 Author Posted August 15, 2017 I can of course take a look, I tried this with a script and had some limited success, although the initialization would ultimately fail.
Myy Posted August 17, 2017 Posted August 17, 2017 Looking at Rockchip's code, I'm starting to wonder if the uart_rts0 GPIO was enabled at all when using their rfkill_bt driver. Maybe it was the reason ? However, in their DTS they initialize it with GPIOD_OUT_LOW, and I put GPIOD_OUT_HIGH in my code (since it's the value that's actually checked by the rfkill_bt driver). I don't know if I should put it to LOW again. The uart_rts0 GPIO don't have any "BT" prefix in their DTS but seems essential to get any communication working with the BT driver anyway.
karelv Posted August 27, 2017 Posted August 27, 2017 Hey, I just installed armbian on my tinker board. It works great! For me it is difficult to understand what is actually in the package and what is work in progress. Therefore here my question: The bluetooth function, is it supposed to work? (I have kernel "4.4.73-rockchip" installed) I got no adapters and it does not find devices... Thx!
TonyMac32 Posted August 27, 2017 Author Posted August 27, 2017 Kernel 4.4 does support bluetooth. If you look at the original post you'll see a status for the different kernels, a link, and a command that must be run at boot. A program "rtk_hciattach" is necessary to make the bluetooth stack talk to the bluetooth hardware. 1
planb Posted August 30, 2017 Posted August 30, 2017 Why don't you just integrate BT function to latest build?
KC13 Posted October 1, 2017 Posted October 1, 2017 On 7/7/2017 at 12:01 AM, TonyMac32 said: The Legacy 4.4 kernel has the wifi and bluetooth, , although I have to warn you I have not tried A2DP with it. Remember WiFi and BT are sharing a single antenna, that will result in some less than amazing throughput if using both simultaneously. You will probably also want to change the default frequency governor, and I have not tried using any webcams with the board. Sorry for the "Newb" question, but could one get around this bottleneck by using a USB Bluetooth adapter?
TonyMac32 Posted October 1, 2017 Author Posted October 1, 2017 Yes, Although I haven't done any real testing along those lines as yet, and the device would have to be supported by the kernel/Bluetooth stack. Google should be of some help there. Also remember the I/O bottleneck through USB, all 4 ports are shared through a hub, so bandwidth going to bluetooth will be taken away from whatever else you may be doing.
TonyMac32 Posted February 23, 2018 Author Posted February 23, 2018 Update: upcoming default (4.4-rockchip)image update will include services loading bluetooth on boot automagically. 1
jeffkid Posted March 6, 2018 Posted March 6, 2018 I am attempting to use the Tinker board to scan for Bluetooth Low Energy (BLE) advertisements, or AKA BLE beacons. I am running the latest armbian OS for the board and have installed the BlueZ package. I am unable to get my working python module to scan for beacons on the system. While attempting to debug the situation, I found that the system was not recognizing the internal bluetooth module at all. I am not able to utilize the internal bluetooth adapter for any type of bluetooth application. I believe there to be something wrong with the kernel's bluetooth module, but this is where it becomes beyond my knowledge. I appreciated any information, direction, guidance on this topic.
Myy Posted May 8, 2018 Posted May 8, 2018 So, continuing the discussion of this thread here : 2 hours ago, TonyMac32 said: It's a Realtek 8723BS, but operates the same way. (any guess what BS stands for? ;-) ). I actually think we should wipe out the DTS entry that's there for it and start over, since that one appears to be tied somehow to the Rockchip special rfkill system. I was able to get it to start the handshake by toggling the gpio pins associated, so this might be a template for getting to to work properly. Ok, enough off-topic. :-D BS stands for BullShit of course ! ＼（・ヮ・）／ ... Broadcom Systems ? (・ω・｀ ) Anyway, since the Rockchip DTS uses one naming, the kernel uses another one and the Rockchip Datasheet uses yet another one, I don't which one we're talking about. According to TRM : GPIO4C3 is RTS. The DTS says GPIO4 19 for RTS. I guess that the kernel starts from GPIO 0 and the TRM using one letter every 8 bits, so GPIO4C3 refers to GPIO4 2*8 + 2 -> GPIO4 19 ? Now the kernel wants the absolute reference when enabling it. Since there seems to be only 32 pins per GPIO group, GPIO4 19 would be GPIO 128 + 19 -> GPIO 147 ? So exporting the RTS pin would be something akin to : echo 147 > /sys/class/gpio/export This would lead to : UART_RTS : GPIO4 19 (GPIO4C3 : uart0bt_rtsn - RTS Pin) → GPIO147 RESET : GPIO4 29 (GPIO4D5 : sdio0_bkpwr - Reset == Remove the backup power ??) → GPIO157 WAKE : GPIO4 26 (GPIO4D1: sdio0_detectn - Wake up == Detect the chip ??) → GPIO154 WAKE_HOST_IRQ : GPIO4 31 (GPIO4D7 : Undocumented) → GPIO159 So basically, to expose the Bluetooth GPIO (besides the IRQ one) : echo 147 > /sys/class/gpio/export echo 157> /sys/class/gpio/export echo 154 > /sys/class/gpio/export ? I'll try that and see how it fares.
Myy Posted May 8, 2018 Posted May 8, 2018 Okay, it seems that Rockchip already export the base groups and GPIO0 only has 24 pins root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip0/label gpio0 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip0/ngpio 24 GPIO4 starts from 120, not 128 it seems : root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/label gpio4 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/ngpio 32 root@tinkerboard:/sys/class/gpio# cat /sys/class/gpio/gpiochip120/base 120 So the actual values would be : UART_RTS : GPIO4 19 (GPIO4C3 : uart0bt_rtsn - RTS Pin) → GPIO139 RESET : GPIO4 29 (GPIO4D5 : sdio0_bkpwr - Reset == Remove the backup power ??) → GPIO149 WAKE : GPIO4 26 (GPIO4D1: sdio0_detectn - Wake up == Detect the chip ??) → GPIO146 WAKE_HOST_IRQ : GPIO4 31 (GPIO4D7 : Undocumented) → GPIO151 But the export functions give me nothing on my 4.17. I'll check tomorrow if I'm not missing an option with GPIO export. I'll also remove the DTS entry, see if it "frees" up the GPIO.
Myy Posted May 8, 2018 Posted May 8, 2018 Hmm, I'm able to export the wake_host_irq and the reset GPIO, but not the wakeup one. Also, I'll have to compile the latest BlueZ toolset and Larry Finger patched hciconfig too. So far, dmesg throws an error when playing with the reset GPIO : [ 117.592575] gpio-149 (sysfs): gpiod_request: status -16 [ 117.592580] export_store: status -16
Myy Posted May 12, 2018 Posted May 12, 2018 Okay, I got it "kind of" working with a 4.17-rc4. I say "kind of" because I only tested scanning, which worked (with UTF-8 support too !). I didn't get that much farther because... I'm no bluetooth user so I don't know how to test it in a meaningful way. Anyway, here's the catch, you need to enable all the GPIO, including the RTS one, through the GPIO export. Note that I tested this without the "wireless-bluetooth" entry in the DTS. Enable Bluetooth GPIO cd /sys/class/gpio echo 139 > export echo 146 > export echo 149 > export echo 151 > export echo low > gpio139/direction echo high > gpio146/direction echo high > gpio149/direction echo high > gpio151/direction Then download Larry W Finger hciattach tool and use it like he says : ./rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 Testing was done like that : root@tinkerboard:~# hcitool scan Scanning ... C4:86:E9:5E:50:89 ? ? is my Huawei phone with Bluetooth activated. Spoiler Reset Note that if the rtk_hciattach were to fail, you'll be unable to send any packet to the chip again until your "reset" it. Resetting is done like this : cd /sys/class/gpio/gpio149 echo "0" > value echo "1" > value I'm putting this behind a Spoiler, to avoid people running these commands blindly. 1
TonyMac32 Posted May 12, 2018 Author Posted May 12, 2018 I saw some French going back and forth on on your github, . So, perhaps this can be put into a service or perhaps compiled into a "tinker_hciattach". I'll toss it on the list of things to look at. :-P [edit] if hcitool can scan, then bluetooth is working. [edit2] (posting while thinking) needs look at the device tree a bit more I think, could take care of some of this.
Myy Posted May 12, 2018 Posted May 12, 2018 I'm currently preparing a new DTS patch that won't add the Bluetooth nodes. I'm also forking the rtk_hciattach repository and adding a few scripts to make it "testable" by any user. I'm currently wondering if the "Reset" mechanism doesn't kill the Wifi system... There's nothing in my dmesg that attest that though. Now there's still some hideous messages in my dmesg concerning bluetooth, so that clearly needs testing.
Myy Posted May 12, 2018 Posted May 12, 2018 Alright, here's a repository with the scripts prepared : https://github.com/Miouyouyou/tinkerboard_rtl8723bs And here's the new DTS patch I'm using, that enables the WIFI and SDIO but do not add the Wireless bluetooth node : https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.17/DTS/0015-ARM-DTS-rk3288-tinker-Enabling-SDIO-and-Wifi.patch
TonyMac32 Posted May 13, 2018 Author Posted May 13, 2018 1 hour ago, Myy said: I'm currently wondering if the "Reset" mechanism doesn't kill the Wifi system... The last look I had at the rtl8723bs datasheet showed (if I remember) an independent reset for the bluetooth, so that should be fine. I will take a look shortly.
TonyMac32 Posted May 13, 2018 Author Posted May 13, 2018 &uart0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&uart0_xfer>, <&uart0_cts>, <&uart0_rts>; }; Should at least pull the RTS out of the list of exports. Then the possibility of using rfkill-gpio improves. I'll look into a gpio binding that will get the other pins set up. [edit] Confirmed that adding <&uart0_rts> to the uart0 pin control makes it unnecessary on the gpio manipulation. Also successfully paired a device as an audio source, and played some songs through it. [edit2] It kind of looks like the most straightforward "solution" would be to define the reset/etc as LED's just to get them configured by the kernel without userspace intervention... someone with more kernel-fu than I can cut in and call me an idiot, I would appreciate it as a learning opportunity.
TonyMac32 Posted May 13, 2018 Author Posted May 13, 2018 For the Adventurous: https://github.com/armbian/build/commit/3b4338069f751fbf7c51315c3f0b6008719dbc02
Myy Posted May 13, 2018 Posted May 13, 2018 Hmm, configuring them as LED would be nice, but I'm wondering how we could generate a reset if needed. Maybe by disabling it/enabling the led through the /sys entries ? Note that rtk_hciattach might just not work after the first activation. So if you disable the Bluetooth for "energy saving" purposes (I think some people turned a Tinky into a tablet, with a battery system to power it), you might not be able to activate it again, without resetting the chip. That said, I'll try to mess with the DTS and add some LED definitions corresponding to these GPIO, see how it fares. Now, at the worst case, we could just write a userspace driver that will handle the Buetooth GPIO, and the reset mechanism.
Recommended Posts