Jump to content

NanoPC T4 bluetooth (mainline kernel)


Ma Tianfu

Recommended Posts

I tried building the mainline kernel (ayufan) for NanoPC T4. My aim is to bring up bluetooth. No quite familiar with device tree, just googling and reading the kernel doc, and now I had some luck.

 

According to this post (https://discuss.96boards.org/t/updated-preliminary-support-for-bluetooth-in-debian-rock960/5588/7) in 96boards forum, in recent kernel, there is a serial bus support for bcm blutooth.

 

----

 

firmware. I used firmware from the repo mentioned in the post: https://github.com/openwetek/wlan-firmware-aml/blob/master/bcm_ampak/config/4356/bcm4356a2.hcd

 

according to hci_bcm.c code, this file should be renamed to BCM4356A2.hcd and placed at /lib/firmware/brcm directory.

 

----

 

kernel config

 

First, serial bus should be enabled in kernel config, located at Device Drivers > Character devices > Serial device bus > Serial device TTY port controller.

 

Second, in Networking support > Bluetooth subsystem support > Bluetooth device drivers, enabled Broadcom protocol support. This option won't appear if serial bus is not enabled, aka, a dependency. Meanwhile, The UART (H4) protocol support will be enabled automatically. 

 

-----

 

device tree file

 

in "arch/arm64/boot/dts/rockchip/rk3399-nanopi4-common.dtsi",  there are two blocks named as "wireless-bluetooth", one containing full configuration of all gpios, clocks, and compatibles. The other contains only uart0_gpios pullup/pulldown configration (I guess). 

 

I removed the first block and left the second one intact. Don't know if the second block should be removed or updated.

 

then the uart0 block is modified to:

341 &uart0 {
342   pinctrl-names = "default";
343   pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
344   status = "okay";
345 
346   bluetooth {
347     compatible = "brcm,bcm43438-bt";
348     max-speed = <1500000>;
349     clocks = <&rk808 1>;
350     clock-names = "ext_clock";
351     shutdown-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>; /* GPIO0_B1, originally BT,reset_gpio */
352     device-wakeup-gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>; /* GPIO2_D2 */
353     host-wakeup-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>; /* GPIO0_A4 */
354   };
355 };

 

Rebuild and install the kernel and dtb package. The bluetooth now works as expected.

 

$ dmesg | grep Bluetooth

[    6.695813] Bluetooth: Core ver 2.22
[    6.696184] Bluetooth: HCI device and connection manager initialized
[    6.696196] Bluetooth: HCI socket layer initialized
[    6.696203] Bluetooth: L2CAP socket layer initialized
[    6.696311] Bluetooth: SCO socket layer initialized
[    6.741105] Bluetooth: HCI UART driver ver 2.3
[    6.741112] Bluetooth: HCI UART protocol H4 registered
[    6.741327] Bluetooth: HCI UART protocol Broadcom registered
[    6.957330] Bluetooth: hci0: BCM: chip id 101
[    6.957644] Bluetooth: hci0: BCM: features 0x2f
[    6.961779] Bluetooth: hci0: BCM4354A2
[    6.961788] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0000
[    7.965063] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0266

$ hciconfig
hci0:   Type: Primary  Bus: UART
        BD Address: CC:4B:73:1D:99:4F  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:3584 acl:0 sco:0 events:410 errors:0
        TX bytes:63761 acl:0 sco:0 commands:410 errors:0


 

Hopefully somebody will find this info helpful.

 

Also, not sure if the device tree modification is correct. Especially how to deal with the remaining "wireless-bluetooth" block. which looks like:

 

888   wireless-bluetooth {
889     uart0_gpios: uart0-gpios {
890       rockchip,pins = <2 19 RK_FUNC_GPIO &pcfg_pull_none>;
891     };
892   };

 

Shoudl I remove them out of the dtsi file? Or renaming/modifying the block to something correct? Any advice will be appreciated.

 

 

 

 

 

 

 

 

 

 

Link to comment
Share on other sites

Ma,

   Thanks for the link! You posted a real easy userspace workaround!  I  just run rfkill unblock bluetooth,
 and hciattach /dev/ttyS0 bcm43xx in a startup script.   Everything works.  Bluetooth keyboard,mouse, audio

 

When my MediaCenter is finished I will pair my old NVIDIA Shield remote with it.  The older remotes were bluetooth

 

You post was a big help.

 

Link to comment
Share on other sites

Just to update, when I upgraded to the latest stable release before I built mmp gstreamer modules, the user space rfkill / hci attach no longer works.  I think the firmware used for the board changed since the firmware is loaded but according to the logs some hci command time out. Not all fail.

Wrong firmware ?

Link to comment
Share on other sites

Update - I updated the bootconfig.   I am now configured rk3399-nanopi4-rev01.dtb.  I was configured with rev 1. kernel is 4.4.164-rk3399

Bluetooth initilization is qwerky.   I can get the Bluetooth operational using these steps.

systemctl enable ap6212-bluetooth  

systemctl disable brcm40183-patch

created a a script: /usr/local/bin/startbluetooth

 

#!/bin/bash
rfkill unblock bluetooth
hciattach /dev/ttyS0 bcm43xx

 

The script run in XFCE as a "Application Start" script when my XFCE4 session starts.   

 

I did  several shutdowns and cold boots root@nanopct4:/etc/init.d# hcitool lescan

 

LE Scan ...
6C:B0:FE:51:3C:20 (unknown)
6C:B0:FE:51:3C:20 (unknown)
CE:B3:47:FB:1F:DD Q5-1FDD
CE:B3:47:FB:1F:DD (unknown)
2C:26:17:0B:91:A6 (unknown)
2C:26:17:0B:91:A6 OMVR-V190
59:88:09:F5:69:9E (unknown)
59:88:09:F5:69:9E (unknown)

 

Right now I'm compiling a new version of MPV with vaapi support. Streaming Pandora as a test while compiling.  

The NanoPCT4 gets toasty.  I need to find a small fan that will fit in the NanoPC Metal case.
 

 

 

 

Link to comment
Share on other sites

I tried to install mainline kernel yesterday and my nanopc-t4 stopped booting. It couldn't find the root-fs, which is on SSD. Could fix it with reverting back to stable. Edited to add: This was on a Ubuntu Bionic build.

Edited by vzsze
Added info about build.
Link to comment
Share on other sites

I wanted to update the tread.  Bluetoooth isn't initializing again.  It could be a an issue when uploading the firmware. Here's what happens when Bluetooth fails to initialize properly:

 

[    2.377137] of_get_named_gpiod_flags: parsed 'uart_rts_gpios' property of node '/wireless-bluetooth[0]' - status (0)
[    2.377150] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: uart_rts_gpios = 83.
[    2.377169] of_get_named_gpiod_flags: can't parse 'BT,power_gpio' property of node '/wireless-bluetooth[0]'
[    2.377212] of_get_named_gpiod_flags: parsed 'BT,reset_gpio' property of node '/wireless-bluetooth[0]' - status (0)
[    2.377223] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,reset_gpio = 9.
[    2.377265] of_get_named_gpiod_flags: parsed 'BT,wake_gpio' property of node '/wireless-bluetooth[0]' - status (0)
[    2.377276] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_gpio = 90.
[    2.377317] of_get_named_gpiod_flags: parsed 'BT,wake_host_irq' property of node '/wireless-bluetooth[0]' - status (0)
[    2.377327] [BT_RFKILL]: bluetooth_platdata_parse_dt: get property: BT,wake_host_irq = 4.
[    2.377788] [BT_RFKILL]: Request irq for bt wakeup host
[    2.377887] [BT_RFKILL]: ** disable irq
[    2.378171] [BT_RFKILL]: bt_default device registered.
[   84.651284] Bluetooth: Core ver 2.21
[   84.651371] NET: Registered protocol family 31
[   84.651377] Bluetooth: HCI device and connection manager initialized
[   84.651396] Bluetooth: HCI socket layer initialized
[   84.651408] Bluetooth: L2CAP socket layer initialized
[   84.651439] Bluetooth: SCO socket layer initialized
[   94.885328] [BT_RFKILL]: rfkill_rk_set_power: set bt wake_host pin output high!
[   94.932247] [BT_RFKILL]: ENABLE UART_RTS
[   95.036188] [BT_RFKILL]: DISABLE UART_RTS
[   95.036254] [BT_RFKILL]: bt turn on power
[   95.042331] ttyS0 - failed to request DMA, use interrupt mode
[   95.073614] clk_uart0_frac parent_rate(800000000) is low than rate(48000000)*20, fractional div is not allowed
[   95.095211] Bluetooth: HCI UART driver ver 2.3
[   95.095231] Bluetooth: HCI UART protocol H4 registered
[   95.095240] Bluetooth: HCI UART protocol LL registered
[   95.095249] Bluetooth: HCI UART protocol ATH3K registered
[   95.095257] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   95.095635] Bluetooth: HCI UART protocol Intel registered
[   95.097276] Bluetooth: HCI UART protocol BCM registered
[   95.097292] Bluetooth: HCI UART protocol QCA registered
[   95.266269] Bluetooth: RFCOMM TTY layer initialized
[   95.266298] Bluetooth: RFCOMM socket layer initialized
[   95.266322] Bluetooth: RFCOMM ver 1.11
[   96.760576] [BT_RFKILL]: rfkill_rk_set_power: set bt wake_host pin output high!
[   96.807996] [BT_RFKILL]: ENABLE UART_RTS
[   96.912177] [BT_RFKILL]: DISABLE UART_RTS
[   96.912261] [BT_RFKILL]: bt turn on power
[ 1062.641813] Bluetooth: hci0 command 0x0401 tx timeout
 

 

