Larry Fox

I am running the patch identified in this repo as it has the don't change speed before FW update patch. One clue to what the right speed for the BT module needed to be came from doing: dmesg | grep tty and seeing 1c28c00.serial: ttyS3 at MMIO 0x1c28c00 (irq = 41, base_baud = 1500000) is a U6_16550A Nikolay patch; This has the binary file in it hciattach you can just replace yours with.. https://bugs.launchpad.net/snappy/+bug/1674509/+attachment/4854099/+files/bluez.tar.xz I did recompile Bluez to v5.48 but didn't see any positive benefit. What I have noticed is there are quite a lot of legacy apps and config files that no longer seem to be used. My goal is to finish getting this hci uart working and document the process. Digging deep into the device tree overlays on Armbian I can see RFKILL is associated with PG13, which would make sense if it worked. My novice experience level with the device tree unfortunately doesn't lead me to a path that would correct the reset line toggle I would have expected. rfkill_bt { compatible = "rfkill-gpio"; pinctrl-names = "default"; pinctrl-0 = <0x49>; reset-gpios = <0x14 0x6 0xd 0x0>; clocks = <0x1e>; clock-frequency = <0x8000>; rfkill-name = "sunxi-bt"; rfkill-type = "bluetooth"; }; bt_pwr_pin@0 { pins = "PG13"; function = "gpio_out"; linux,phandle = <0x49>; phandle = <0x49>; }; Ironically the DTB for the friendlyarm build has PG13 associated with I2S0 or I2S1 if I recall. Seems to me the problem of the reset line doesn't exist on that build by accident.

if I do something like this I will still get AA:AA:AA:AA:AA:AA /usr/bin/hciattach /dev/ttyS3 bcm43xx 1500000 bdaddr 43:29:B1:55:01:01 FYI, I was able to modify /etc/init.d/ap6212-bluetooth to include the startup scripts that would turn on PG13. I also modified the appropriate lines to change hciattach to the appropriate speed of 1500000 and it comes up with the bd addr found in /etc/default/ap6212. Also note, I no longer get the LSB firmware update error during boot that seems to be very common. I did add hci_uart and rfcomm to the /etc/modules file as well. The critical element appears to be the modified hciattach amongst many other things such as the firmware being in the right place. A little messy to figure out, but it got the job done. Interestingly there are a number of what appear to be legacy configuration files that are not being read. It would sure be nice to figure out how to fix that. Given that it's late, I don't have the bandwidth to see if I can make an end-to-end serial connection. That will wait until tomorrow when I can test rfcomm and sdptool. Below is where I am as of now available directly from boot. hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:29:B1:55:01:01 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:1354 acl:0 sco:0 events:58 errors:0 TX bytes:1825 acl:0 sco:0 commands:58 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: 'nanopiair' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.1 (0x7) Revision: 0x0 LMP Version: 4.1 (0x7) Subversion: 0x2209 Manufacturer: Broadcom Corporation (15)

Confirmed the same files are on a friendlyarm board as on my board now. I have seen mention of defining an env variable FIRMWARE_DIR. Doesn't seem to have any affect that I can tell. Note also tried to add a bdaddr to the hciattach command, no luck there. FYI the script sometimes fails the first time around but seems to be pretty solid on try two. Now to get all of this mess into a startup scenario where I can cold boot and have everything configured properly. Thanks for all your help! Still more than willing to try any suggestions. Larry

Well one step further and a small change has occurred, I see the baud rate change message on the first try. bcm43xx_init Failed to read local name, command failure Can't initialize device: Success or bcm43xx_init Patch not found, continue anyway Set Controller UART speed to 1500000 bit/s Initialization timed out. copied the patch to /etc/firmware and now get bcm43xx_init Failed to write reset command Can't initialize device: Success realized I needed a reboot and now get bcm43xx_init Patch not found, continue anyway Set Controller UART speed to 1500000 bit/s Device setup complete hciconfig hci0 hci0: Type: Primary Bus: UART BD Address: AA:AA:AA:AA:AA:AA ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:766 acl:0 sco:0 events:48 errors:0 TX bytes:2737 acl:0 sco:0 commands:48 errors:0 the BD address is bogus and will need to do some work to get the right profiles/class, etc registered. Now to make this something more manageable Larry

