From: Steven Saunderson <essat2...@gmail.com>
 Sent: Friday, 20 February 2015, 1:50
 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
   Thanks for the .dts patch info.  I've updated my .dts but it doesn't help 
with the firmware load.  I haven't seen any mainline version of the AP6210 
driver.  Maybe it's not required.  At the moment I'm running the brcmfmac 
driver for wifi and just the standard bt-uart driver for BT.

OK, useful to know hci_uart is the kernel module to use here.


The good news is that bluetooth works with 3.19 once I've managed to load the 
firmware.  

I presume that is full radio communication, e.g. a bluetooth keyboard (HID 
profile) and not just communication with the controller over UART?


But I don't like my current hack with the BT_RESET pin.  I'll see if I can 
monitor the uart2 TX line before the port is opened.

I've done a bit of digging in the docs and have another theory - that BT_WAKE 
needs to be high.

Page 30 of the bluetooth chip manual ( 
http://dl.linux-sunxi.org/users/turl/20710-DS103-RDS.pdf ) says the default 
baud rate is 115200. So I assume that is the rate you are using.

Under the CubieTruck Bluetooth wiki page ( 
http://linux-sunxi.org/Cubietruck/Bluetooth ) I found in the Update 3 section: 
"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."
Then on page 20 of the chip manual "The polarity of this signal is software 
configurable and can be asserted high or low. By default, BT_WAKE is active-low 
(if BT-WAKE is low it requires the device to wake up or remain awake)."
So if BT_WAKE is zero then the chip is always on and I am thinking there is a 
conflict between BT_RESET and the power management. This is the story I 
imagine: BT_RESET is sent low and then high to initiate a reset but the power 
management doesn't allow the chip to sleep as part of the reset. Page 55 of the 
chip manual says sleep state is held for 4.2ms after reset.

I can't think of a reason to hold BT_WAKE at zero (always on). So maybe it 
should be 1 in the DTS then the boot script toggles the chip awake, resets the 
chip and loads the firmware.
You probably want to 
echo -n "" > /dev/ttyS1so RTS is low before uploading the firmware. See 
http://www.cubieforums.com/index.php/topic,2449.msg18834.html?PHPSESSID=usadn8lim7jp5ghh6rc22j31j7#msg18834
Hope that works.
Al
 
   

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to