Link to comment
Share on other sites

On 11/28/2018 at 3:37 PM, martinayotte said:

Check the UUID of your SSD and make sure that this UUID is the one used in both /boot/armbranEnv.txt and /etc/fstab.

It was. I made a copy of the files and checked. The error message was:

ALERT! UUID=69... does not exist. Dropping to a shell!

Rebooting automatically due to panic= boot argument

Link to comment
Share on other sites

54 minutes ago, martinayotte said:

If you got this message, it doesn't seems to match with /boot/armbianEnv.txt and /etc/fstab ...

Check it with the command "blkid" !

root@nanopct4:~# blkid
/dev/nvme0n1p1: UUID="6984f986-8788-4dc7-9e57-e5a27d39a7d6" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="85cf3890-e009-4640-b803-b868558967b1"
/dev/mmcblk1p1: UUID="53822d9c-1cb2-4a65-96e1-c20e030c4615" TYPE="ext4" PARTUUID="492db6dc-01"
/dev/nvme0n1: PTUUID="ccc5a30e-c5ff-463d-9514-dceb88c77f01" PTTYPE="gpt"
/dev/mmcblk1: PTUUID="492db6dc" PTTYPE="dos"
/dev/zram0: LABEL="log2ram" UUID="c13859e3-cb78-489a-89d0-e147116b6f8c" TYPE="ext4"
/dev/zram1: UUID="8346ad54-ee77-44ed-a14d-52cea05b4f10" TYPE="swap"
/dev/zram2: UUID="b96d2711-611b-4bb5-83b0-f43f6b235e72" TYPE="swap"
/dev/zram3: UUID="953d115a-07d3-4b62-83eb-f0d05bac59c8" TYPE="swap"
/dev/zram4: UUID="46fce07f-d5df-41d1-b833-2c673213d05b" TYPE="swap"

