November 15, 2019, 11:04:33 am

News:

Have you visited the Allwinner Chipset wiki? - http://linux-sunxi.org/


Debian sd/nand/sata image with onboard wifi and bluetooth

Started by DomoJimbo, April 28, 2014, 05:42:25 am

Previous topic - Next topic

DomoJimbo

Hi all,

All is in the title, I am looking to a server debian image for my CubieTruck, on which wifi and bluetooth is working.

Are you aware of such image ?

I would like to ba able to put it on a sd to test, then on Nand or Sata.

Thanks !

This one looks good, but bluetooth not working http://www.cubieforums.com/index.php?topic=1275.0

slovenia

Quote from: DomoJimbo on April 28, 2014, 05:42:25 am
Hi all,

All is in the title, I am looking to a server debian image for my CubieTruck, on which wifi and bluetooth is working.

Are you aware of such image ?

I would like to ba able to put it on a sd to test, then on Nand or Sata.

Thanks !

This one looks good, but bluetooth not working http://www.cubieforums.com/index.php?topic=1275.0


Problem is in driver / firmware for on-board Bluetooth chip. All Cubietruck images (if they support WIFI/BT chip) uses the same driver. We are waiting long for an update :(

If you need BT right now than get some USB BT dongle. This image is "USB Bluetooth plug and play". (if you won't use some rare chipset)

ADD: Someone could said that BT is working ... in case you want to play ... read this.
Debian and Ubuntu images with kernel 3.4.110, 4.3.3, 4.4
http://www.armbian.com

KoofyKoof

I can confirm that I 'once' got bluetooth working fine with keyboard, mouse and heaphones


phelum

Quote from: slovenia on April 28, 2014, 06:03:05 am

Problem is in driver / firmware for on-board Bluetooth chip. All Cubietruck images (if they support WIFI/BT chip) uses the same driver. We are waiting long for an update :(

If you need BT right now than get some USB BT dongle. This image is "USB Bluetooth plug and play". (if you won't use some rare chipset)

ADD: Someone could said that BT is working ... in case you want to play ... read this.


Hi,

There is a kernel patch <github.com/EddyBeaupre/ap6210>; that helps with wifi.  Wifi supports both client mode and host mode with hostapd.  The bluetooth firmware loading patch in the link above works but I had to make some changes to get it to work on my CT.  The chip has two wake-up pins and a reset pin and I added these to the GPIO pins in script.bin so I can control them.  Before loading the firmware (using the program in the link above) I make sure the two wake-up ins are set and also I toggle the reset pin.  Also, I had to change the program so it waits briefly rather than waiting for a response when the start download command is issued.

I can provide further details if anybody is interested.

Cheers,
Steven

slovenia

Quote from: phelum on June 26, 2014, 02:09:44 am
Quote from: slovenia on April 28, 2014, 06:03:05 am

Problem is in driver / firmware for on-board Bluetooth chip. All Cubietruck images (if they support WIFI/BT chip) uses the same driver. We are waiting long for an update :(

If you need BT right now than get some USB BT dongle. This image is "USB Bluetooth plug and play". (if you won't use some rare chipset)

ADD: Someone could said that BT is working ... in case you want to play ... read this.


Hi,

There is a kernel patch <github.com/EddyBeaupre/ap6210>; that helps with wifi.  Wifi supports both client mode and host mode with hostapd.  The bluetooth firmware loading patch in the link above works but I had to make some changes to get it to work on my CT.  The chip has two wake-up pins and a reset pin and I added these to the GPIO pins in script.bin so I can control them.  Before loading the firmware (using the program in the link above) I make sure the two wake-up ins are set and also I toggle the reset pin.  Also, I had to change the program so it waits briefly rather than waiting for a response when the start download command is issued.

I can provide further details if anybody is interested.

Cheers,
Steven


Thanks.

I tested the patch from Eddy but run into some troubles (probably compiler related). I have to do it again and compare if there is any difference to default one: bcmdhd. Generally I have no problems regarding WiFi - using it in Access Point mode daily. There are some errors sometimes in the log but it does not affect functionality. I agree that it should be better polished.

In the mean time we manage to find out how properly load BT firmware. It's not full bullet-proof. Sometime loading fails and you need to restart the device.

If your solution is acting better than this, please share.
Debian and Ubuntu images with kernel 3.4.110, 4.3.3, 4.4
http://www.armbian.com

castalla

I find pairing and connecting bt audio devices very hit and miss. 

Does anyone have a working script or set of commands to carry out reliable pairing?

phelum

Quote from: slovenia on June 26, 2014, 03:56:52 am

In the mean time we manage to find out how properly load BT firmware. It's not full bullet-proof. Sometime loading fails and you need to restart the device.

If your solution is acting better than this, please share.


I think we're both on the same path here.  I don't know enough to modify the kernel so I added the three GPIO pins to the section in script.fex.

[gpio_para]
gpio_used = 1
gpio_num = 70
.....
gpio_pin_68 = port:PH18<1><default><default><0>
gpio_pin_69 = port:PH24<1><default><default><0>
gpio_pin_70 = port:PH09<1><default><default><1>


The scripts to prepare the device are

#!/bin/bash

killall -q hciattach 2&1> /dev/null

# 0 on the reset pin resets the device
#
if [ ! -x /sys/class/gpio/gpio68_ph18 ] ; then
  echo -n 68  > /sys/class/gpio/export
  echo -n out > /sys/class/gpio/gpio68_ph18/direction
fi
echo -n 0   > /sys/class/gpio/gpio68_ph18/value
echo -n 1   > /sys/class/gpio/gpio68_ph18/value

# 0 on the wake pin forces the device to be active
#
if [ ! -x /sys/class/gpio/gpio69_ph24 ] ; then
  echo -n 69 > /sys/class/gpio/export
  echo -n out > /sys/class/gpio/gpio69_ph24/direction
fi
echo -n 0   > /sys/class/gpio/gpio69_ph24/value

# 1 on the reg-on pin enables the device
#
if [ ! -x /sys/class/gpio/gpio70_ph9 ] ; then
  echo -n 70 > /sys/class/gpio/export
  echo -n out > /sys/class/gpio/gpio70_ph9/direction
fi
echo -n 1   > /sys/class/gpio/gpio70_ph9/value

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

#!/bin/bash
NAME=$(cat /etc/hostname)
NAME='Cubietruck'
hciattach /dev/ttyS1 any &> /dev/null || exit 1
hciconfig hci0 up || exit 2
hciconfig hci0 name $NAME || exit 3
hciconfig hci0 piscan || exit 4
exit 0


I've uploaded the patchram source to http://phelum.net/temp/brcm_patchram_plus.c.  The program waits for CTS before sending and doesn't expect a reply to the start download command. also waits briefly after sending the start download command and getting a reply.  Then it starts sending the firmware.

I'm currently running the scripts from /etc/rcS.d.

I'll add some debug code to the program to ascertain why I'm not getting a response to the start download command.  Also, I'll check your code because I suspect it will be better than my approach.

Cheers,
Steven


phelum

June 26, 2014, 08:08:19 pm #8 Last Edit: June 28, 2014, 01:48:29 am by phelum
Quote from: rose28357 on June 26, 2014, 09:46:03 am
If we have a valid solution we should document it at sunxi wiki.
http://linux-sunxi.org/Cubietruck/Bluetooth


I agree.  I've tried to start an account there and am still awaiting my activation e-mail.  However, I know little about Linux and am cautious about posting to such a public page.  Also, my solution here is far from elegant but it does seem to work and might help others to produce a better effort.

The firmware load problems seem to stem from unreliable loading of the IC pins and the need to wait briefly when starting the download.  My kernel (3.4.90) has the AP6210 patch for wifi and I find that the bluetooth firmware load should be done in the /etc/rcS startup phase.  My init and load patch requires a change to script.bin.

Change to script.bin

[gpio_para]
gpio_used = 1
gpio_num = 70
...
gpio_pin_68 = port:PH18<1><default><default><0>
gpio_pin_69 = port:PH24<1><default><default><0>
gpio_pin_70 = port:PH09<1><default><default><1>


The patch is run from /etc/rcS.d/@S11bcbt-prep and I think the position in the rcS list is important.
I now run the patch in the "start" section of the etc/init.d/bluetooth script just before it starts the daemons.

The patch is

if [ ! -x /sys/class/gpio/gpio69_ph24 ] ; then
  echo -n 69 > /sys/class/gpio/export
  echo -n out > /sys/class/gpio/gpio69_ph24/direction
fi
echo -n 1   > /sys/class/gpio/gpio69_ph24/value

# 0 on the reset pin resets the device
#
if [ ! -x /sys/class/gpio/gpio68_ph18 ] ; then
  echo -n 68  > /sys/class/gpio/export
  echo -n out > /sys/class/gpio/gpio68_ph18/direction
fi
echo -n 0   > /sys/class/gpio/gpio68_ph18/value
echo -n 1   > /sys/class/gpio/gpio68_ph18/value

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



My version of the patchram program has been modified to wait for CTS and pause briefly before sending the first firmware frame (after the start download frame).  It also checks that the response to every frame is correct.  The program source is at http://phelum.net/temp/brcm_patchram_plus.c.  Note that I don't use the --enable_hci option in the patchram command.

The init & load patch seems reliable and can be re-run without booting.  So I think I've corrected the hanging problems that have been reported by other people.  What I need to learn is enough so I can access and control the GPIO pins without the modified script.bin.

Previously (when running the patch before the bluetooth startup) I was doing the hciattach in the above script.  This would fail sometimes and I'd get tx timeouts on the subsequent hciconfig commands.  Now I've removed this attach and config from the script and let the bluetooth service startup do it for me.  I created /etc/bluetooth/uart and the bluetooth startup uses it.

/etc/bluetooth/uart

/dev/ttyS1 any


If anybody can tell me how a C program can control GPIO pins I could add the code to the patchram program.  I'd like to do this without needing the changes to script.bin.

Cheers,
Steven

rose28357

Just for completion. There is an other simpler approach.
http://archlinuxarm.org/forum/viewtopic.php?t=7253

It uses
echo -n "" > /dev/ttyS1
to pull down the RTS line of the second UART low. With a low RTS line the parchram program runs flawless.

It will be used in the next aRuntu version.