[Cryptech Tech] CLI and UARTs

Rob Austein sra at hactrn.net
Wed Aug 10 18:55:27 UTC 2016


If you don't care about the Alpha's management port command line
interface code or its USB UARTs, you can stop reading now.

I've been testing both Paul's re-port of libcli and Peter's
daughterboards for the USB UARTs.

The good news:

* Paul's re-port seems significantly less quirky than our original
  port.  Unless somebody strongly objects, I think Paul should merge
  the alternate_libcli branch of sw/stm32 to master, and I should then
  teach releng/alpha to build with that.

  Last I heard we were still waiting for word from Leif (BSD license
  stuff -- original author agreed in principal but we haven't closed
  the loop yet) before promoting either libcli port to the sw/ tree.

* Linux (Debian Jessie) and the Python serial library recognize the
  new UARTs on Peter's daughterboard.  The Unix device names are a bit
  different, these show up as /dev/ttyACM? instead of /dev/ttyUSB?,
  which at least on Jessie also places them in a different group
  ("dialout" instead of "plugdev"), but they're present.

The bad news:

* The console (management port) seems to have serious problems using
  the new UART.  I suspect this is some kind of line speed / buffer
  overrun problem.  With the old libcli it's pretty much unusable;
  the new libcli is better, but still hangs when one types any command
  which generates a large text response (eg, "help").

  Interestingly, this does not seem to be a problem for the RPC (DATA)
  port.  Not sure why.  The console hangs pretty quickly, so I don't
  think it's as simple as the RPC messages being short (they are,
  mostly, but not that short).  More likely this is something to do
  with how the various drivers pace what they send and receive.

  It is of course possible that this is a hardware quirk in the
  particular daughterboard I'm playing with, but I doubt it.

  Same HSM, software, cables work fine with the daughterboard switches
  set to use the FTDI chips, so this is (somehow) related to the
  alternate UARTs.  Details are for somebody who knows the hardware
  better than I.

The UART issue isn't a problem in the short term, everybody who has
the daughterboard should also have working FTDI UARTs which they can
keep using until we figure this out.


More information about the Tech mailing list