From: Steven Saunderson <[email protected]> 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 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
