Adding Bluetooth to your Kernel

[sghazagh]

As per Tonymac32 suggestion, I closed the WIFI issue as it successfully run on Tinker Board. So Thank you :) Just please remember to move Firmwares to "rtlwifi" folder as WIFI is looking into that folder by default to load the firmware.

Bluetooth device is not recognized as a device! Not sure if it is Kernel /Device Tree related issue or need to power it up through user space (GPIO or something). By the way, "rfkill list" command shows only "phy0-Wireless LAN" device and not "hci0" which should be Bluetooth.

Thanks

[sghazagh]

Miouyouyou, I do suggest to rename the Project from "MyyQi" to "RK3288-Kernel" or "Tinker-MiQi-Kernel " or something relevant as this repository is well serving the RK3288 devices now, for sure "Tinker Board" and as you said "MiQi".

[Tonymac32]

https://github.com/lwfinger/rtl8723bs_bt

H5 protocol necessary apparently, hci uart 3-wire

[sghazagh]

Guys, I searched through official image and I found that they have definitely used "rtk_hciattach" tools that Tonymac32 is refering to attach the hci. I have copied the executable file to my rootfs (debootstrap Ubuntu Xenial) and have adjusted the script from the URL and ran it.

Here is the log:

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 :3-wire sync pattern resend : 2, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 3, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 4, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 5, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 6, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 7, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 8, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 9, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 10, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 11, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 12, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 13, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 14, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 15, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 16, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 17, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 18, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 19, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 20, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 21, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 22, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 23, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 24, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 25, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 26, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 27, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 28, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 29, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 30, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 31, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 32, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 33, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 34, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 35, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 36, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 37, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 38, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 39, len: 8
Realtek Bluetooth :3-wire sync pattern resend : 40, len: 8
Realtek Bluetooth ERROR: H5 sync timed out

I don't know if it shows something useful!

Here is the Script that I have read through and fix it to work at least for fining the TTYs:

#!/bin/bash
#
# Shell script to install Bluetooth firmware and attach BT part of
# RTL8723BS
#
if [ "$1" = "" ]
then
    # Find the TTY attached to the BT device
    TTYSTRING=`dmesg -t | grep tty | grep MMIO | cut -b 18-22`
    TTY=`expr substr "$TTYSTRING" 1 5`

    if [ "$TTYSTRING" = "" ]
    then
    echo
    echo "No BT TTY device has been found"
    echo "Either this computer has no BT device that uses hciattach, or"
    echo "Your kernel does not have module 8250_dw configured."
    echo "Note: The configuration variable is CONFIG_SERIAL_8250_DW."
    echo
    exit 1
    fi
else
    # Use the TTY device mentioned oi the call
    TTY=$1
fi

TTY="/dev/$TTY"
echo "Using device $TTY for Bluetooth"

if [ ! -f /lib/firmware/rtlbt/rtl8723b_config ];
then
    mkdir -p /lib/firmware/rtlbt/
    cp rtlbt_* /lib/firmware/rtlbt/.
fi
./rtk_hciattach -n -s 115200 $TTY rtk_h5 > hciattach.txt 2>&1 &

Note: I already have copied the existing "rtlbt" firmware folder mentioned inside the script, from official image, into the rootfs as well!

Miouyouyou, I also checked and for "8250_dw" both these two options are enabled in default config: CONFIG_SERIAL_8250_FSL=y CONFIG_SERIAL_8250_DW=y

[Miouyouyou]

dmesg -t | grep tty | grep MMIO | cut -b 18-22 ?? It looks for a line with 'tty' and 'MMIO' in dmesg but cannot find it as I understand.

I'll take a look at the other Git repository, see if I can figure something out.

[Miouyouyou]

Alright, based on @TonyMac32 comment in the previous bug report, some configuration options are required in the kernel (CONFIG_BT_HCIUART_3WIRE), but are not enabled currently.

I'm enabling them, together with other not enabled Bluetooth options, and I'm doing a full recompilation just now. The new images should be available in a few hours, if everything goes well.

[sghazagh]

this command: dmesg -t | grep tty | grep MMIO | cut -b 18-22 actually returns ttySx. In original script the cut was 14-18 which was wrong (at leas on my device). I changed it to 18-22 (shifted it 4 characters) and then it returned: ttyS0 ttyS1 ttyS2 ttyS3

you can directly provide ttySx as argument 1. In both cases is set the TTY variable to /dev/ttySx

In case you don't provide the argument the final command will be this: ./rtk_hciattach -n -s 115200 /dev/ttyS0 rtk_h5 > hciattach.txt 2>&1 &

