From: Steven Saunderson <essat2...@gmail.com> Sent: Saturday, 21 February 2015, 6:06 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel My bluetooth testing is to a mobile phone for wireless broadband. I haven't tested any other bluetooth functions.
Thanks for confirming radio communication works. My project involves Bluetooth so it is good to know that when I start working on using mainline the end goal is achievable. Although it involves A2DP so need to get the audio side figured out too. I had read clk_out_a from the AllWinner system on chip was needed and that there was a problem with this getting set up in the DTS and I thought this could have an effect on frequency stabilisation on the Bluetooth radio. The maximum UART speed is stated to be 4Mbps in the datasheet. Have you got as far as using the highest rate and if so when do you switch over to using it? The BT_WAKE pin seems irrelevant to me. After reading the datasheet I'm setting it low now. Thanks for confirming that theory can be discounted. If the AP6210 is not a perfect clone of the 20710 it might default to SPI mode if CTS is negated at the end of the reset pulse. I think this CTS theory is more plausible than my previous suggestion of noise on the TX line. My understanding is AMPAK package Broadcom's ICs vertically in one package as a System in Package (SiP), but don't get involved in IC design or production. So I don't think it would be a "clone" as such. I was thinking of creating a separate section on our Bluetooth wiki page for Broadcom with links to the tools, firmware, etc. and then referring to that section from the AP6210 section. So the AP6210 section only has specific implementation details while the general BCM20710 stuff is in a different section. Page 29 of the BCM20710 datasheet gives the HCI transport detection procedure. Step 3 there states the chip waits for CTS_N to be set to zero before selecting UART, otherwise it just waits. I guess that is the section you were referring to. So it could be CTS needs to be de-asserted after a reset otherwise the chip just waits. I'll keep testing and post details on the linux-sunxi page when I'm sure my new procedure is correct. That's great. Thanks for taking the time to keep us posted. Very useful. 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.
