Got bluetooth working on Cubietruck - proof of concept

[PLyttle]

In order to get bluetooth to work you first need to get ttyS1 to work.
The problem here is that the current kernel allows for only one uart and ttyS0 is already in use for debug terminal
recompiling the kernel with
$this->bbcode_second_pass_code('', 'CONFIG_SERIAL_8250_NR_UARTS=2
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
')
instead of 1 solves that problem. ttyS1 is now available:
$this->bbcode_second_pass_code('', '[ 1.465217] [uart]: serial probe 2 irq 35 mapbase 0x01c28800
[ 1.497099] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A
')
then preload the following modules:
$this->bbcode_second_pass_code('', 'bluetooth
hidp
rfcomm
bnep
hci_uart
')
in /etc/modules-load.d/bluetooth.conf.

then get the broadcom patchram plus utility here:
https://broadcom-bluetooth.googlecode.c ... 9ab.tar.gz

unpack and compile (just type make)
then (assuming you already have the firmware ap6210 in /usr/lib/firmware)
go read this page: http://linux-sunxi.org/Cubietruck/Bluetooth

now type
$this->bbcode_second_pass_code('', 'sudo systemctl start bluetooth
')

now type as root in the patchram directory (or put in your path somewhere)
$this->bbcode_second_pass_code('', './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')
I always need to Ctrl-C and do it again to make it work. The console goes dead, leave it be (Work for later...)

Open a second console and type
$this->bbcode_second_pass_code('', 'sudo bluetoothctrl
')you see your controller appear.
$this->bbcode_second_pass_code('', '[NEW] Controller 11:22:33:44:55:66 cubie [default]
[bluetooth]# show
Controller 11:22:33:44:55:66
Name: cubie
Alias: cubie
Class: 0x000000
Powered: no
Discoverable: no
Pairable: yes
UUID: PnP Information (...)
UUID: Generic Access Profile (...)
UUID: Generic Attribute Profile (...)
UUID: A/V Remote Control (...)
UUID: A/V Remote Control Target (...)
Modalias: usb:...
Discovering: no
[bluetooth]# ')
your bluetooth is working.

This is a proof of concept within the ARCH environment. There is more work to be done.

fave fun

LP

[WarheadsSE]

Nicely done.

[pepedog]

Similar hardware by Broadcom packaged here
https://github.com/archlinuxarm/PKGBUIL ... e-brcm43xx
Uses patchram too and might be an easy to adapt thing? Note it covers 2 chipsets

[PLyttle]

looks promising. I think I can make that working.

I guess I finally have to figure out how to use git in the right way

LP

[PLyttle]

pepedog, thanks a million for the pointer You've done most of the work already.

Adapting the scripts was a breeze, but two problems remain:

First I always needed to start the patchram program twice. The first time it halts on the first reset command to the broadcom chip. I found a workaround for it, but it is ugly.

I send
$this->bbcode_second_pass_code('', 'echo -e "\x01\x03\x0c\x00" > /dev/ttyS1
')
before the patchram command. This is the first reset command, which is ignored, but it simulates the unsuccessful first startup. And it works. Zarkwon knows why. If somebody knows where to find the loader protocol I'm interested.
I left the patchram program unmodified.

Second I have not located the chip ident in the /sys directory yet. So I can't check for a valid install.

EDIT: belay that, I'm using /sys/class/rfkill/*/name. One of them is the chip ident. One problem left to solve

Nevertheless, progress

LP

[PLyttle]

I think I know what happens.
On booting the Cubietruck the RTS of UART-2 is set high
Running patchram pulls RTS low when starting, but fails to transfer data. Closing the program leaves RTS low

Issuing the command $this->bbcode_second_pass_code('', 'echo -n "" > /dev/ttyS1') also pulls RTS low and leaves it low.

running patchram when RTS is initially low completes without problems.

External triggering of RTS also made patchram perform as expected.

I'm not clear on the underlying problem. There is some mention of a mandatory 8 clock cycle delay after setting the divisor latch registers in the UART in the A20 user manual, but just inserting a delay in patchram did not work. There are probably several ways to approach this, but I think that issuing the above command is the least invasive, so I'm inclined to leave it at that.

Conclusion: The Cubietruck bluetooth works, with available tools, drivers and firmware. Required is a Kernel config modification to enable the second UART, a systemd service and a startup script.

For who is interested:
Patchram can be obtained by installing the firmware-brcm43xx package.

the bcm40183 firmware is here: http://dl.cubieforums.com/patwood/ap6210.zip
it goes in /usr/lib/firmware

and these are the scripts, with thanks to pepedog, for doing most of the work:

/usr/lib/systemd/system/brcm40183.service
$this->bbcode_second_pass_code('', '[Unit]
Description=Load Broadcom bluetooth firmware
Before=bluetooth.service

[Service]
EnvironmentFile=/etc/conf.d/bcm40183
Type=oneshot
ExecStart=/usr/lib/systemd/scripts/start-brcm40183-patchram-plus
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
')
/usr/lib/systemd/scripts/start-brcm40183-patchram-plus
$this->bbcode_second_pass_code('', '#!/bin/sh

MAC_OPTIONS=""
if [ -z "$MAC_ADDR" ]; then
echo "MAC_ADDR in /etc/conf.d/bcm40183 not set, will use MAC set by device (expect this to be buggy)"
else
MAC_OPTIONS="--bd_addr $MAC_ADDR"
fi

# Selection for CubieTruck (CubieBoard 3)
if [ -n "$(cat /sys/class/rfkill/*/name | grep bcm40183)" ]; then
PORT=$(ls /sys/devices/platform/sunxi-uart.2/tty/)
echo -en "" > /dev/$PORT # pull down RTS on UART
HCD="ap6210/bcm20710a1.hcd"
EXTRA="--no2bytes --tosleep=1000"
/usr/bin/brcm_patchram_plus --patchram /usr/lib/firmware/$HCD --enable_hci $EXTRA $MAC_OPTIONS /dev/$PORT &
else
echo " No device Found."
exit 1
fi

for i in 1 2 3 4 5 ; do
b=$(hciconfig | grep UART | cut -d: -f1)
if [ -n "$b" ] ; then
hciconfig $b up
break
else
sleep $i
fi
done

exit 0
')

and optional: /etc/conf.d/bcm40183, modify to taste
$this->bbcode_second_pass_code('', 'MAC_ADDR=43:29:B1:55:01:01
')

be well...
LP