Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Friday, February 27, 2015 at 12:19:48 PM UTC+11, Al Thomas wrote: > > > Do the 3.4 kernel and standard Broadcom program work together without the > restart program? If so then maybe the restart program should just be for > new kernels with DTS support. > > I've had trouble with the BT firmware download right from the start (Cubian 3.4.79 if I remember correctly). The standard response has always been reboot and try again. Hmmm. I'm running 3.4.103 now and the load still fails if I don't reset the chip first. The hassle with 3.4.x is that it requires a script.bin change and the bt.init script might need to be changed to the GPIO pin numbers correspond. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Thursday, 26 February 2015, 21:57 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth On Friday, February 27, 2015 at 1:36:43 AM UTC+11, Al Thomas wrote: Why do you use mmap to access the GPIOs and not write to the sysfs files from within the C program? mmap seems good because it avoids the indirection (and interface differences across kernel releases) imposed by the drivers. I can understand that many people might not like this kind of access. I didn't know the way of referencing GPIO pins had changed for later kernels. Looking at your https://github.com/phelum/CT_Bluetooth/blob/master/usr/local/bin/bt.init I understand now. I was only thinking that at some point using /proc/device-tree/ (or whatever interface this should be if this turns in to a kernel driver) to read the pins could be useful in the general sense. There was some discussion last year about placing those details as a sub-node of the UART in the DTS file:http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/248765.htmlhttp://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/247985.htmlThe Marvell Bluetooth driver has some DTS documentation:https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/btmrvl.txt Do the 3.4 kernel and standard Broadcom program work together without the restart program? If so then maybe the restart program should just be for new kernels with DTS support. Thanks for the insight into what you did with mmap. 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Friday, February 27, 2015 at 1:36:43 AM UTC+11, Al Thomas wrote: > > Why do you use mmap to access the GPIOs and not write to the sysfs files > from within the C program? > > mmap seems good because it avoids the indirection (and interface differences across kernel releases) imposed by the drivers. I can understand that many people might not like this kind of access. The brcm_bt_reset program can now be told to use a script rather than /dev/mem to reset the device. This is specified in the bt.load script. Thanks again for your suggestions here. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Thursday, 26 February 2015, 9:50 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth I've just added a brcm_bt_reset program to my repository https://github.com/phelum/CT_Bluetooth . This resets the BCM20710 and leaves it in UART-enabled mode as required by the download program. So now the download program (should be generic) doesn't have to call an initialise script (CubieTruck specific) and there is now some separation of the two tasks. It should be easy to modify the reset program for other platforms. That's very useful for me. Thanks. Why do you use mmap to access the GPIOs and not write to the sysfs files from within the C program? All the best, 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
I've just added a brcm_bt_reset program to my repository https://github.com/phelum/CT_Bluetooth . This resets the BCM20710 and leaves it in UART-enabled mode as required by the download program. So now the download program (should be generic) doesn't have to call an initialise script (CubieTruck specific) and there is now some separation of the two tasks. It should be easy to modify the reset program for other platforms. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Wednesday, 25 February 2015, 6:30 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. This could make things simpler. If you can configure the serial port for a null-modem environment then it might be possible to use the standard program. I had assumed it could be configured and that was the reason for suggesting stty crtscts -F /dev/ttyS2 A patch was posted back in May 2014 that added has-hw-flow-control to the DTS bindings:http://lists.openwall.net/linux-kernel/2014/05/28/673 It doesn't appear to have been applied:https://www.kernel.org/doc/Documentation/devicetree/bindings/serial/of-serial.txt There appears another patch renaming the documentation file from of-serial.txt to 8250.txt:https://lkml.org/lkml/2014/11/25/596That doesn't appear to have been applied. So maybe that is why 3.19 doesn't work as expected. Does anyone know the status of hardware flow control for UART on AllWinner SoCs? 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
> > On Wednesday, February 25, 2015 at 12:51:13 AM UTC+11, Al Thomas wrote: > > > > Host RTS must be asserted at the end of the reset pulse and for 30ms after > to get the device to assert its RTS (our CTS). Since I check for CTS > before sending this causes the program to time out. > > The timing is good to know. Does it still work if you wait 10ms after the > end of the reset pulse and then assert RTS for 20ms? If it does then it > suggests the controller needs a few millisecond to re-initialise, the > manual says 4.2ms of sleep occurs during initialisation, and then it needs > a sufficiently long pulse on its CTS as zero (host RTS asserted) for it to > recognise UART is the transport. > If CTS isn't low at the end of the reset pulse the device apparently doesn't react. Besides, any boot process that relied on a signal change at some precise point after the reset pulse would be inherently unreliable in a multi-tasking environment. I'm wondering if the GPIO script is necessary. The BCM20710 manual states > on p.29 "The CTS and RTS signals of the UART interface are used for BT wake > (CTS) and Host wake (RTS) functions in addition to their normal > function on the UART interface. Note that this applies for both H4 and H5 > protocols." So asserting RTS on the host will wake the controller (its CTS > goes low). This would mean the BT_WAKE GPIO would be unnecessary. > Yes, playing with BT_WAKE is probably insignificant. But toggling BT_REST is critical unless the device is already in UART mode. > Also the Broadcom tool sends an HCI reset command first. Could this be the > same kind of reset as the GPIO control line? > I don't think so. The firmware download is preceded and suceeded by HCI_reset. So HCI_reset doesn't clear the device RAM. But BT_REST powers off the device and I assume this will clear its RAM. > I think the host UART driver ( serial8250 ) should be dealing with the > handshaking. It is hopefully just a question of getting it configured > correctly at start up. > This could make things simpler. If you can configure the serial port for a null-modem environment then it might be possible to use the standard program. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Tuesday, 24 February 2015, 10:28 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth Today I've tested asserting and negating RTS at various times. Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out. The timing is good to know. Does it still work if you wait 10ms after the end of the reset pulse and then assert RTS for 20ms? If it does then it suggests the controller needs a few millisecond to re-initialise, the manual says 4.2ms of sleep occurs during initialisation, and then it needs a sufficiently long pulse on its CTS as zero (host RTS asserted) for it to recognise UART is the transport. I'm wondering if the GPIO script is necessary. The BCM20710 manual states on p.29 "The CTS and RTS signals of the UART interface are used for BT wake (CTS) and Host wake (RTS) functions in addition to their normal function on the UART interface. Note that this applies for both H4 and H5 protocols." So asserting RTS on the host will wake the controller (its CTS goes low). This would mean the BT_WAKE GPIO would be unnecessary. Also the Broadcom tool sends an HCI reset command first. Could this be the same kind of reset as the GPIO control line? If so then the problem could be simply setting up the UART on the host correctly. The command stty -F /dev/ttyS1 --all on the 3.4 kernel and stty -F /dev/ttyS2 --all on the 3.19 kernel might give a clue as to what has changed in the initial configuration of the serial lines. Also for testing I wonder if cat /dev/ttyS2 | hexdump -C on one host terminal then something like echo -n -e "\x01\x03\x0c\x00" > /dev/ttyS2 on another host terminal would be any help. This example is the HCI reset command, but it may be a simple echo of any text would be enough to demonstrate the host and controller are talking correctly. The device apparently doesn't send when host RTS is negated. The responses are buffered because I can get them later when I assert RTS. This is good. It shows that full duplex handshaking is taking place. The best explanation I could find of this was https://bluegiga.zendesk.com/entries/23143152--REFERENCE-Using-or-bypassing-flow-control-with-UART-communication I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. I tried sending some H5-specific commands but got no response. Ho hum, another theory bites the dust. Thanks for trying it. 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Tuesday, February 24, 2015 at 8:24:32 AM UTC+11, Al Thomas wrote: > > Your description of handshaking made me wonder if that was the problem. > Are you aware there are two serial protocols available on the chip? H4 uses > the control lines and H5 that seems to use SLIP. Page 30 of the BCM20710 > manual says "H5 requires the use of an external LPO. CTS must be pulled > low." So if RTS is asserted on the host to switch to UART transport after > reset and RTS is kept high (so CTS low on the controller) the controller > may expect H5. There is a Broadcom H5 version of the tools so I may try > that when I get set up. > Today I've tested asserting and negating RTS at various times. Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out. The device apparently doesn't send when host RTS is negated. The responses are buffered because I can get them later when I assert RTS. I tried sending some H5-specific commands but got no response. I've updated my repository because I found an ioctl bug in my patchram. Possibly significant. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Monday, 23 February 2015, 8:43 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth I've checked stty. The -clocal option causes patchram to hang when opening the serial port. The crtscts option doesn't help unfortunately. If this handshaking is done properly I'd expect the host to leave RTS off until there is something to send. Then it should raise (i.e assert) RTS, wait for CTS, send the data, then drop RTS. So this wouldn't leave RTS asserted which is what we want. Thanks for trying. Thinking about it, the cread switch of stty probably doesn't affect RTS on the host, but CTS. Your description of handshaking made me wonder if that was the problem. Are you aware there are two serial protocols available on the chip? H4 uses the control lines and H5 that seems to use SLIP. Page 30 of the BCM20710 manual says "H5 requires the use of an external LPO. CTS must be pulled low." So if RTS is asserted on the host to switch to UART transport after reset and RTS is kept high (so CTS low on the controller) the controller may expect H5. There is a Broadcom H5 version of the tools so I may try that when I get set up. I have come across something suggesting RTS is set on the host when a serial port device file is opened as part of the POSIX spec ( http://stackoverflow.com/questions/5090451/how-to-open-serial-port-in-linux-without-changing-any-pin ) although not found any verification yet. This may be why you found you had to open the file before running the Broadcom tool so RTS was asserted on the host to get the UART selected after reset. I will look for a way to assert and de-assert RTS from the command line. My theory is this switches to UART transport after reset and then because CTS will then go high on the controller the controller will expect H4 protocol. The other thing I noticed is the Broadcom reset command is the HCI reset command and not a vendor specific command. I'm hoping this will give me a nice test case that the host and controller are talking the right serial protocol. So send 0x01, 0x03, 0x0c, 0x00 and get back 0x04, 0x0e, 0x04, 0x01, 0x03, 0x0C, 0x00 See: http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#Command_Packethttps://code.google.com/p/smalltooth/wiki/HostControllerInterface#Bluetooth_Controller_setup:https://code.google.com/p/broadcom-bluetooth/source/browse/brcm_patchram_plus.c#171 Anyway there is a lot for me to try when I get that far. All the best, 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Monday, February 23, 2015 at 7:14:45 AM UTC+11, Al Thomas wrote: > > It looks as though modifying the Broadcom program allows you to use the > ioctls on the Linux UART driver because it is written in C so it is easier > for you to access the ioctl. Have you heard of or used stty ? I've just > done a bit of research on it and this program is part of the coreutils > package that comes with most GNU/Linux distributions. So a more general > solution than forking the Broadcom tools. I wish I was further along with > my board to try this myself, but instead of forking the Broadcom tools > maybe the procedure should be: > >1. Reset Bluetooth chip >2. Wait 1 centisecond for the chip to re-initialise itself >3. Issue: stty -F /dev/ttyS2 115200 crtscts -clocal cread >4. Wait a bit for luck? >5. Upload firmware with Broadcom tool > > The stty program hopefully sets up the UART on the host side, for line > control (crtscts), no modem control (-clocal) and I'm hoping cread sets RTS > to 1 on the host interface side and consequently 0 on the CTS at the > controller side. > Hi Al, Thanks for updating the linux-sunxi page; I'm sure it will be helpful to some. I've checked stty. The -clocal option causes patchram to hang when opening the serial port. The crtscts option doesn't help unfortunately. If this handshaking is done properly I'd expect the host to leave RTS off until there is something to send. Then it should raise (i.e assert) RTS, wait for CTS, send the data, then drop RTS. So this wouldn't leave RTS asserted which is what we want. My latest testing here just confirms that RTS must be asserted when the BT_REST pin goes from low to high (i.e. end of reset pulse). There is still an unexplained difference between kernels 3.4 and 3.19 where the patchram program gets a response to the "start download" command with kernel 3.9 but not 3.19. The program times out here and continues. I'm not losing any sleep over this. Thanks for all your help and suggestions here. Thanks also to Chen-Yu Tsai for his help which saved me a lot of time checking a non-existant problem. 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Monday, February 23, 2015 at 7:14:45 AM UTC+11, Al Thomas wrote: > > It looks as though modifying the Broadcom program allows you to use the > ioctls on the Linux UART driver because it is written in C so it is easier > for you to access the ioctl. Have you heard of or used stty ? I've just > done a bit of research on it and this program is part of the coreutils > package that comes with most GNU/Linux distributions. So a more general > solution than forking the Broadcom tools. I wish I was further along with > my board to try this myself, but instead of forking the Broadcom tools > maybe the procedure should be: > >1. Reset Bluetooth chip >2. Wait 1 centisecond for the chip to re-initialise itself >3. Issue: stty -F /dev/ttyS2 115200 crtscts -clocal cread >4. Wait a bit for luck? >5. Upload firmware with Broadcom tool > > Hi Al, Thanks for updating the linux-sunxi page; I'm sure it will be helpful to some. I've checked stty. The -clocal option causes patchram to hang when opening the serial port. The crtscts option doesn't help unfortunately. If this handshaking is done properly I'd expect the host to leave RTS off until there is something to send. Then it should raise (i.e assert) RTS, wait for CTS, send the data, then drop RTS. So this wouldn't leave RTS asserted which is what we want. My latest testing here just confirms that RTS must be asserted when the BT_REST pin goes from low to high (i.e. end of reset pulse). There is still an unexplained difference between kernels 3.4 and 3.19 where the patchram program gets a response to the "start download" command with kernel 3.9 but not 3.19. The program times out here and continues. I'm not losing any sleep over this. Thanks for all your help and suggestions here. Thanks also to Chen-Yu Tsai for his help which saved me a lot of time checking a non-existant problem. Cheers, Steven > The stty program hopefully sets up the UART on the host side, for line > control (crtscts), no modem control (-clocal) and I'm hoping cread sets RTS > to 1 on the host interface side and consequently 0 on the CTS at the > controller side. > > A few references for ideas: > >- See "info coreutils stty" for more on stty >- > > http://stackoverflow.com/questions/13075595/how-do-the-clocal-and-crtscts-flags-in-termios-c-cflag-affect-the-serial-port > >- useful point about clocal >- http://wiki.openwrt.org/doc/recipes/serialbaudratespeed >- http://www.valvers.com/embedded-linux/beaglebone/step05-uart/ >- https://github.com/s-macke/jor1k/issues/15#issuecomment-48670513 > > It would make things a lot simpler if stty was the magic step that was > missing. > > Another issue at the transport detect stage is the device checks for S_CLK > first. My CT schematic shows this pin is unconnected. I'm assuming it has > an internal pull-up resistor to stop it floating and causing problems. > > OK, so that's step 1 in the BCM20710 manual for HCI transport > configuration, where it checks for SCL being low. SCL is an I2C clock in > the manual. My interpretation of the manual is the I2C interface is used by > the Broadcom Serial Control (BSC) interface, maybe by default, but keeping > the I2C clock signal low during start up will switch the chip to use SPI > HCI transport. I can't find anything in the manual that shows the SPI data > lines, only SPI clock and chip select. So whether the I2C lines get > re-purposed as SPI data lines I don't know. I'm really hoping the stty > command solves the problem and all these flaky behaviours from the chip > disappear. On my board (Anichips Phoenix A20) the schematic also shows the > I2C clock and data lines are unconnected. > > Great that you are persevering with this and I hope it all comes together > soon. > > 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson Sent: Sunday, 22 February 2015, 3:16 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth Due to a reply in another forum I've uploaded my files to https://github.com/phelum/CT_Bluetooth and might get some feedback. If you are going to update the linux-sunxi page could you please include a reference to my repository. I would like some feedback from others first and suspect that you will do a much better job of updating the page. No problem, I've added a link to your work. If you are looking for a general solution and not just a CubieTruck solution then a couple of points: - Your scripts check the Kernel version to determine the UART in two places. I would set the UART tty in a single configuration file and then pass it as a parameter. Unfortunately I don't know a convention for doing this. I would also look at the FEX and DTS files to see if there was a reason why the ttys had changed number. - Forking the Broadcom tools got things working, but some distributions may be carrying the tools as a package. There is certainly a PPA page for Ubuntu. I have an idea to solve this which I detail below. It involves trying stty. But CTS is active low (same as RTS and DTR and DCD) and all float high and must be pulled low. Writing 1 to the relevant bit in the UART asserts the signal and the UART pulls the line low. So CTS must be asserted for the transport detection to work. Aha, I did not know UART was always active low ( https://bluegiga.zendesk.com/entries/90651766-Allow-UART-RTS-CTS-polarity-to-be-configured ). So writing 1 to RTS on the host will set CTS on the controller to 0, which should then initiate the UART transport layer on the controller according to the docs. A point to note is that there are no modem control lines (DTR and DCD) on UART. If it worked as per the datasheet I should be able to assert CTS after the reset pulse. But this doesn't work and this is why I wondered if the device was less than a perfect clone. I remember the old trick of echoing a character to the device and hopefully this would leave RTS (connected to device CTS) asserted. It didn't work reliably for me OK so maybe echo -n "" > /dev/ttyS2 isn't a good way of getting CTS active on the controller so I wrote my original script and modified the Broadcom program. It looks as though modifying the Broadcom program allows you to use the ioctls on the Linux UART driver because it is written in C so it is easier for you to access the ioctl. Have you heard of or used stty ? I've just done a bit of research on it and this program is part of the coreutils package that comes with most GNU/Linux distributions. So a more general solution than forking the Broadcom tools. I wish I was further along with my board to try this myself, but instead of forking the Broadcom tools maybe the procedure should be: - Reset Bluetooth chip - Wait 1 centisecond for the chip to re-initialise itself - Issue: stty -F /dev/ttyS2 115200 crtscts -clocal cread - Wait a bit for luck? - Upload firmware with Broadcom tool The stty program hopefully sets up the UART on the host side, for line control (crtscts), no modem control (-clocal) and I'm hoping cread sets RTS to 1 on the host interface side and consequently 0 on the CTS at the controller side. A few references for ideas: - See "info coreutils stty" for more on stty - http://stackoverflow.com/questions/13075595/how-do-the-clocal-and-crtscts-flags-in-termios-c-cflag-affect-the-serial-port - useful point about clocal - http://wiki.openwrt.org/doc/recipes/serialbaudratespeed - http://www.valvers.com/embedded-linux/beaglebone/step05-uart/ - https://github.com/s-macke/jor1k/issues/15#issuecomment-48670513 It would make things a lot simpler if stty was the magic step that was missing. Another issue at the transport detect stage is the device checks for S_CLK first. My CT schematic shows this pin is unconnected. I'm assuming it has an internal pull-up resistor to stop it floating and causing problems. OK, so that's step 1 in the BCM20710 manual for HCI transport configuration, where it checks for SCL being low. SCL is an I2C clock in the manual. My interpretation of the manual is the I2C interface is used by the Broadcom Serial Control (BSC) interface, maybe by default, but keeping the I2C clock signal low during start up will switch the chip to use SPI HCI transport. I can't find anything in the manual that shows the SPI data lines, only SPI clock and chip select. So whether the I2C lines get re-purposed as SPI data lines I don't know. I'm really hoping the stty command solves the problem and all these flaky behaviours from the chip disappear. On my board (Anichips Phoenix A20) the schematic also shows the I2C clock and
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Saturday, February 21, 2015 at 10:50:42 PM UTC+11, Al Thomas wrote: > > 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? > I tried increasing the bps to 1152000 but it didn't work. I'll investigate further. 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. > Due to a reply in another forum I've uploaded my files to https://github.com/phelum/CT_Bluetooth and might get some feedback. If you are going to update the linux-sunxi page could you please include a reference to my repository. I would like some feedback from others first and suspect that you will do a much better job of updating the page. 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 noted this also. But CTS is active low (same as RTS and DTR and DCD) and all float high and must be pulled low. Writing 1 to the relevant bit in the UART asserts the signal and the UART pulls the line low. So CTS must be asserted for the transport detection to work. If it worked as per the datasheet I should be able to assert CTS after the reset pulse. But this doesn't work and this is why I wondered if the device was less than a perfect clone. I remember the old trick of echoing a character to the device and hopefully this would leave RTS (connected to device CTS) asserted. It didn't work reliably for me so I wrote my original script and modified the Broadcom program. Another issue at the transport detect stage is the device checks for S_CLK first. My CT schematic shows this pin is unconnected. I'm assuming it has an internal pull-up resistor to stop it floating and causing problems. Thanks, 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson 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.