root@nanopct4:~# grep 6984f986-8788-4dc7-9e57-e5a27d39a7d6 /etc/fstab
UUID=6984f986-8788-4dc7-9e57-e5a27d39a7d6    /        ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide

root@nanopct4:~# grep 6984f986-8788-4dc7-9e57-e5a27d39a7d6 /boot/armbianEnv.txt
rootdev=UUID=6984f986-8788-4dc7-9e57-e5a27d39a7d6

 

It does exist when booting the stable kernel. After upgrading to linux-image-dev-rk3399 it doesn't find the device and halts with the alert. I tried it twice with the same result and had to switch back to stable kernel each time.

Link to comment
Share on other sites

51 minutes ago, vzsze said:

It does exist when booting the stable kernel.

Your "6984f986-8788-4dc7-9e57-e5a27d39a7d6" partition is /dev/nvme0n1p1, is the OS itself is present there or is it located in /dev/mmcblk1p1 which is "53822d9c-1cb2-4a65-96e1-c20e030c4615" ?

What the whole content of /etc/fstab ?

Link to comment
Share on other sites

Yes, "6984f986-8788-4dc7-9e57-e5a27d39a7d6" is the root partition.

/etc/fstab:

# <file system>                 <mount point>   <type>  <options>                           <dump>  <pass>
tmpfs                       /tmp        tmpfs   defaults,nosuid                         0   0
UUID=53822d9c-1cb2-4a65-96e1-c20e030c4615   /media/mmcboot  ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1
/media/mmcboot/boot                 /boot       none    bind                                0       0
UUID=6984f986-8788-4dc7-9e57-e5a27d39a7d6   /       ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1

 

 

Link to comment
Share on other sites

32 minutes ago, vzsze said:

Yes, "6984f986-8788-4dc7-9e57-e5a27d39a7d6" is the root partition.