And the log is what I attached above! I tried that with other available ttySx as well, but no luck.

It also tries to copy the firmwares from downloaded folder (git cloned folder) to /lib/firmware. In our case that bit does not required as the firmware already was copied by me manually.

[Miouyouyou]

Alright, I've pushed a new kernel with a new configuration file that enables what should be the right Bluetooth options for HCI UART. Give it a shot and see if it gets better.

[sghazagh]

Miouyouyou I tried to use working kernel (4.4.16), working DTS and working firmware and modules by adding them to my rootfs. still cannot see the hci0 device. I don't think if it is kernel related, because same set of kernel,device tree,module and firmware on official Debian rootfs works just fine. I think there should be something in usermode which enables the Bluetooth!

but this hci0 device is not available in first place!

In official image when I use "rfkill list", I see:

0: phy0: Wireless LAN
      Soft blocked:   no
      Hard blocked:  no
1: hci0: Bluetooth
      Soft blocked:   no
      Hard blocked:  no

With same set of kernel,device tree,module and firmware in Ubuntu Xenial debootstrap rootfs, I only see device 0, like:

0: phy0: Wireless LAN
      Soft blocked:   no
      Hard blocked:  no

What do you think?

[Miouyouyou]

Even with CONFIG_BT_HCI_UART support ? I'l can take a look at the configuration and DTS files used by tablets kernel that integrated this driver. With the new kernel, do you have any reference to 'hci0' in the dmesg output ?

Also, this might help : https://github.com/lwfinger/rtlwifi_new/issues/187

[Miouyouyou]

Also, yeah, I'll rename the repository for the 4.13 release.

[sghazagh]

Which new kernel? the one I have compiled last night , NO. The one you added recently, as it gets all linux folder again, I only can check it tomorrow. Unless you upload zImage and DTB file plus modules and firmware to a cloud like Google Drive and send me the Download link. Can you do it now? otherwise I have to go trough compile process from scratch!

[Miouyouyou]

The boot folder the repository already contains compiled kernels.

That said, here are the links that can help you get the latest compiled kernels of this repository: https://github.com/Miouyouyou/MyyQi/archive/v4.12-rc4-p3.tar.gz https://github.com/Miouyouyou/MyyQi/raw/master/boot/zImage https://github.com/Miouyouyou/MyyQi/raw/master/boot/System.map-4.12.0-rc4-The-Twelve-MyyQi%2B https://github.com/Miouyouyou/MyyQi/tree/master/lib/modules/4.12.0-rc4-The-Twelve-MyyQi%2B

If you download https://github.com/Miouyouyou/MyyQi/archive/v4.12-rc4-p3.tar.gz just copy boot/* in /boot/, lib/* in /lib/ and usr/ in /usr/ .

[sghazagh]

I cannot see the archive folder , therefore the first link shows the error 404.

[Miouyouyou]

Strange, I just checked with another browser in private mode and it worked. Is it a Github 404 page that you get when downloading the archive ?

[sghazagh]

yes , error 404. you see as you are a owner of repository. I don't think anyone else can see that.

Anyway, I compiled the kernel again. I see taht you have made the Mali as a module so now I see these modules loaded: bnep r8723bs mali_kbase dw_hdmi_i2s_audio bpa10x

However, still Bluetooth device is not available and I cannot see the hci0 device!

I think your kernel now has all the required options, except you also need to have firmware which I have it in my rootfs. I can send it to you for inclusion when we get it working....

we have to figure out what we need in usermode to get it up and running.

[Miouyouyou]

Alright, so:

• Could you paste the dmesg output ?
• What does rtk_hciattach returns this time ? Is it still timing out ?

I'll add the firmware for the next release, yeah. Meanwhile, I'd like to know if this firmware and these tools can work with the staging driver.

[sghazagh]

the rtk_hcitools exactly is same as before. Removed dmesg to shorten the page Got really tired, have to go to sleep... Hope you can get it working then your Kernel will be the most recent and working kernel for Tinker Board!

If you have any resource how knows about userspace, ask if we need to do anything in userspace to get it working. As I said, I still believe kernel part is done and we need to some sort enable the Bluetooth inside the userspace!

Till tomorrow, have a good after noon...

[sghazagh]

I recompiled 4.12.0.-rc4-p4 Unfortunately the Bluetooth still does not work as I cannot see the "hci0" device again!

Removed dmesg to shorten the page

rfkill list

0: phy0: Wireless LAN
    Soft blocked: no
    Hard blocked: no

lsmod

