Ok, Managed to learn through my failures. I now have working backported drivers however something weird is going on. My process is as follows:
modprobe hci_uart modprobe Bluetooth echo "1" > /sys/class/rfkill/frkill0/state hciattach /dev/ttySAC0 bcm43xx 4000000 hciconfig hci0 up
But here is the weird part. If I do a hciconfig -a hci0 I get this
Look at the BD address, its a default value. If I go any further to start bluez I get a Bluetooth address mismatchCode:
hciconfig -a hci0 hci0: Type: BR/EDR Bus: UART BD Address: 43:34:B0:00:00:00 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:7419 acl:37 sco:0 events:151 errors:0 TX bytes:2834 acl:36 sco:0 commands:75 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: 'BCM4334B0 37.4MHz Class1.5 Samsung D2' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x40f LMP Version: 4.0 (0x6) Subversion: 0x410d Manufacturer: Broadcom Corporation (15)
I have no idea what is wrong with it, I am able to scan with the hcitool and get devices back and ping them with l2ping so the chip is working. Anyone have any ideas? Ive tried to set the address with hciattach with no luck
Boardcom chips have bluedroid support. I assume you are trying to test bluez. I didn't try other chips before. Other than the material already posted, there would be little to help.I suppose you had followed the bluetooth.c in your device tree. The sequence should init your chip properly.
The example from Bluez for Nexus4 might be a place for you to look into.
I remember, there is the program (something like bdAddrLoader) starting in init.mako.rc. I think it read a file in /efs (or similar partition) for the bdadress. Most of the devices share the same mac address from WiFi.
Take a look at your old device tree's init.<>.rc. See if there is similar code.