Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson essat2...@gmail.com 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
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
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 essat2...@gmail.com 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
From: Steven Saunderson essat2...@gmail.com 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
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
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 essat2...@gmail.com 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 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 essat2...@gmail.com 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 essat2...@gmail.com 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 data lines are unconnected. Great that you are persevering with this and I
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 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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
Hi Al, My bluetooth testing is to a mobile phone for wireless broadband. I haven't tested any other bluetooth functions. The BT_WAKE pin seems irrelevant to me. After reading the datasheet I'm setting it low now. Thanks for the details from the linux-sunxi page. With kernel 3.4 this is exactly what I do. I modified the Broadcom download program to assert RTS when starting and to wait for CTS before sending. For 3.19 I've changed the process so I open the serial port before toggling the BT_REST pin. This is now working reliably. The datasheet states the device waits for CTS after a reset before enabling async mode. Perhaps the old kernel left RTS asserted when the port is closed whereas the new kernel negates it. 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. I'll keep testing and post details on the linux-sunxi page when I'm sure my new procedure is correct. Thanks for your assistance 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
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.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel
My particular issue is downloading the bluetooth firmware to the AP6210. With the 3.4 kernel I can toggle the BT_REST pin (via gpio PH18) and then open a serial connection (via uart2) and download. This works reliably. With the 3.19 kernel the AP6210 didn't respond. I've just found that if I hold BT_REST low, then open the serial connection, then release BT_REST, that the download will work. This is not an ideal solution because the Broadcom download program can't be used and the replacement program is kernel release specific. I'm wondering if the TX line from uart2 is floating before the port is opened and this is confusing the AP6210 and it's misdetecting the baud rate. The sun71-a20-cubietruck.dtb has pullup disabled for the uart2 pins. This differs from the 3.4 kernel script.bin which has the pullup set to 1. I've tried changing the .dtb file so the pullup is 1 but this didn't help. Perhaps my .dts changes are wrong. Can anybody provide a link to a good devicetree syntax manual ? Or where I can find the .dtb parsing code to see if allwinner.pull is used when allwinner,function is set to a mux value ? Or if the uart pin specs are loaded before the uart is enabled ? 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
From: Steven Saunderson essat2...@gmail.com Sent: Thursday, 19 February 2015, 20:43 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel My particular issue is downloading the bluetooth firmware to the AP6210. With the 3.4 kernel I can toggle the BT_REST pin (via gpio PH18) and then open a serial connection (via uart2) and download. This works reliably. With the 3.19 kernel the AP6210 didn't respond. Perhaps my .dts changes are wrong. Can anybody provide a link to a good devicetree syntax manual ? Or where I can find the .dtb parsing code to see if allwinner.pull is used when allwinner,function is set to a mux value ? Or if the uart pin specs are loaded before the uart is enabled ? Not tried this myself, but does the DTS at: https://github.com/wens/linux/commit/b3df2aa9dfb48d58ee590c9686dfc0e3946de5fc help at all? Atleast to upload the firmware. I'm not sure mainline AP6210 driver for BT works because there is a problem setting up the clock on the chip. I recently added a few links about AP6210 on the linux-sunxi Bluetooth wiki page if that helps: http://linux-sunxi.org/Bluetooth Hope that helps a bit, 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
On Friday, February 20, 2015 at 9:42:13 AM UTC+11, Al Thomas wrote: Not tried this myself, but does the DTS at: https://github.com/wens/linux/commit/b3df2aa9dfb48d58ee590c9686dfc0e3946de5fc help at all? Atleast to upload the firmware. I'm not sure mainline AP6210 driver for BT works because there is a problem setting up the clock on the chip. I recently added a few links about AP6210 on the linux-sunxi Bluetooth wiki page if that helps: http://linux-sunxi.org/Bluetooth 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. The good news is that bluetooth works with 3.19 once I've managed to load the firmware. 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. 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
On Thursday, February 19, 2015 at 12:34:40 PM UTC+11, Chen-Yu Tsai wrote: Mine is also using irqs 41 and 42. You should look at /proc/interrupts. You'll see that 41 and 42 are the interrupt numbers used in the kernel. The real IRQ is between GIC and the last column, which says which device or driver is using it. The software and hardware interrupt numbers aren't always in the same order. It previously was with GIC. Recently hierarchy irq domain support was added. This might have changed the behavior. Thanks for the helpful details. I see the real irqs in /proc/interrupts and when I open the device the serial driver does get attached. The confirmation that the UARTS work for you is also good. I'll keep looking here. 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
Hi, On Thu, Feb 19, 2015 at 8:18 AM, Steven Saunderson essat2...@gmail.com wrote: Hi, I'm running 3.19 on my CT and can't get the internal UARTs to work. The two UARTs I'm testing are /dev/ttyS0 (debug port) and /dev/ttyS2 (connects to BT half of AP6210). With the 3.4 kernel, ttyS0 uses irq 33 and the BT UART uses irq 35. But with the 3.19 kernel, according to /proc/tty/driver/serial, ttyS0 uses irq 41 and ttyS2 uses irq 42. The CT dtb specifies interrupts 1 and 3 for these devices and given the convention of adding 32 these irq numbers become 33 and 35 which sounds right to me. But for some strange reason these devices end up with irqs 41 and 42. I would think that any device inside the SoC would be hard-wired to a certain interrupt line and the irqs here should always be 33 and 35. Does anybody know whether using irqs 41 and 42 here could be correct ? Or has anybody got the UARTs working with 3.19 ? Mine is working fine. Mine is also using irqs 41 and 42. You should look at /proc/interrupts. You'll see that 41 and 42 are the interrupt numbers used in the kernel. The real IRQ is between GIC and the last column, which says which device or driver is using it. The software and hardware interrupt numbers aren't always in the same order. It previously was with GIC. Recently hierarchy irq domain support was added. This might have changed the behavior. ChenYu -- 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.