I have completed quite the diagnosis of this problem and I am still not seeing a result that gets me to a working BT Uart. Here are a few things that I have determined with my current linux build: ARMBIAN 5.65 stable Debian GNU/Linux 9 (stretch) 4.14.78-sunxi modified armbianEnv.txt to include uart3 (used on the nano pi neo air for BT) and param_uart3_rtscts=1 modified /etc/default/ap6212, changed port to PORT=ttyS3 added hci_uart to modules Updated Bluez to latest Installed hciattach patch, still getting "Initialization timed out." Still have an error loading the firmware as noted in ""systemctl status ap6212-bluetooth.service" Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: Initialization timed out. Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: bcm43xx_init Nov 28 15:13:19 nanopiair ap6212-bluetooth[2179]: Can't get device info: No such Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Control process Nov 28 15:13:19 nanopiair systemd[1]: Failed to start LSB: Patch firmware for ap -- Subject: Unit ap6212-bluetooth.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit ap6212-bluetooth.service has failed. -- -- The result is failed. Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Unit entered fai Nov 28 15:13:19 nanopiair systemd[1]: ap6212-bluetooth.service: Failed with resu Some obvious items worthy of note. I can remove the SD card with this build of linux and replace it with the Friendlyarm build and BT works like a champ. As such the hardware is functional. I also notice that PG13 is currently low on the Armbian build whereas it is high on the Friendlyarm build. I have not probed into this more but this I/O does control BT Reset to the ap6212. I get the feeling that the gatekeeper to success is simply being able to talk to /dev/ttyS3 to move info back and forth to the ap6212. Regards, Larry

I tried the process as well to enable ttyS3 and although ttyS3 is there, the commands listed above do not work. I get the same message in the hciattach, bcm43xx_init Initialization timed out. Fundamentally all I would like to do is get hci_uart fired up. In a standard build for the NEO Air LTS Linux BE-BLUE 4.14.0 #2 SMP Wed Dec 13 15:15:38 CST 2017 armv7l armv7l armv7l GNU/Linux [ 19.331372] Bluetooth: Core ver 2.22 [ 19.331541] NET: Registered protocol family 31 [ 19.331550] Bluetooth: HCI device and connection manager initialized [ 19.331587] Bluetooth: HCI socket layer initialized [ 19.331606] Bluetooth: L2CAP socket layer initialized [ 19.331665] Bluetooth: SCO socket layer initialized [ 19.350794] Bluetooth: HCI UART driver ver 2.3 [ 19.350814] Bluetooth: HCI UART protocol H4 registered [ 19.350819] Bluetooth: HCI UART protocol BCSP registered [ 19.351002] Bluetooth: HCI UART protocol LL registered [ 19.351009] Bluetooth: HCI UART protocol ATH3K registered [ 19.351014] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 19.351252] Bluetooth: HCI UART protocol Intel registered [ 19.351480] Bluetooth: HCI UART protocol Broadcom registered [ 19.351488] Bluetooth: HCI UART protocol QCA registered [ 19.351492] Bluetooth: HCI UART protocol AG6XX registered [ 19.351496] Bluetooth: HCI UART protocol Marvell registered [ 43.777037] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 43.777055] Bluetooth: BNEP filters: protocol multicast [ 43.777093] Bluetooth: BNEP socket layer initialized [ 44.597084] Bluetooth: RFCOMM TTY layer initialized [ 44.597132] Bluetooth: RFCOMM socket layer initialized [ 44.597178] Bluetooth: RFCOMM ver 1.11 In the latest armbian (Debian stretch) I see below. Clearly HCI UART is not being loaded Linux nanopiair 4.14.65-sunxi #1 SMP Mon Aug 20 08:45:20 CEST 2018 armv7l GNU/Linux [ 14.579509] Bluetooth: Core ver 2.22 [ 14.579673] NET: Registered protocol family 31 [ 14.579682] Bluetooth: HCI device and connection manager initialized [ 14.579803] Bluetooth: HCI socket layer initialized [ 14.579828] Bluetooth: L2CAP socket layer initialized [ 14.579873] Bluetooth: SCO socket layer initialized