No bluetooth with AP6212a under 4.11 Mainline

[esc]

I've just checked my orangepi board and can confirm that it receives same AA:AA:AA:AA:AA:AA without manual assignment. Are you saying manual assignment is not working?

[Larry Fox]

5 hours ago, esc said:

I've just checked my orangepi board and can confirm that it receives same AA:AA:AA:AA:AA:AA without manual assignment. Are you saying manual assignment is not working?

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)

 

[esc]

2 hours ago, Larry Fox said:

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  

I know it doesn't matter for your case since you've managed to get it up and running; but,"bdaddr" isn't a keyword, actual address should be the only non-option argument of the command: 

/usr/bin/hciattach /dev/ttyS3 bcm43xx 1500000 - 43:29:B1:55:01:01

 

What modified hciattach are you running? Is it with firmware patch uploading fix?

[Larry Fox]

7 hours ago, esc said:

I know it doesn't matter for your case since you've managed to get it up and running; but,"bdaddr" isn't a keyword, actual address should be the only non-option argument of the command: 

/usr/bin/hciattach /dev/ttyS3 bcm43xx 1500000 - 43:29:B1:55:01:01

 

What modified hciattach are you running? Is it with firmware patch uploading fix?

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.

[jerryn]

I have a nanopc-4.  Do you think an updated DTB file will be ailable in the repo soon ?