Cubietruck/Bluetooth

Given that you see this in dmesg:

sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A

You can upload the firmware and activate the hci device like that:

./brcm_patchram_plus -d  --patchram /lib/firmware/ap6210/bcm20710a1.hcd --enable_hci --bd_addr 11:22:33:44:55:66 --no2bytes --tosleep 1000 /dev/ttyS1

You will see lots of hex dumps flying through the screen and at the end:

received 7
04 0e 04 01 03 0c 00
writing
01 01 fc 06 66 55 44 33 22 11
received 7
04 0e 04 01 01 fc 00
Done setting line discpline

The program doesn't detach itself - goes into infinite sleep. Must investigate why.

 The reason it doesn't detach is because of the --enable_hci flag.
 The program holds the tty open and enables bluetooth line discipline on the tty.
 The alternative is to remove the flag and use hciattach.

Confirm the device has been created:

root@cubietruck:~# hcitool dev
Devices:
        hci0    11:22:33:44:55:66
root@cubietruck:~# hciconfig -a
hci0:   Type: BR/EDR  Bus: UART
        BD Address: 11:22:33:44:55:66  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING PSCAN 
        RX bytes:4479 acl:66 sco:0 events:130 errors:0
        TX bytes:3593 acl:65 sco:0 commands:51 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: 'cubietruck-0'
        Class: 0x620100
        Service Classes: Networking, Audio, Telephony
        Device Class: Computer, Uncategorized
        HCI Version: 4.0 (0x6)  Revision: 0x1000
        LMP Version: 4.0 (0x6)  Subversion: 0x220e
        Manufacturer: Broadcom Corporation (15)

You might also need to preload bluetooth and hci-uart modules.

The program can be downloaded from https://code.google.com/p/broadcom-bluetooth/ The firmware can be grabbed from various places, e.g. cubietech images.

Update

There's been some complaints about the results being irreproducible. It is true that sometimes the firmware fails to load. And if it failed once, you most likely won't be able to activate the chip until next reboot (fixme: Someone more competent, explain how to reset the chip circuitry).

 Reset the chip by setting the BT-REST GPIO pin to 0.

I have the following modules loaded before uploading the firmware:

g2d_23 37275 2 - Live 0xbf16e000
rfcomm 57752 14 - Live 0xbf157000
bnep 13796 2 - Live 0xbf14f000
hci_uart 23588 1 - Live 0xbf144000
bluetooth 264130 31 hidp,rfcomm,bnep,hci_uart, Live 0xbf0ef000
sunxi_cedar_mod 9600 0 - Live 0xbf0e8000
snd_hwdep 5278 0 - Live 0xbf0e3000
snd_usbmidi_lib 17980 0 - Live 0xbf0da000
snd_rawmidi 18863 1 snd_usbmidi_lib, Live 0xbf0d0000
mali_drm 2533 2 - Live 0xbf0c4000
mali 224497 1 - Live 0xbf07d000
drm 208545 3 mali_drm, Live 0xbf034000
disp_ump 788 0 - Live 0xbf030000
ump 50814 6 mali,disp_ump, Live 0xbf01d000
lcd 3693 0 - Live 0xbf019000 
sunxi_gmac 30577 0 - Live 0xbf00c000
pwm_sunxi 9138 0 - Live 0xbf005000
rtc_sun4i 5440 0 - Live 0xbf000000

After uploading the firmware I do:

modprobe hidp
hidd --server
hciconfig hci0 up

This is probably not the cleanest way to do things, but I've been able to use a e.g. BT keyboard for a week long without any trouble.

Update 2

There seems to be missing gpio configuration to allow firmware download. Re: Debian sd/nand/sata deploying bluetooth firmware

 PH09 is for enabling WiFi. Not relevant here.

Update 3

There are two GPIO pins that are significant here. AP6210 pin 34 is BT-REST and is connected to GPIO pin PH18. AP6210 pin 6 is BT-WAKE and is connected to GPIO pin PH24. I've found that setting PH24 to 1 and then toggling PH18 (0 then 1) is required before loading the firmware using the Broadcom program. Changing the program to wait for CTS before sending also helps avoid hangs. This should be done by manually checking for CTS rather than using the RTSCTS ioctl option. Because the connection to the AP6210 is a null-modem link, RTS should be used by the program to indicate that it is ready to receive rather than it wants to send. So the modified program checks for CTS before sending and sets RTS while awaiting a reply. There are details in the link mentioned above.

I suggest that the best place to set the pins and load the firmware is in the "start" section of the /etc/init.d/bluetooth file before it starts the daemons. I'm currently doing this and while not bullet-proof it does seem as reliable as any other approach. One change from the Broadcom suggested command to run patchram is that I do not use --enable_hci. This leaves the link in raw serial mode and is probably what hciattach expects. hciattach will set the line discipline when attaching the device.

If you want the bluetooth script to attach the uart automatically, create the file /etc/bluetooth/uart and add the line :

 /dev/ttyS1 any

The script looks for the file and uses the line as parameters for hciattach.