Module                  Size  Used by
bnep                   20480  2
mali_kbase            520192  0
r8723bs               552960  0
dw_hdmi_i2s_audio      16384  0
bpa10x                 16384  0
hci_uart               61440  1 bpa10x
btbcm                  16384  1 hci_uart
btqca                  16384  1 hci_uart
btintel                16384  1 hci_uart

[sghazagh]

I am using "rk3288-miniarm.dtb" as the official image uses. Is it different that "rk3288-tinker.dtb" ? Should I use this one?

Did you really test the Bluetooth is working? if yes please tell me why the device hci0 cannot be seen at all!

[Tonymac32]

https://forum.armbian.com/index.php?/topic/3327-asus-tinkerboard/&do=findComment&comment=33245

If using the external program, I suggest sifting through the commit to see if they toggle an I/O for "Chip Enable" on the bluetooth part of the module. If so, the module may simply be "off" and so not answering.

[sghazagh]

Hi Tony, Can you please answer this question? If I use, working kernel, device tree file, modules and firmware grabbed from the official Debian 1.8 Image issued by ASUS, should I expect to see the hco0 device in my rootfs or not?

I just used all thoes stuff and I still cannot see the device in my rootfs!

Doesn't that means that I need to do something in userspace (my rootfs) to be able to bring up the BT device?!

[sghazagh]

Guys, I just think that it is more complicated that what I was expecting... I installed a fresh SD from Debian 1.8 image and copied all the relevant files like kernel, dtb, modules, firmware, startup files and... the BT device cannot been initialized at all. (WiFi is ok) The interesting thing is that in firmware folder they only have two files for Bluetooth in "rtlbt" folder. Even no firmware for WiFi !!! I believe they embedded everything inside the kernel!!!

Meanwhile, I did other way around as well. I booted up the official image with 4.12.0-rc4 kernel,modules and firmware. Bluetooth which was known before, is gone from the known device list by "rfkill list" Also means that this kernel does not have the required driver or whatever needed to initialize and know the Bluetooth device!

[Miouyouyou]

I'm taking a look at https://github.com/lwfinger/rtl8723bs_bt and I'm seeing this in the log dw-apb-uart: probe of ff1c0000.serial failed with error -28. Since the Bluetooth driver tends to use serial communication to access the Bluetooth driver, I'm wondering if this is linked or not.

ff1c0000 is linked to uart4 which doesn't seem to be initialized correctly.

Anyway, I'm looking at the user-space code provided here https://github.com/lwfinger/rtl8723bs_bt/blob/master/hciattach_rtk.c and it basically relies on reading values from a serial port, using UART protocol.

The Tinkerboard modifications on the 4.4 kernel seem rather heavy-handed and use HCI protocols that are not used by the drivers provided by Larry so... this will have to wait for this week-end I guess.

Note that, they indeed integrated a lot in their kernel. But I'm always wary about replicating such heavy-handed modifications. Mostly because they break support on many other boards and might not even be necessary in the first place.

I guess that I'll try to ping @lwfinger by opening an issue in his tracker. We might be simply missing a few configuration lines here and there.

[sghazagh]

Sound great, I am just thinking, if you can make this Kernel works fine with Bluetooth, this will be the most recent and up-to-date kernel available in whole Internet for Tinker Board. Your work so far is much appreciated anyway...

I am sure you can figure that out. I also try to do my best to participate and get it working. At least for testing and providing the logs :)

Let us know if you have made any progress please...

[Tonymac32]

All of the device trees say uart 0 for by, so I haven't spent much time working on uart4 issues. I am going to try the 4.4 kernel tonight, I seem to remember seeing different dmesg output concerning the tty and bt.

[Tonymac32]

It would appear they are also using hci_attach to do the work. It would seem from my research that hci0 does not exist until you run hci_attach. I have also com across an apparent need to enable gpio rfkill in kernel config along with some patching: https://groups.google.com/forum/#!topic/Android-x86/kPBpj3CoXW4

[sghazagh]

Hi Guys, Yes, I also have downloaded and compiled the "rtk_hciattach" tool and scripts. (it also could be copied from official image-I found it in /usr/local/bin folder) Problem is that, it cannot send the data and sync data with ttyS0, and all other available ttySx. See above logs, it says "Realtek Bluetooth ERROR: H5 sync timed out".

Probably because the device is off some sort or needs to be known first and the attach t to ttyS0!!!

[Miouyouyou]

I've seen the patch but it seems that the whole rfkill acpi tables has been thrown away and only GPS systems remain. I could try to add it to the list, see if changes anything though.

[Miouyouyou]

Alright, I'm recompiling a kernel with such support however... the table in which they add the information is an ACPI table, which is an Intel thing. I wonder if this will have any effect.

