Until yesterday I used sun7i-a20-cubietruck.dtb generated from files supplied with the Linux 3.19.0-rc6 kernel. With this .dtb the Bluetooth UART is accessed via /dev/ttyS2. This is different from the 3.4 kernels which provide access via /dev/ttyS1.
Now I've generated a new .dtb using the latest files from https://github.com/wens/linux/blob/sunxi-next/arch/arm/boot/dts/ and with this .dtb the relevant UART (uart2) is accessed via /dev/ttyS1. This is a great improvement. It also means that my decisions based on the kernel level are incorrect. I've changed the scripts so they always use ttyS1 and will have to manually altered if required. I've updated my repository at https://github.com/phelum/CT_Bluetooth with these scripts and also the .dts and .dtb I'm using. The .dts generated from the files above didn't contain a clause enabling uart2 so I added such a clause to the end of the .dts before creating the .dtb. On Thursday, February 26, 2015 at 6:31:55 AM UTC+11, Al Thomas wrote: > > > Does anyone know the status of hardware flow control for UART on AllWinner > SoCs? > > Hi Al, I don't know about this and I'm not sure it would help anyway. I added CTS checking to my version of the Broadcom program last year when trying to fix the download problem. The only time I see CTS drop is immediately after a reset (BT_REST toggle) and immediately after sending an HCI_reset command. The standard Broadcom program has a parameter specifying the wait period after sending HCI_reset. So the standard program will probably work if the delay (e.g. --tosleep 5000) is specified in the command. The problem I see with any hardware or serial port flow control is that anything that uses CTS might also drive RTS. In the download case here we need RTS asserted continuously and this might not happen in any CTS-sensitive environment. It seems safer to me for the download program to drive RTS and whether this program reacts to CTS is another matter. This still leaves the issue with RTS and the BT_REST pulse. It should be possible to write a small program that opens the serial port, asserts RTS, applies the BT_REST pulse, and then closes after say 10ms. The standard download program could be run after this preparation step. Does this sound like a better approach ? Cheers, Steven -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
