Ma Tianfu Posted November 23, 2018 Posted November 23, 2018 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.
jerryn Posted November 24, 2018 Posted November 24, 2018 That link you posted looks interesting. When I get home I'm going to give a userspace work around a shot
jerryn Posted November 24, 2018 Posted November 24, 2018 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.
jerryn Posted November 27, 2018 Posted November 27, 2018 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 ?
jerryn Posted November 28, 2018 Posted November 28, 2018 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.
vzsze Posted November 28, 2018 Posted November 28, 2018 (edited) 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 November 28, 2018 by vzsze Added info about build.
martinayotte Posted November 28, 2018 Posted November 28, 2018 5 hours ago, vzsze said: It couldn't find the root-fs, which is on SSD Check the UUID of your SSD and make sure that this UUID is the one used in both /boot/armbranEnv.txt and /etc/fstab.
jerryn Posted November 28, 2018 Posted November 28, 2018 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
vzsze Posted November 29, 2018 Posted November 29, 2018 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
martinayotte Posted November 29, 2018 Posted November 29, 2018 1 hour ago, vzsze said: ALERT! UUID=69... does not exist. Dropping to a shell! If you got this message, it doesn't seems to match with /boot/armbianEnv.txt and /etc/fstab ... Check it with the command "blkid" !
vzsze Posted November 29, 2018 Posted November 29, 2018 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.
martinayotte Posted November 29, 2018 Posted November 29, 2018 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 ?
vzsze Posted November 29, 2018 Posted November 29, 2018 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
martinayotte Posted November 29, 2018 Posted November 29, 2018 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
suka Posted November 30, 2018 Posted November 30, 2018 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
vzsze Posted November 30, 2018 Posted November 30, 2018 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?
martinayotte Posted November 30, 2018 Posted November 30, 2018 1 hour ago, vzsze said: What's the appropriate place to issue a bug report about this? If it related to build proces, here : https://github.com/armbian/build/issues
Hover Posted December 1, 2019 Posted December 1, 2019 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.
TinaB Posted January 3, 2020 Posted January 3, 2020 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.
Recommended Posts