[Cryptech Tech] CLI and UARTs

[Leif Johansson]

On 2016-08-10 20:55, Rob Austein wrote:
> 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.
> 

yeah thx for the rminder

> * 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.
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech
>