Really strange ...

As a workaround try to change that line /etc/fstab of the SSD :

UUID=6984f986-8788-4dc7-9e57-e5a27d39a7d6   /       ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1

with :

/dev/nvme0n1p1   /       ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1

 

Link to comment
Share on other sites

I noticed my NVME is no longer detected at all on recent 4.19 dev kernels:

Since I just started playing around with Armbian on the NanoPC-T4 a few days ago I haven't gotten around to analyzing the failure further, e.g. if it is related to DTB or actual kernel changes, and would have opened a new topic then

 

Relevant section from yesterdays 4.19 dev build compared to stable 4.4.164:

grep pcie -i  boot_pcie_err_dmesg.txt
[    5.604837] rockchip-pcie f8000000.pcie: no vpcie12v regulator found
[    5.604856] rockchip-pcie f8000000.pcie: no vpcie3v3 regulator found
[    5.604868] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
[    5.604879] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
[    6.160995] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout!
[    6.161076] rockchip-pcie: probe of f8000000.pcie failed with error -110
grep pcie -i dmesg.4.4.164.log
[    1.962459] phy phy-pcie-phy.5: Looking up phy-supply from device tree
[    1.962469] phy phy-pcie-phy.5: Looking up phy-supply property in node /pcie-phy failed
[    1.964666] rockchip-pcie f8000000.pcie: GPIO lookup for consumer ep
[    1.964677] rockchip-pcie f8000000.pcie: using device tree for GPIO lookup
[    1.964705] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0)
[    1.964945] rockchip-pcie f8000000.pcie: Looking up vpcie3v3-supply from device tree
[    1.965037] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply from device tree
[    1.965048] rockchip-pcie f8000000.pcie: Looking up vpcie1v8-supply property in node /pcie@f8000000 failed
[    1.965062] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found
[    1.965070] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply from device tree
[    1.965079] rockchip-pcie f8000000.pcie: Looking up vpcie0v9-supply property in node /pcie@f8000000 failed
[    1.965091] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found
[    1.987144] rockchip-pcie f8000000.pcie: invalid power supply
[    1.999603] PCI host bridge /pcie@f8000000 ranges:

Will gladly accept any pointers on how to proceed, but am currently struggling with manually loading the relevant parts from U-Boot cli

Link to comment
Share on other sites

13 hours ago, martinayotte said:

Really strange ...

As a workaround try to change that line /etc/fstab of the SSD :


UUID=6984f986-8788-4dc7-9e57-e5a27d39a7d6   /       ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1

with :


/dev/nvme0n1p1   /       ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0   1

 

I cannot test this right now, but my suspicion is, that it is caused by the modularization of the nvme driver. The modules are inside of the initrd, but might not be loaded properly.

 

$ grep -i nvme config-4.4.156-rk3399
CONFIG_BLK_DEV_NVME=y
CONFIG_NVMEM=y

 

$ grep -i nvme config-4.19.0-rk3399
# NVME Support
CONFIG_NVME_CORE=m
CONFIG_BLK_DEV_NVME=m
CONFIG_NVME_MULTIPATH=y
CONFIG_NVME_FABRICS=m
CONFIG_NVME_FC=m
CONFIG_NVME_TARGET=m
CONFIG_NVME_TARGET_LOOP=m
CONFIG_NVME_TARGET_FC=m
# CONFIG_NVME_TARGET_FCLOOP is not set
CONFIG_RTC_NVMEM=y

 

Adding the modules to /etc/modules and updating the initrd might help. I will test this as soon as I can.

 

Sorry for hijacking this thread. I installed the mainline-kernel to test bluetooth. What's the appropriate place to issue a bug report about this?

Link to comment
Share on other sites

It seems on mainline kernel 5.3 & 5.4 the serdev bcm4356 driver is broken, while it worked on kernel 5.2. Anyone on nanopc t4 or m4 found the same problem?

 

Anything sent to the module via __hci_cmd_sync resulted in timeout. There was a refactor of the underlying 8250_dw uart driver after kernel 5.2, but I can not tell anything break the communication from the git diff.

Link to comment
Share on other sites

On 12/1/2019 at 1:54 PM, Hover said:

It seems on mainline kernel 5.3 & 5.4 the serdev bcm4356 driver is broken, while it worked on kernel 5.2. Anyone on nanopc t4 or m4 found the same problem?

 

I can confirm this, im using the latest version of buster desktop (2019-12-27) with 5.4 kernel and no wifi/bluetooth.

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