[Miouyouyou]

This time there's no patch added. Just test the zImage and see if the rfkill system gets loaded and attached to the bluetooth system.

[sghazagh]

Miouyouyou, Nop! still only seeing wifi device "phy0" and no "hci0"! (using zImage created Sun 11 June, 3:43:11)

[Miouyouyou]

It seems that there's yet another Bluetooth HCIAttach binary for this chipset.

According to @Xalius on ARMbian forums, Pine64 used the binary provided in the following Git repository to get Bluetooth working on Pine64 boards :

https://github.com/NextThingCo/rtl8723ds_bt

If you can give it a try and paste your dmesg after that.

[sghazagh]

Same as before... Sync Timeout...

By the way, I only could make rtk_hciattach. It seems that it needs whole kernel folder on local to build the derive! but we cross compile the kernel.... cannot get everything created inside the device.Take ages to build then....

[Miouyouyou]

Could you try the following command:

rfkill unblock all

And then give the rtk_rciattach a try again ?

[sghazagh]

I always do my friend. If the device is not known after boot finishes, none of the hci command works!

[Tonymac32]

We have to add the bluetooth device to the rfkill driver first (maybe you already did?), and then, if I'm not mistaken hci0 may not exist directly. The hci_attach program's job is to communicate over the uart, on the 4.4 kernel, for example, hci0 does not exist, but hci_attach will communicate with the BT chipset up until it, I assume, decides to attach to the bluetooth stack. At which point it hangs the cpu.

[sghazagh]

I don't know may be! But it does not work when you try to use applications like "bluetoothctl". It does not know the device. The "rtk_hciattach" tool also timeout as it cannot find the device on ttyS0.

I think we miss something in userspace. We have to find out why we cannot attach the Bluetooth device. As I mentioned before, even official kernel, modules and firmware copied to other rootfs, do not work. Means that, userspace does something that brings up the Bluetooth. I already tried few thins which I thought might help. Like udev rules, startup scripts and ... .None of them brought up the Bluetooth. And if the rfkill does not know the ttyS0--> hci0 --> Bluettoth Device, nothing works!

[Tonymac32]

Yes, I can verify that rfkill does not know of the bt module's existence. There is something wrong with the uart in my opinion, and I think it traces back to yet more kernel hacking in the 3.10 -> 4.4 kernels by Rockchip.

https://github.com/TinkerBoard/debian_kernel/commit/3a2b762e8fc156103e77574b12364e79f94b9a86 https://github.com/TinkerBoard/debian_kernel/commit/668a1834bb4d7ebf76ad983e4f9b4e4767adfcfa https://github.com/TinkerBoard/debian_kernel/commit/ed7869a3f4ce42bea89299b49ff29783bb9700c0

Other than likewise integrating a special rfkill driver, or using these crumbs to write a special bt driver, I see no easy way to handle this. It may be possible, if the GPIO is available in userspace, to try to add it to the hci_attach software.

[sghazagh]

What about reboot issue then? is that same as this issue and you guys think that cannot be fixed easily as welll?

[x86demon]

I got same results with TinkerOS 1.8 and 4.12 kernel. With original kernel hci0 is in rfkill list untill I kill rtk_hciattach process. After this rtk_hciattach execution with same arguments returns same Time out errors for every ttyS[0..3]

Also I'm noticed by commit history that not only H5 code was modified in https://github.com/TinkerBoard/debian_kernel/tree/linux4.4-rk3288/drivers/bluetooth

May it be possible that device initialization is done in several steps with using different protocols?

[Tonymac32]

That's what I thought, hci0 is more or less created by the rtk_hciattach process. @sghazagh, the mmc core driver for rockchip SoC's has to be modified for some reason, that I believe I can manage as long as it doesn't cause any ill effects for the other rockchip devices (so far onlyMiQi), that are supported by this kernel.

[sghazagh]

I am thinking maybe the time we need to attach a device by "rtk_hciattach" tool is important. where do you guys recommend to insert the attach command for initializing the device before anything else? I tried runlevel 3 on "rc.local" but that might be late! I couldn't find any systemd unit file in original Debian Image related to Bluetooth to see if they have loaded as a service needed by other early started services! Just thought you might have some idea that we can test?!

@Tonymac32, Thanks for looking at the reboot issue. That helps a lot as we can remotely test the stuff and reboot properly when needed.

[sghazagh]

Guys, I tried to check my RPi Zero W device and see how the Bluetooth works. I realized that my rootfs do not know hci0 as well.

Then I search through the web and found that the RPi bluetooth needs to be attached with hciattach tool.

