Bert Posted May 4, 2020 Posted May 4, 2020 (edited) Armbianmonitor: https://pastebin.pl/view/bbb9f5f0 Hello, Trying to figure out to get bluetooth working on Cubietruck with Armbian Buster mainline based kernel 5.4.y Installed all software but bluetoothctl keeps telling me there is no default controller. Seems to me the drivers are not loaded/activated. Is this supposed to work or m i trying to fix someting unfixable. Please bump me in the right direction.. Tjabks! Edited May 4, 2020 by Bert output armbianmonitor and title 0 Quote
joaofl Posted July 15, 2020 Posted July 15, 2020 Same here... Have tried many option, including compiling my own armbian. Nothing really works. Except if I plug an USB Bluetooth dongle, that work fine after getting the right broadcom drivers in place. Here are the logs for the hci0 device (onboard bluetooth device): Short log: dmesg | grep toot [ 11.011248] Bluetooth: Core ver 2.22 [ 11.011395] Bluetooth: HCI device and connection manager initialized [ 11.011421] Bluetooth: HCI socket layer initialized [ 11.011434] Bluetooth: L2CAP socket layer initialized [ 11.011469] Bluetooth: SCO socket layer initialized [ 11.398268] Bluetooth: HCI UART driver ver 2.3 [ 11.398283] Bluetooth: HCI UART protocol H4 registered [ 11.398288] Bluetooth: HCI UART protocol BCSP registered [ 11.398392] Bluetooth: HCI UART protocol LL registered [ 11.398397] Bluetooth: HCI UART protocol ATH3K registered [ 11.398453] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 11.398883] Bluetooth: HCI UART protocol Intel registered [ 11.399221] Bluetooth: HCI UART protocol Broadcom registered [ 11.399287] Bluetooth: HCI UART protocol QCA registered [ 11.399292] Bluetooth: HCI UART protocol AG6XX registered [ 11.399343] Bluetooth: HCI UART protocol Marvell registered [ 11.820070] Bluetooth: hci0: Frame reassembly failed (-84) [ 13.830695] Bluetooth: hci0: command 0xfc79 tx timeout [ 21.990700] Bluetooth: hci0: BCM: Read verbose config info failed (-110) [ 24.663143] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 24.663157] Bluetooth: BNEP filters: protocol multicast [ 24.663184] Bluetooth: BNEP socket layer initialized Complete logs here:http://ix.io/2rHa And some additional info from sunxi: Quote AMPAK From Linux 5.2, there's nice clean upstream support for broadcom bluetooth. See http://lists.infradead.org/pipermail/linux-arm-kernel/2018-November/610954.html for the full details. If you're adding bluetooth nodes to existing hardware, the quick traps are: missing the clocks/clock-names nodes on the wifi_pwrseq node. thinking that the "bt-reset-n" signal should be flagged as active low. Remember, you need kernel config option CONFIG_SERIAL_DEV_BUS to be able to select CONFIG_BT_HCIUART_BCM If you have these wrong, your kernel will keep reporting lines like ```Bluetooth: hci0: command 0x0c03 tx timeout``` 0x0c03 is the standard HCI request to reset the part, so this means your device is not (yet) responsive. Once this is all correct, your next trap will be finding suitable firmware, and getting it named correctly, though fortunately at this point, the kernel will simply tell you. linux-firmware repo has very few of the bluetooth files, your best bet is armbian's repo, though they will all need renaming, because armbian patched all that too. 0 Quote
CryBaby Posted July 15, 2020 Posted July 15, 2020 Same for me on Focal with 5.4.45. I suspect the bluetooth firmware is not being loaded. It is installed with armbian-firmware, the file is bcm20710a1.hcd. It should be sent via uart2 somehow, but it seems there is no tty for it. 0 Quote
joaofl Posted July 16, 2020 Posted July 16, 2020 I believe I found the reason why. The device tree overlays of the the board-specific peripherals are not being loaded correctly by u-boot. Not sure how to fix it. Any ideas @Werner? Find below the u-boot logs: U-Boot 2020.04-armbian (Jul 15 2020 - 13:11:40 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Cubietech Cubietruck I2C: ready DRAM: 2 GiB MMC: mmc@1c0f000: 0, mmc@1c12000: 1 Loading Environment from FAT... Card did not respond to voltage select! Setting up a 1024x768 vga console (overscan 0x0) In: serial Out: vga Err: vga Allwinner mUSB OTG (Peripheral) Net: eth0: ethernet@1c50000 Warning: usb_ether using MAC address from ROM , eth1: usb_ether 230454 bytes read in 15 ms (14.7 MiB/s) starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 1 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3967 bytes read in 2 ms (1.9 MiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 350 bytes read in 2 ms (170.9 KiB/s) 10965901 bytes read in 605 ms (17.3 MiB/s) 7172168 bytes read in 397 ms (17.2 MiB/s) Found mainline kernel configuration 42521 bytes read in 8 ms (5.1 MiB/s) 386 bytes read in 4 ms (93.8 KiB/s) Applying kernel provided DT overlay sun7i-a20-can.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 500 bytes read in 4 ms (122.1 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c3.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 766 bytes read in 4 ms (186.5 KiB/s) Applying kernel provided DT overlay sun7i-a20-i2c4.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 590 bytes read in 5 ms (115.2 KiB/s) Applying kernel provided DT overlay sun7i-a20-mmc2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 2301 bytes read in 4 ms (561.5 KiB/s) Applying kernel provided DT overlay sun7i-a20-nand.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 778 bytes read in 5 ms (151.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-pps-gpio.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 443 bytes read in 4 ms (107.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-pwm.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1040 bytes read in 4 ms (253.9 KiB/s) Applying kernel provided DT overlay sun7i-a20-spdif-out.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 556 bytes read in 4 ms (135.7 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-add-cs1.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1093 bytes read in 5 ms (212.9 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-jedec-nor.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1069 bytes read in 5 ms (208 KiB/s) Applying kernel provided DT overlay sun7i-a20-spi-spidev.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 808 bytes read in 5 ms (157.2 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart2.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 1078 bytes read in 5 ms (210 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart3.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart4.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart5.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart6.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 513 bytes read in 5 ms (99.6 KiB/s) Applying kernel provided DT overlay sun7i-a20-uart7.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ 777 bytes read in 5 ms (151.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-w1-gpio.dtbo failed on fdt_overlay_apply(): FDT_ERR_BADMAGIC base fdt does did not have a /__symbols__ node make sure you've compiled with -@ Error applying DT overlays, restoring original DT 42521 bytes read in 8 ms (5.1 MiB/s) ## Loading init Ramdisk from Legacy Image at 43300000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10965837 Bytes = 10.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 4958a000, end 49fff34d ... OK Loading Device Tree to 4957c000, end 49589618 ... OK 0 Quote
Werner Posted July 16, 2020 Posted July 16, 2020 Not really. That overlay stuff is beyond my skills 0 Quote
joaofl Posted July 16, 2020 Posted July 16, 2020 Actually I have realized that because u-boot fails to load the first overlay: Applying kernel provided DT overlay sun7i-a20-can.dtbo failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND 500 bytes read in 4 ms (122.1 KiB/s) Then the following ones will also fail. Cant tell why. So after removing the faulty ones from `/boot/armbianEnv.txt` list, I got the overlays loaded successfully. So I though that once the serial and spi ports got their overlay loaded, that the device would work and consequently the Bluetooth. But still, no bluetooth... [ 11.422077] Bluetooth: Core ver 2.22 [ 11.422216] Bluetooth: HCI device and connection manager initialized [ 11.422242] Bluetooth: HCI socket layer initialized [ 11.422254] Bluetooth: L2CAP socket layer initialized [ 11.422283] Bluetooth: SCO socket layer initialized [ 11.735777] Bluetooth: HCI UART driver ver 2.3 [ 11.735791] Bluetooth: HCI UART protocol H4 registered [ 11.735796] Bluetooth: HCI UART protocol BCSP registered [ 11.735901] Bluetooth: HCI UART protocol LL registered [ 11.735906] Bluetooth: HCI UART protocol ATH3K registered [ 11.735963] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 11.736254] Bluetooth: HCI UART protocol Intel registered [ 11.736524] Bluetooth: HCI UART protocol Broadcom registered [ 11.736589] Bluetooth: HCI UART protocol QCA registered [ 11.736594] Bluetooth: HCI UART protocol AG6XX registered [ 11.736676] Bluetooth: HCI UART protocol Marvell registered [ 14.055469] Bluetooth: hci0: command 0xfc18 tx timeout [ 21.468312] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 21.468325] Bluetooth: BNEP filters: protocol multicast [ 21.468351] Bluetooth: BNEP socket layer initialized [ 22.247521] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 22.247534] Bluetooth: hci0: Failed to set baudrate [ 24.263479] Bluetooth: hci0: command 0x0c03 tx timeout [ 32.487473] Bluetooth: hci0: BCM: Reset failed (-110) 0 Quote
CryBaby Posted July 16, 2020 Posted July 16, 2020 I have been following this page: It's out of date but I deduce from it that we should be seeing a tty directory in /sys/devices/platform/soc/1c28800.serial/ Do you have that now? 0 Quote
joaofl Posted July 17, 2020 Posted July 17, 2020 Yes, I do have the serial port in place. Still the same issue when reseting `hci0` ls /sys/devices/platform/soc/1c28800.serial/ driver driver_override modalias of_node power serial0 subsystem uevent dmesg | grep ttyS [ 0.000000] Kernel command line: root=UUID=69f5d75b-1ab7-4ffd-80a6-17d11e5447e2 rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 consoleblank=0 loglevel=1 ubootpart=0e31188e-01 ubootsource=mmc usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 2.450365] printk: console [ttyS0] disabled [ 2.470572] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 51, base_baud = 1500000) is a U6_16550A [ 2.470642] printk: console [ttyS0] enabled [ 2.491835] 1c28800.serial: ttyS1 at MMIO 0x1c28800 (irq = 52, base_baud = 1500000) is a U6_16550A [ 2.492030] serial serial0: tty port ttyS1 registered [ 2.515067] 1c28c00.serial: ttyS2 at MMIO 0x1c28c00 (irq = 53, base_baud = 1500000) is a U6_16550A [ 2.538141] 1c29000.serial: ttyS3 at MMIO 0x1c29000 (irq = 54, base_baud = 1500000) is a U6_16550A [ 2.561222] 1c29400.serial: ttyS4 at MMIO 0x1c29400 (irq = 55, base_baud = 1500000) is a U6_16550A [ 2.584406] 1c29c00.serial: ttyS5 at MMIO 0x1c29c00 (irq = 57, base_baud = 1500000) is a U6_16550A [ 10.676268] systemd[1]: Found device /dev/ttyS0. EDIT: But indeed, `/dev/ttyS1` is not there... Not sure what this means. 0 Quote
joaofl Posted July 17, 2020 Posted July 17, 2020 So if I understood correctly, the idea is to detach the ttyS1 from the bluetooth device, so that it can be used as a normal tty device, so that the operations can be carried by the hack done in https://github.com/phelum/CT_Bluetooth. Right? Thing is that with the device tree he provides there, the overlays wont work, and the board wont even boot up. So I guess we need to patch the serial port overlays and give another try. 0 Quote
CryBaby Posted July 17, 2020 Posted July 17, 2020 Not sure about detaching. What I have gleaned is that bt.load figures out which tty is attached to uart2 then sends the firmware to it. bt.init resets the chip via a couple of GPIO pins. The systemd service then attaches an hci device to the tty. This is what bluetooth clients use. Now this is all handled by the kernel and I am just assuming that it does pretty much the same thing. In which case not having /dev/ttyS1 is a problem. Using the right GPIOs will also be key. I get the impression that both tty and GPIOs can change between kernels. So we need all the overlays to load (some might provide power etc.) and they need to match the kernel in terms of the tty and GPIO numbers it is expecting. I'm afraid that device tree and kernel code are a little beyond my ken. 0 Quote
usual user Posted July 17, 2020 Posted July 17, 2020 1 hour ago, CryBaby said: I'm afraid that device tree and kernel code are a little beyond my ken. Device tree is describing the hardware design of a device that can't be auto detected. You probably missing a proper bluetooth DT node. It will tell the kernel which driver to load and the driver will know how the chip is wired and which firmware to load to operate the device. This is used to use the same driver for a particular chip, regardless of how it is wired and what possible configuration parameters it needs. Figuring the proper values for your specific board is the hard part if no DT node is already provided. But once it's done, it won't change unless you change your hardware design. 0 Quote
CryBaby Posted July 17, 2020 Posted July 17, 2020 So we shouldn't need to delve into kernel code, just figure out why the overlays aren't loading. Hopefully they already describe the hardware correctly. Unfortunately, uboot is also a bit beyond my ken... 0 Quote
usual user Posted July 17, 2020 Posted July 17, 2020 1 hour ago, CryBaby said: Hopefully they already describe the hardware correctly. Because the driver searches for the Bluetooth node, simply check that your device tree has such a node. This is the one of my device: &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_xfer &uart0_rts &uart0_cts>; status = "okay"; bluetooth { compatible = "brcm,bcm43438-bt"; clocks = <&rk808 1>; clock-names = "lpo"; device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>; host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>; shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>; max-speed = <4000000>; pinctrl-names = "default"; pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>; vbat-supply = <&vcc3v3_sys>; vddio-supply = <&vcc_1v8>; }; }; It showcase only what you are looking for. Because I have a completely different board and different BCM chip the values don't match for your board. Even the required bindings may vary (see the already referenced binding doc). But it will use the same driver in the end. 1 hour ago, CryBaby said: Unfortunately, uboot is also a bit beyond my ken... The only task of uboot is to initialize the system so that the boot device can be accessed. Then it loads the kernel and its companion data (dtb, initramfs, ...) and transfers control to the kernel. Since this already works, you don't have to worry about it. By the way, mainline uboot is using the same DT files while its build as the kernel uses, but requires only few DT nodes for its operation. And bluetooth isn't one of it, uboot has no business in bluetooth 0 Quote
CryBaby Posted July 17, 2020 Posted July 17, 2020 Now I'm wondering if the overlays are a red herring. Looking at my /boot none of the ones in joafl's log are there, just a sun7i-a20-cubietruck.dtb which if my reading of boot.cmd is correct, is getting loaded as the default that uboot is falling back to. Also, my armbianEnv.txt has no list of overlays, just a prefix. It looks like I'm going to have to install the kernel sources to get the dt source, which means I'm going to have to expand my filesystem as that did not happen on first run. And connect my cubietruck to a proper monitor so I can see the boot messages and maybe fiddle with uboot. Good job the weekend is coming. 0 Quote
usual user Posted July 17, 2020 Posted July 17, 2020 1 hour ago, CryBaby said: Now I'm wondering if the overlays are a red herring. All permanently equipped components on a device should be represented in the base dtb. Overlays are for optional components. Think of something connected via gpio-connector or a camara module via csi-connector. Because the configuration may clash or if an option is not applied, it is not desirable to have them in the base dtb. So if no addons are used the base dtb should suffice. 1 hour ago, CryBaby said: It looks like I'm going to have to install the kernel sources to get the dt source If you are interested in mainline, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree should suffice. And don't look too closely, it already has the Bluetooth node since a while I see no vbat-supply and vddio-supply bindings in there. But I don't know if they are required for your device. I see this: Quote 5197 [ 10.572239] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator 5198 [ 10.572369] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator in the logs. It may be normal but the real regulators may be not enabled by power management (no consumers). Maybe adding the bindings is the missing part, but I don't really know. 0 Quote
CryBaby Posted July 18, 2020 Posted July 18, 2020 Well, I have learned something. Disabling the non-functional desktop helps, you can find stuff in the logs now. Firstly: the firmware file. The old page I referenced earlier used the file /lib/firmware/ap6210/bcm20710a1.hcd but in my log it said this: [ 15.336274] bluetooth hci0: Direct firmware load for brcm/BCM20702A1.hcd failed with error -2 [ 15.336285] bluetooth hci0: Falling back to sysfs fallback for: brcm/BCM20702A1.hcd The wrong file is in armbian-firmware, the right file is not. I downloaded one from github and renamed it to match the message. It seemed to load successfully after that. It didn't work though, trouble is there is about 50 files that start with BCM20702A1 and no clue as to the right one. [ 15.104357] Bluetooth: hci0: unexpected event for opcode 0x06c4 [ 25.318761] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 25.332570] Bluetooth: hci0: Failed to set baudrate [ 26.926352] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 26.926365] Bluetooth: BNEP filters: protocol multicast [ 26.926393] Bluetooth: BNEP socket layer initialized [ 27.366710] Bluetooth: hci0: command 0x0c03 tx timeout [ 35.558743] Bluetooth: hci0: BCM: Reset failed (-110) [ 35.571171] Bluetooth: hci0: hardware error 0x00 [ 36.742620] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 36.756228] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 [ 37.606706] Bluetooth: hci0: command 0xfc18 tx timeout [ 45.798600] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 45.812862] Bluetooth: hci0: Failed to set baudrate [ 47.846607] Bluetooth: hci0: command 0x0c03 tx timeout [ 56.033010] Bluetooth: hci0: BCM: Reset failed (-110) Secondly: The tty. [ 2.565468] 1c28800.serial: ttyS2 at MMIO 0x1c28800 (irq = 51, base_baud = 1500000) is a U6_16550A [ 2.565660] serial serial0: tty port ttyS2 registered But /dev/ttyS2 no longer exists. Maybe attaching the hci to it is supposed to remove it? Thirdly: uboot/overlays. I have no errors relating to overlays in my uboot output. $ rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked 1 wlan phy0 unblocked unblocked $ bluetoothctl devices No default controller available So, possibly a step closer but not there yet. 0 Quote
usual user Posted July 18, 2020 Posted July 18, 2020 5 hours ago, CryBaby said: The old page I referenced earlier This post uses the outdated method of uploading the firmware via an user space tool. To have access to the bluetooth device it needs /dev/ttyS# for the communication. Further the firmware file name is given as a parameter so you can throw in any arbitrary name. The new method of uploading the firmware via the kernel driver has no way to use an arbitrary name. Because the driver is used for several BCM chips it can only use some generic name (brcm/BCM20702A1.hcd). Since the previously used bcm20710a1.hcd was apparently the right one, a symbolic link (ln --symbolic /lib/firmware/ap6210/bcm20710a1.hcd /lib/firmware/brcm/BCM20702A1.hcd) would be sufficient to continue using it. 5 hours ago, CryBaby said: Secondly: The tty. Having no /dev/ttyS# is ok, the kernel driver is now dealing with the uart2 and making it accessible to the user via /dev/ttyS# can even be dangerous as it can affect driver operation. 0 Quote
CryBaby Posted July 18, 2020 Posted July 18, 2020 I think I already tried linking the old file. I just tried it again and while the loading error is gone otherwise there is no change. Unfortunately this doesn't tell me whether the firmware is wrong or there is some other problem. The github says: Quote These devices requires two kinds of firmware - first for WiFi, and second for Bluetooth. Without WiFi firmware Bluetooth will not initialize and will not work properly. Firmware for WiFi already included to kernel, but you may need to do additional work to place correct NVRAM. I haven't tested the WiFi at all so I'll do that. I see no info on NVRAM for uart based devices. 0 Quote
usual user Posted July 18, 2020 Posted July 18, 2020 2 hours ago, CryBaby said: Unfortunately this doesn't tell me whether the firmware is wrong The firmware is probably for your device. If it is wrong for you, it may be missing a feature that you expect. Anyway, the basic functionality should be present so bluetooth starts working. Because the wifi and the bluetooth component share some hardware resources on the module both kernel drivers have to be loaded properly. User space does not need to use the WiFi component, but the WiFi kernel driver must be ready to let Bluetooth work. 2 hours ago, CryBaby said: I see no info on NVRAM for uart based devices. The Wifi component is attached via sdio and the driver will request the firmware and the nvram like the bluetooth driver. Look at the output of "dmesg" after boot up to see if something is missing. 0 Quote
CryBaby Posted July 18, 2020 Posted July 18, 2020 WiFi seems to be fully functional. There is an error about p2p but I don't think it is significant. $ bluetoothctl devices No default controller available $ hciconfig -a hci0: Type: Primary Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:14 acl:0 sco:0 commands:2 errors:0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DH1 HV1 Link policy: Link mode: SLAVE ACCEPT I think there's a way to go before I need to worry about 'features'. I am only really interested in HID devices anyway. $ dmesg | grep -iE "bluetooth|hci|brcm|uart|firmware|patch" [ 13.026900] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 13.336492] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 13.999486] Bluetooth: Core ver 2.22 [ 13.999624] Bluetooth: HCI device and connection manager initialized [ 13.999648] Bluetooth: HCI socket layer initialized [ 13.999661] Bluetooth: L2CAP socket layer initialized [ 13.999692] Bluetooth: SCO socket layer initialized [ 14.453847] Bluetooth: HCI UART driver ver 2.3 [ 14.453869] Bluetooth: HCI UART protocol H4 registered [ 14.453873] Bluetooth: HCI UART protocol BCSP registered [ 14.454015] Bluetooth: HCI UART protocol LL registered [ 14.454060] Bluetooth: HCI UART protocol ATH3K registered [ 14.454149] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 14.454436] Bluetooth: HCI UART protocol Intel registered [ 14.454792] Bluetooth: HCI UART protocol Broadcom registered [ 14.454877] Bluetooth: HCI UART protocol QCA registered [ 14.454883] Bluetooth: HCI UART protocol AG6XX registered [ 14.454943] Bluetooth: HCI UART protocol Marvell registered [ 14.455439] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator [ 14.455589] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator [ 15.450901] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 15.473035] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d [ 16.742840] Bluetooth: hci0: command 0xfc18 tx timeout [ 24.806758] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 24.806771] Bluetooth: hci0: Failed to set baudrate [ 26.268609] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 26.268621] Bluetooth: BNEP filters: protocol multicast [ 26.268649] Bluetooth: BNEP socket layer initialized [ 26.923039] Bluetooth: hci0: command 0x0c03 tx timeout [ 35.046796] Bluetooth: hci0: BCM: Reset failed (-110) [ 36.166697] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 36.185858] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 What is missing is the lines github says indicate a successful firmware load: Bluetooth: hci1: BCM: chip id 63 Bluetooth: hci1: BCM20702A Bluetooth: hci1: BCM20702A1 (001.002.014) build 0000 Bluetooth: hci1: BCM20702A1 (001.002.014) build 1467 Bluetooth: hci1: Broadcom Bluetooth Device 0 Quote
usual user Posted July 19, 2020 Posted July 19, 2020 I agree with your analysis, something goes wrong with the hci initialization. What worries me are these lines: 16 hours ago, CryBaby said: [ 16.742840] Bluetooth: hci0: command 0xfc18 tx timeout [ 24.806758] Bluetooth: hci0: BCM: failed to write update baudrate (-110) [ 24.806771] Bluetooth: hci0: Failed to set baudrate Since the driver already works in many other situations, my suspicion is again focused on the board-specific configuration. Just to rule this out, there are no more user space services (with brcm_patchram_plus, hciattach, ...) that might conflict (e.g do some reset) with kernel-mode hci initialization? They are no longer needed with the new mode. Because the user space tools did not rely on the bluetooth DT node (they did there own thing) maybe there is still something not set up properly. Oh, one more idea, can you boot without any overlays. To rule out they make bluetooth non working by pull conflicting configuration. 16 hours ago, CryBaby said: What is missing is the lines github says indicate a successful firmware load: With "strings bcm20710a1.hcd | grep BCM" you can check which version string to expect. 0 Quote
usual user Posted July 19, 2020 Posted July 19, 2020 Just out of curiosity I took a look at the ap6210 directory on my NanoPC-T4 image: ap6210/bcm20710a1.hcd ap6210/bd_addr.txt ap6210/fw_bcm40181a2_apsta.bin ap6210/fw_bcm40181a2.bin ap6210/fw_bcm40181a2_p2p.bin ap6210/nvram_ap6210.txt ap6210/nvram_apxxxx.txt ap6210/nvram.txt I see they are not only carrying the bluetooth firmware but also wifi firmware and its companion nvram. I don't know where your used ones are origination from but to rule out this special versions are required, let's put them in place. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin and create a symlink (ln --symbolic /lib/firmware/ap6210/fw_bcm40181a2.bin /lib/firmware/brcm/brcmfmac43362-sdio.bin). I don't know if you're using only the generic name (brcmfmac43362-sdio.bin.txt) for nvram. If so, let's do it the proper way. 1. Temporarily rename /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt 2. Reboot and check dmesg for which <nvram>.txt is being searched. First attempt will try a board specific one, second attempt will try brcmfmac43362-sdio.bin.txt. We are interested in the name of the board specific one. Copy over ap6210/nvram.txt to /lib/firmware/brcm/brcmfmac4356-sdio.<specific name>.txt With board specific name at least one <nvram>.txt for each board can coexist in the searched directory. And yes, in theory, every board needs a specific one. Falling back to the generic can work, but can break as soon as the generic one changes. One doesn't fit them all. Now reboot and check if this has changed anything regarding Bluetooth. 0 Quote
CryBaby Posted July 19, 2020 Posted July 19, 2020 I thought I'd better start with a fresh install. Armbian_20.05.4_Cubietruck_focal_current_5.4.45_desktop.img same as before. I set up locale and other basics using armbian-config. I disabled the desktop and installed bluetooth. I did not install full firmware or do an apt upgrade. I didn't mess with the firmwares at all. After the second boot I get this: $ dmesg | grep -iE "bluetooth|bcm|brcm|uart|firmware" [ 14.107368] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 14.124398] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt failed with error -2 [ 14.124415] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt [ 14.971356] Bluetooth: Core ver 2.22 [ 14.971491] Bluetooth: HCI device and connection manager initialized [ 14.971517] Bluetooth: HCI socket layer initialized [ 14.971528] Bluetooth: L2CAP socket layer initialized [ 14.971560] Bluetooth: SCO socket layer initialized [ 15.559057] Bluetooth: HCI UART driver ver 2.3 [ 15.559071] Bluetooth: HCI UART protocol H4 registered [ 15.559075] Bluetooth: HCI UART protocol BCSP registered [ 15.577995] Bluetooth: HCI UART protocol LL registered [ 15.578005] Bluetooth: HCI UART protocol ATH3K registered [ 15.578095] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 15.578343] Bluetooth: HCI UART protocol Intel registered [ 15.578594] Bluetooth: HCI UART protocol Broadcom registered [ 15.578653] Bluetooth: HCI UART protocol QCA registered [ 15.578657] Bluetooth: HCI UART protocol AG6XX registered [ 15.578728] Bluetooth: HCI UART protocol Marvell registered [ 15.579197] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator [ 15.579343] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator [ 16.003897] Bluetooth: hci0: BCM: chip id 63 [ 16.004556] Bluetooth: hci0: BCM: features 0x07 [ 16.007117] Bluetooth: hci0: BCM20702A [ 16.007139] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000 [ 16.007337] bluetooth hci0: Direct firmware load for brcm/BCM20702A1.hcd failed with error -2 [ 16.007349] bluetooth hci0: Falling back to sysfs fallback for: brcm/BCM20702A1.hcd [ 16.498239] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 17.197704] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 17.202654] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43362/1 wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d [ 17.232956] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1.hcd not found [ 27.449547] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 27.449560] Bluetooth: BNEP filters: protocol multicast [ 27.449606] Bluetooth: BNEP socket layer initialized [ 36.327143] ieee80211 phy0: brcmf_p2p_create_p2pdev: timeout occurred [ 36.340517] ieee80211 phy0: brcmf_cfg80211_add_iface: add iface p2p-dev-wlan0 type 10 failed: err=-5 [ 679.526274] Bluetooth: RFCOMM TTY layer initialized [ 679.526315] Bluetooth: RFCOMM socket layer initialized [ 679.526375] Bluetooth: RFCOMM ver 1.11 This is pretty much what I had before, except the RFCOMM is new. $ rfkill ID TYPE DEVICE SOFT HARD 0 bluetooth hci0 unblocked unblocked 1 wlan phy0 unblocked unblocked $ bluetoothctl devices $ bluetoothctl list Controller 08:A7:A4:C6:5D:A5 truck1 [default] $ hciconfig -a hci0: Type: Primary Bus: UART BD Address: 08:A7:A4:C6:5D:A5 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:1926 acl:0 sco:0 events:87 errors:0 TX bytes:3896 acl:0 sco:0 commands:87 errors:0 Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: SLAVE ACCEPT Name: 'truck1' Class: 0x0c0000 Service Classes: Rendering, Capturing Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x1000 LMP Version: 4.0 (0x6) Subversion: 0x220e Manufacturer: Broadcom Corporation (15) This does look like it is working, despite not finding the firmware. $ bluetoothctl Agent registered [CHG] Controller 08:A7:A4:C6:5D:A5 Pairable: yes [bluetooth]# scan on Discovery started [CHG] Controller 08:A7:A4:C6:5D:A5 Discovering: yes [bluetooth]# It doesn't find my device (a Magicsee R1 minijoystick thingy which works with my Deban laptop and Android phone). Might be a bit run down, I'll charge it up while I go for lunch and try again later. 0 Quote
joaofl Posted July 19, 2020 Posted July 19, 2020 Nice that you got it working, at least once. I actually also got it working a couple of time, but it would go fail to reset again after a reboot. I still did not find the time to look deeper into it. Ill see if I find the time this week. I also manged to get the firmware loaded, but it almost always will fail to reset. I still believe it has to do with some additional pins that have to be toggled to reset the bt module. Have to look at the schematics in one hand, and device trees in the other to see if things are mapped properly. Looking back at the legacy device tree (in which it use to work), may also give us a hint. 0 Quote
CryBaby Posted July 19, 2020 Posted July 19, 2020 It still doesn't find my device even with a full charge and it sitting on top of the cubietruck. I did an apt upgrade and reboot. Now there is no bluetooth controller again. The RFCOMM messages are gone too. Either the upgrade broke something or there is an element of luck involved. 0 Quote
CryBaby Posted July 19, 2020 Posted July 19, 2020 A cold reboot and the controller is back, and the RFCOMM messages. It still does not see my device though. 0 Quote
joaofl Posted July 20, 2020 Posted July 20, 2020 It seems that there is luck involved. If you read on that patch available you see that: https://github.com/phelum/CT_Bluetooth 0 Quote
usual user Posted July 20, 2020 Posted July 20, 2020 Studying the provided logs gives some clues. After a fresh install I guess there are /lib/firmware/brcm/brcmfmac43362-sdio.bin and /lib/firmware/brcm/brcmfmac43362-sdio.bin.txt in place. With this, the wifi driver get loaded and with no /lib/firmware/brcm/BCM20702A1.hcd no BT firmware upload does take place. The embedded BT firmware in brcmfmac43362-sdio.bin get used and the BT host interface via uart is working. Because the embedded firmware most probably does not match the BT hardware it has to be updated by BCM20702A1.hcd for proper operation. So we are back to find out why this is failing. The only relevant binding in the DT is this line: shutdown-gpios = <&pio 7 18 GPIO_ACTIVE_HIGH>; /* PH18 */ For a test let us remove it from the dtb. Copy the original sun7i-a20-cubietruck.dtb to sun7i-a20-cubietruck.dtb.orig at your workbench. Disassemble the dtb (dtc -I dtb sun7i-a20-cubietruck.dtb.orig > sun7i-a20-cubietruck.dts). Use your preferred text editor to remove the "shutdown-gpios = ..." line at the bluetooth node in the sun7i-a20-cubietruck.dts. Compile the dtb again (dtc -I dts sun7i-a20-cubietruck.dts > sun7i-a20-cubietruck.dts) Now replace sun7i-a20-cubietruck.dtb at the boot location with this one and reboot. This should now be able to upload BCM20702A1.hcd and make BT working to some extent. Since there is no longer any way to reset the BT, this only works after a power cycle, a warm reboot fails. Can you also try the wifi firmware in /lib/firmware/ap6210/ as described above? Because the version has a newer time stamp (date: Mon 2014-03-10 15:00:57 CST) than the firmware you are using. Now that I know the board specific nvram name I just discovered linux-firmware is already carrying a brcmfmac43362-sdio.cubietech,cubietruck.txt. It is identical to the nvram_ap6210.txt except the "macaddr=" parameter. But also the brcmfmac43362-sdio.bin has a newer time stamp (Date: Wed 2018-05-16 23:44:07 CDT). Maybe this one is worth a try also. 0 Quote
CryBaby Posted July 20, 2020 Posted July 20, 2020 I'll give it a go when I get back from work in about 9 hours. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.