CryBaby

Nah, using brcmfmac43362-sdio.bin and brcmfmac43362-sdio.cubietech,cubietruck.txt from linux-firmware with no hcd gives a (non-functioning) controller on cold boot only. Adding in ap6210/bcm20710a1.hcd gives no controller. Also, none of the 54 hcd files from github match ap6210/bcm20710a1.hcd I don't know what to try next.

I have the same one: /lib/firmware$ strings ap6210/fw_bcm40181a2.bin | grep 43362 43362a2-roml/sdio-g-pno-pktfilter-keepalive-wapi-wme-p2p-*unknown* Version: 5.90.195.0 CRC: b99a439d Date: Mon 2014-03-10 15:00:57 CST /lib/firmware$ ls -la brcm/brcmfmac43362* lrwxrwxrwx 1 root root 27 Jul 21 07:05 brcm/brcmfmac43362-sdio.bin -> ../ap6210/fw_bcm40181a2.bin -rw-r--r-- 1 root root 1121 Jul 20 21:15 brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt $ dmesg | grep -iE "bluetooth|bcm|brcm|uart|firmware" [ 12.799205] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for c

I removed the bluetooth stanza from the dt. Installed CT_Bluetooth and rebuilt the binaries. Set it to use /dev/ttyS2 and the systemd service from here. I had to link the hcd from ap6210/ to brcm/ to start the brcm40183-patch.service then I got a controller: $ sudo systemctl status bluetooth ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-07-22 20:54:40 CST; 5s ago Docs: man:bluetoothd(8) Main PID: 1938 (bluetoothd) Status: "Ru

My phone is not detected and it doesn't detect the cubietruck.

Using ap6210/nvram_ap6210.txt loses the controller again. Using ap6210/nvram.txt and the newer brcmfmac43362-sdio.bin from linux-firmware has a controller after a cold boot but not after a warm boot. No device detected. $ dmesg | grep -iE "bluetooth|bcm|brcm|uart|firmware" [ 12.866616] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 13.871351] Bluetooth: Core ver 2.22 [ 13.871648] Bluetooth: HCI device and connection manager initialized [ 13.871674] Bluetooth: HCI socket layer initialized [ 13.871688] Bluetooth: L2CAP socket layer initia

Removing the line from the dtb gives me a new line in the log: [ 14.709455] hci_uart_bcm serial0-0: No reset resource, using default baud rate But there are no RFCOMM messages and no bt controller after two cold boots. Next I moved the old firmware and NVRAM and linked the new firmware: $ dmesg | grep -iE "bluetooth|bcm|brcm|uart|firmware" [ 12.781584] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43362-sdio for chip BCM43362/1 [ 12.819250] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43362-sdio.cubietech,cubietruck.txt failed with error -2 [ 12.81

I'll give it a go when I get back from work in about 9 hours.

A cold reboot and the controller is back, and the RFCOMM messages. It still does not see my device though.

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.

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/brc

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 'featu

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: I haven't tested the WiFi at all so I'll do that. I see no info on NVRAM for uart based devices.

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

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

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