Story short, I could manage to get the hci0 attach with a command attaching the ttyAMA0 and then rfkill list the hci0. from there, all other command just works fine...

The only point I got from there is that, in RPi, they use something to check the valiue of GPIO and base on that it knows what speed needs to be set in hciattach. I tried different and if it's not a correct speed, the device does not attach.

I add the code here for your better understanding:

#!/bin/bash

if [ "$(cat /proc/device-tree/aliases/uart0)" = "$(cat /proc/device-tree/aliases/serial1)" ] ; then
        if [ "$(wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' ')" = "16" ] ; then
                /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 3000000 flow -
        else
                /usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -
        fi
else
        /usr/bin/hciattach /dev/serial1 bcm43xx 460800 noflow -
fi

(For RPi Zero , the first command works only: /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 3000000 flow - )

Now, first of all, we should have a correct hciattach binary as the protocols embedded inside the tools vary from version to version. for instance the raspberry pi one, do not have protocol rtk_h5, instead, it has bcm43xx which attach the BT device to hci0. Here is the list of protocols you can get from "hciattach -l" command, and here is for RPi version:

any       0x0000,0x0000
ericsson  0x0000,0x0000
digi      0x0000,0x0000
bcsp      0x0000,0x0000
xircom    0x0105,0x080a
csr       0x0000,0x0000
bboxes    0x0160,0x0002
swave     0x0000,0x0000
texas     0x0000,0x0000
texasalt  0x0000,0x0000
st        0x0000,0x0000
stlc2500  0x0000,0x0000
philips   0x0000,0x0000
bgb2xx    0x0000,0x0000
picocard  0x025e,0x1000
inventel  0x0000,0x0000
comone    0xffff,0x0101
tdk       0x0105,0x4254
socket    0x0104,0x0096
3com      0x0101,0x0041
bt2000c   0x022d,0x2000
zoom      0x0279,0x950b
sitecom   0x0279,0x950b
billionton0x0279,0x950b
bcm2035   0x0a5c,0x2035
bcm43xx   0x0000,0x0000
ath3k     0x0000,0x0000
qualcomm  0x0000,0x0000
intel     0x0000,0x0000
3wire     0x0000,0x0000
amp       0x0000,0x0000

And here is for Tinker Board version:

root@ELAR-Systems:~# /usr/bin/rtk_hciattach -l
any       0x0000,0x0000
bcsp      0x0000,0x0000
rtk_h4    0x0000,0x0000
rtk_h5    0x0000,0x0000

as you see the versions is vary and we might or might not use the correct one! We also have to find the proper command that can attach the device to ttyS0 and enables the "hci0"!

[x86demon]

Strange, but with rtk_h4 ttyS0 answered

[Miouyouyou]

Were you able to activate and use Bluetooth using the rtk_h4 subsystem ?

[x86demon]

@Miouyouyou no, here is an output

rtk_hciattach -n -s 115200 ttyS0 rtk_h4
Realtek Bluetooth init uart with init speed:115200, final_speed:115200, type:HCI UART H4
Realtek Bluetooth :Realtek hciattach version 2.5 

Realtek Bluetooth :config offset(f4),length(8)
Realtek Bluetooth :config baud rate to :4928002, hwflowcontrol:5f, 1
Realtek Bluetooth :config offset(27),length(1)
Realtek Bluetooth :config offset(fe),length(1)
Realtek Bluetooth :config offset(15b),length(4)
Realtek Bluetooth :config offset(1e3),length(1)
Realtek Bluetooth :Get config baud rate from config file:4928002
Realtek Bluetooth :Load FW OK
Realtek Bluetooth ERROR: Check signature error!
Realtek Bluetooth :baudrate in change speed command: 0x2 0x80 0x92 0x4 

Realtek Bluetooth :H4 Change uart Baudrate after write 
Initialization timed out

[Miouyouyou]

Realtek Bluetooth ERROR: Check signature error!

Hmm, I've added some debug messages here , https://github.com/Miouyouyou/rtl8723bs_bt/blob/master/hciattach_rtk.c , in order to get a little more informations about what's going on...

However, it looks like the driver is reading bogus values. 4928002 does not appear to be a valid baud rate at all. However, the fact that the h4 system went fine and the hc5 failed miserably is interesting. I'll try to see how both systems access the UART.

I didn't ask which rtk_rciattach you were using though. Larry Finger one or NextThingCo one ?

[Miouyouyou]

I also added a bit more informations about H5 time outs.

[x86demon]

It was Larry Finger compiled from github sources

[sghazagh]

I am pretty sure have checked with rtk_h4 as well and didn't get a response. Will double check later on and let you guys now!!!