Jump to content

ASUS Tinker Board Bluetooth


TonyMac32

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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.

 

 

 

 

Link to comment
Share on other sites

I saw some French going back and forth on on your github, :lol:.  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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 &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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines