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.
