test, tools: introduce tbot README

introduce a README how to use tbot for testing U-Boot
and/or linux kernels.

Signed-off-by: Heiko Schocher <hs@denx.de>

4 files changed, 734 insertions, 0 deletions

diff --git a/tools/tbot/README b/tools/tbot/README
new file mode 100644
index 0000000..a637a63
--- /dev/null
+++ b/tools/tbot/README
@@ -0,0 +1,185 @@
+# Copyright (c) 2016 DENX Software Engineering GmbH
+# Heiko Schocher <hs@denx.de>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+What is tbot ?
+==============
+
+tbot is a tool for executing testcases on boards.
+Source code found on [1]
+Based on DUTS [2]
+written in python
+
+Basic Ideas of tbot
+===================
+(see also the figure:
+https://github.com/hsdenx/tbot/blob/master/doc/tbot_structure.png )
+
+- Virtual laboratory (VL)
+   VL is the basic environment that groups:
+  - [a number of] boards - target devices on which tbot executes testcases.
+  - one Lab PC
+
+- Test case (TC):
+  A piece of python code, which uses the tbot class from [1].
+  Tbot provides functions for sending shell commands and parsing the
+  shell commands output.
+  Tbot waits endless for a shell commands end (detected through reading
+  the consoles prompt).
+  A TC can also call other TC-es.
+
+  remark:
+  Tbot not really waits endless, for a shell commands end, instead
+  tbot starts a watchdog in the background, and if it triggers, tbot
+  ends the TC as failed. In the tbot beginning there was a lot of
+  timeouts / retry cases, but it turned out, that waiting endless
+  is robust and easy ...
+
+- Host PC (where tbot runs, currently only linux host tested)
+  must not a powerful machine (For example [3], I use a
+  raspberry pi for running tbot and buildbot)
+
+- Lab PC:
+  - Host PC connects through ssh to the Lab PC
+    -> so it is possible to test boards, which
+       are not at the same place as the Host PC.
+       (Lab PC and Host PC can be the same of course)
+       -> maybe we can setup a Testsystem, which does nightly
+          U-Boot/Linux builds and test from current mainline U-Boot
+          on boards wherever they are accessible.
+
+  - necessary tasks a Lab PC must deliver:
+    - connect to boards console through a shell command.
+    - power on/off boards through a shell command
+    - detect the current power state of a board through
+      a shell command
+
+  - optional tasks:
+    - tftp server (for example loading images)
+    - nfs server (used as rootfs for linux kernels)
+    - Internet access for example for downloading
+      U-Boot source with git.
+    - toolchains installed for compiling source code
+
+      -> a linux machine is preffered.
+
+  - currently only Lab PC with an installed linux supported/tested.
+
+- Boards(s):
+  the boards on which shell commands are executed.
+
+- Board state:
+  equals to the software, the board is currently running.
+
+  Currently tbot supports 2 board states:
+    - "u-boot", if the board is running U-Boot
+    - "linux", if the board is running a linux kernel
+
+  It should be easy to add other board states to tbot, see
+  https://github.com/hsdenx/tbot/tree/master/src/lab_api/state_[u-boot/linux].py
+
+  A board state is detected through analysing the boards
+  shell prompt. In linux, tbot sets a special tbot prompt,
+  in U-Boot the prompt is static, and configurable in tbot through
+  a board config file.
+
+  A TC can say in which board state it want to send shell commands.
+  Tbot tries to detect the current board state, if board is not in
+  the requested  board state, tbot tries to switch into the correct
+  state. If this fails, the TC fails.
+
+  It is possible to switch in a single TC between board states.
+
+- tbot cmdline parameters:
+
+$ python2.7 src/common/tbot.py --help
+Usage: tbot.py [options]
+
+Options:
+  -h, --help            show this help message and exit
+  -c CFGFILE, --cfgfile=CFGFILE
+                        the tbot common configfilename
+  -l LOGFILE, --logfile=LOGFILE
+                        the tbot logfilename, if default, tbot creates a
+                        defaultnamelogfile
+  -t TC, --testcase=TC  the testcase which should be run
+  -v, --verbose         be verbose, print all read/write to stdout
+  -w WORKDIR, --workdir=WORKDIR
+                        set workdir, default os.getcwd()
+$
+
+tbot needs the following files for proper execution:
+
+  - tbot board configuration file (option -c):
+    A board configuration file contains settings tbot needs to
+    connect to the Lab PC and board specific variable settings
+    for testcases.
+
+  - name of the logfile tbot creates (option -l)
+    defaultname: 'log/' + now.strftime("%Y-%m-%d-%H-%M") + '.log'
+
+  - tbots working directory (option -w)
+
+  - the testcasename tbot executes (option -t)
+
+You are interested and want to use tbot?
+If so, please read on the file:
+tools/tbot/README.install
+
+If not read [3] ;-)
+
+Heiko Schocher <hs@denx.de>
+v1 2016.01.22
+
+--------------
+[1] https://github.com/hsdenx/tbot
+[2] http://www.denx.de/wiki/DUTS/DUTSDocs
+[3] automated Testsetup with buildbot and tbot doing cyclic tests
+    (buildbot used for starting tbot TC and web presentation of the
+     results, all testing done through tbot):
+    http://xeidos.ddns.net/buildbot/tgrid
+    Host PC in Letkes/hungary
+    VL in munich/germany
+
+    Fancy things are done here, for example:
+    - http://xeidos.ddns.net/buildbot/builders/smartweb_dfu/builds/43/steps/shell/logs/tbotlog
+      (I try to cleanup the logfile soon, so it is not so filled with crap ;-)
+      A first step see here:
+      http://xeidos.ddns.net/buildbot/builders/smartweb_dfu/builds/45/steps/shell/logs/tbotlog
+      (same TC now with the new loglevel = 'CON' ... not yet perfect)
+      Executed steps:
+      - clone u-boot.git
+      - set toolchain
+      - get a list of patchwork patches from my U-Boots ToDo list
+      - download all of them, and check them with checkpatch
+        and apply them to u-boot.git
+      - compile U-Boot for the smartweb board
+      - install the resulting images on the smartweb board
+      - boot U-boot
+      - test DFU
+      - more TC should be added here for testing U-Boot
+
+    - automatic "git bisect"
+      https://github.com/hsdenx/tbot/blob/master/src/tc/tc_board_git_bisect.py
+      http://xeidos.ddns.net/buildbot/builders/tqm5200s/builds/3/steps/shell/logs/tbotlog
+
+      If a current U-Boot image not works on the tqm5200 board
+      this TC can be started. It starts a "git bisect" session,
+      and compiles for each step U-Boot, install it on the tqm5200
+      board, and tests if U-Boot works !
+
+      At the end, it detects the commit, which breaks the board
+
+      This TC is not dependend on U-Boot nor on a special board. It
+      needs only 3 variables:
+      tb.board_git_bisect_get_source_tc: TC which gets the source tree, in which
+        "git bisect" should be executed
+      tb.board_git_bisect_call_tc: TC which gets called every "git bisect" step,
+        which executes commands for detecting if current source code is OK or not.
+        This could be a TC which compiles U-Boot, install it on the board and
+        executes TC on the new booted U-Boot image. ! Board maybe gets borken,
+        as not all U-Boot images work, so you must have a TC which install U-Boot
+        image for example through a debugger.
+      tb.board_git_bisect_good_commit: last nown good commit id
diff --git a/tools/tbot/README-ToDo b/tools/tbot/README-ToDo
new file mode 100644
index 0000000..daf1af1
--- /dev/null
+++ b/tools/tbot/README-ToDo
@@ -0,0 +1,62 @@
+# Copyright (c) 2016 DENX Software Engineering GmbH
+# Heiko Schocher <hs@denx.de>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+ToDo list for tbot
+==================
+
+please look also into the tbot ToDo list.
+https://github.com/hsdenx/tbot/blob/master/ToDo
+
+- cleanup tbot code:
+  - remove all retry / timeout pieces of code
+  - clean up tbot function names, as I am not good in
+    giving function a understandable name ;-)
+  - as I am not a python programmer, cleanup whole tbot code
+
+- introduce a "layering" like yocto do, so U-Boot TC can integrated
+  into U-Boot source code.
+
+  Proposal:
+  introduce  subdirs in "src/tc"
+
+       lab: all lab specific stuff
+       lab/common: common lab stuff (for example ssh handling)
+       lab/ssh_std: ssh_std specific stuff
+
+       u-boot: all u-boot tests
+       u-boot/common: common u-boot tc
+       u-boot/duts: DUTS tc
+       u-boot-dxr2: all u-boot dxr2 board specific tc
+
+       board: board tc
+       board/common: common board tc
+       board/dxr2: all tc for dxr2 board
+
+       linux: all linux tc
+       linux/common: common linux tc
+       linux/dxr2
+
+  - move U-Boot special TC to U-Boot source
+    -> need a mechanism in tbot, how it gets automatically for example
+       U-Boot TC from U-Boot source...
+    -> add a consistency checker
+
+- simplify tbot log output (seperate a lot of output which is currently
+  in INFO logging level, to another logging level)
+  started (new loglevel "CON", whih prints read/write from console only), see:
+  https://github.com/hsdenx/tbot/commit/b4ab2567ad8c19ad53f785203159d3c8465a21c6
+  - make the timestamp configurable
+
+- Open more than 2 filehandles ?
+  Do we need for more complex TC more than 2 filehandles?
+
+- Find a way to document all TC and document all variables they use in an
+  automated way.
+
+- write a lot of more TC
+
+- get U-Boot configuration settings from current U-Boot code and use
+  them in U-Boot TC-es
diff --git a/tools/tbot/README.create_a_new_testcase b/tools/tbot/README.create_a_new_testcase
new file mode 100644
index 0000000..fbf8ae8
--- /dev/null
+++ b/tools/tbot/README.create_a_new_testcase
@@ -0,0 +1,117 @@
+# Copyright (c) 2016 DENX Software Engineering GmbH
+# Heiko Schocher <hs@denx.de>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+write a new testcase
+=====================
+
+A TC is written in python, so you can use python as usual. For accessing
+the boards console, use functions from the tbotlib, therefore
+
+First import the tbotlib with the line:
+
+  from tbotlib import tbot
+
+If your TC uses variables, please add a line which adds them to
+the log file (for debugging purposes):
+
+  logging.info("args: %s ...", tb.varname, ...)
+
+Say tbot, for which board state your TC is valid with:
+
+  tb.set_board_state("u-boot")
+
+Then you are ready ... and you can use the tbotlib funtions
+for writting/reading to the boards console.
+
+Big fat warning:
+
+A TC must worry about to end only if a board has finished the shell
+command!
+
+Not following this rule, will end in unpredictable behaviour.
+
+(hopefully) useful tbotlib functions
+====================================
+- set the board state, you want to test
+  tb.set_board_state(state)
+  states are: "u-boot" or "linux"
+  If tbot could not set the board state, tbot ends with failure.
+
+- write a command to the boards console:
+  tb.eof_write_con(command):
+    write the command to the boards console. If this
+    fails, tbot ends with failure
+
+- write a command to boards console and wait for prompt:
+  tb.eof_write_cmd(fd, command):
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    command: command which is written to fd
+
+    Wait endless for board prompt
+
+- write a list of commands to boards console:
+  tb.eof_write_cmd_list(fd, cmdlist):
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    cmdlist: python list of commandstrings which is written to fd
+
+- wait for boards prompt:
+  tb.eof_read_end_state_con(retry):
+    retry: deprecated, not used anymore, cleanup needed here...
+    tbot waits endless for the boards prompt
+
+- write a command, wait for prompt and check, if a string is read
+  tb.write_cmd_check(fd, cmd, string):
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    cmd: command, which is send to fd
+    string: string which should be read from fd
+
+    return value:
+      True, if string is read and tbot got back boards prompt
+      False, else
+
+  tb.eof_write_cmd_check(fd, cmd, string):
+    same as tb.write_cmd_check(fd, cmd, string) except, that tbot
+    ends immediately with Failure, if string is not read.
+
+- read until prompt and search strings:
+  tb.readline_and_search_strings(fd, strings):
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    strings: python list of strings, which can be read
+      If one of this strings is read, this function return the index, which
+      string is read. This function shoud be called in a while loop,
+      until this function returns 'prompt'
+
+- read a line from filedescriptor:
+  not recommended to use, as the TC must check, if tprompt is read for every
+  readen line. Also TC must ensure, that it ends only, if prompt is read.
+  tb.read_line(fd, retry)
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    retry: retry of trying to reead a line
+
+  return values:
+    True, if a line is read. Readen line in tb.buf[fd]
+    False, if something read, but not a complete line
+    None, if nothing is read
+
+  check if string contains prompt with:
+  tb.is_end_fd(fd, string)
+    fd: filedescriptor which is used, use tb.channel_con for boards console
+    string: buffer, in which a prompt gets searched.
+
+- calling other TC:
+  eof_call_tc(name):
+    call another TC from "src/tc"
+    if the called TC fails with failure, tbot ends with failure
+
+  call_tc(name):
+    call another TC from "src/tc"
+    if the TC which call_tc calls  fails, call_tc() returns False, else True
+
+There are more functions, but for writting TC this should be enough. But
+its software, so new useful functions can always pop up.
+
+Heiko Schocher <hs@denx.de>
+v1 2016.01.23
diff --git a/tools/tbot/README.install b/tools/tbot/README.install
new file mode 100644
index 0000000..24c67bc
--- /dev/null
+++ b/tools/tbot/README.install
@@ -0,0 +1,370 @@
+# Copyright (c) 2016 DENX Software Engineering GmbH
+# Heiko Schocher <hs@denx.de>
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+install tbot on your PC (linux only tested):
+============================================
+
+- get the source code:
+
+$ git clone https://github.com/hsdenx/tbot.git
+[...]
+$
+
+  cd into the tbot directory.
+
+- you need the for running tbot the python paramiko module, see:
+  http://www.paramiko.org/installing.html
+
+  paramiko is used for handling ssh sessions, and open filedescriptors
+  on a ssh connection. Tbot open a ssh connection to a "lab PC" and
+  opens on that connection 2 filehandles, one for control functions
+  and one for the connection to the boards console. May it is worth
+  to think about to open more filehandles and use them in tbot, but
+  thats a point in the Todo list ...
+
+  See [1] for more infos about tbot principles.
+
+- prepare a directory for storing the logfiles
+  and pass it with the commandline option "-l"
+  to tbot. Default is the directory "log" in the tbot
+  root (don;t forget to create it, if you want to use it)
+
+- If your VL is not yet in tbot source, integrate it
+  (This task has only to be done once for your VL):
+
+  A VL has, as described in [2] "necessary tasks for a Lab PC" explained,
+  3 tasks:
+
+  a) power on/off the board
+  b) get power state of the board
+  c) connect to the boards console
+
+  As tbot sends only shell commands (also to the Lab PC)
+  this tasks must be executable through shell commands on your
+  Lab PC:
+
+  Task a) power on/off board:
+    default TC for this task is:
+    https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lab_denx_power.py
+
+    - now copy this file to for example
+      cp src/tc/tc_lab_denx_power.py src/tc/tc_lab_denx_power_XXX.py
+      (replace XXX to a proper value)
+      and adapt the "remote_power" command from the denx lab to your needs.
+
+      As this TC powers on the board for all your boards in your VL,
+      you can differ between the boards through the tbot class
+      variable "tb.boardlabpowername" (which is in the default case the
+      same as "tb.boardname"), but you may need to name the power target
+      with an other name than boardname, so you can configure this case.
+      The power state "tb.power_state" which the TC has to set
+      is "on" for power on, or "off" for power off.
+
+      If switching on the power is successful, call "tb.end_tc(True)"
+      else "tb.end_tc(False)"
+
+    - set in your board config file:
+      self.tc_lab_denx_power_tc = 'tc_lab_denx_power_XXX.py'
+
+  Task b) power on/off board:
+    default TC for this task is:
+    https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lab_denx_get_power_state.py
+
+    - now copy this file to for example
+      (replace XXX to a proper value)
+      cp src/tc/tc_lab_denx_get_power_state.py src/tc/tc_lab_denx_get_power_state_XXX.py
+      and adapt the commands to your needs.
+
+      If the power of the board is on, call "tb.end_tc(True)"
+      else "tb.end_tc(False)"
+
+    - set in your board config file:
+      self.tc_lab_denx_get_power_state_tc = 'tc_lab_denx_get_power_state_XXX.py'
+
+  Task c) connect to the boards console:
+    default TC for this task is:
+    https://github.com/hsdenx/tbot/blob/master/src/tc/tc_lab_denx_connect_to_board.py
+
+    - now copy this file to for example
+      (replace XXX to a proper value)
+      cp src/tc/tc_lab_denx_connect_to_board.py src/tc/tc_lab_denx_connect_to_board_XXX.py
+      and adapt the commands to your needs.
+
+      As this TC powers on the board for all your boards in your VL,
+      you can differ between the boards through the tbot class
+      variable "tb.boardlabname" (which is in the default case the
+      same as "tb.boardname"), but you may need to name the power target
+      with an other name than boardname, so you can configure this case.
+
+      If connect fails end this TC with "tb.end_tc(False)"
+      else call "tb.end_tc(True)"
+
+      If you want to use kermit for connecting to the boards console, you
+      can use:
+
+      https://github.com/hsdenx/tbot/blob/master/src/tc/tc_workfd_connect_with_kermit.py
+
+      Example for such a board in the VL from denx:
+      self.tc_lab_denx_connect_to_board_tc = 'tc_workfd_connect_with_kermit.py'
+      https://github.com/hsdenx/tbot/blob/master/tbot_dxr2.cfg#L24
+
+      Hopefully this works for you too.
+
+    - set in your board config file:
+      self.tc_lab_denx_connect_to_board_tc = 'tc_lab_denx_connect_to_board_XXX.py'
+
+  remarks while writting this:
+  - Currently there is only the denx VL. Original idea was to include
+    other VL through a seperate class/file in
+    https://github.com/hsdenx/tbot/tree/master/src/lab_api
+    but it turned out, that if we say "ssh" is the standard way to connect
+    to a VL, we can integrate the VL specific tasks through testcases, see
+    above, so we should do:
+    - rename the "denx" API to a more general name.
+      This is a point on my ToDo list ... done, renamed to 'ssh_std'
+
+  - the VL specific configuration may moved from the board config files
+    and should be collected in VL specific config files, which boards
+    config file simple include.
+
+- prepare password.py file:
+  This file contains all passwords tbot needs (for example for
+  linux login on the boards)
+  tbot searches this file in the tbot root directory.
+  It is a simple python file, for example:
+
+  # passwords for the lab
+  if (board == 'lab'):
+      if (user == 'hs'):
+          password = 'passwordforuserhs'
+      if (user == 'root'):
+          password = 'passwordforrootuser'
+  # passwords for the boards
+  elif (board == 'mcx'):
+      if (user == 'root'):
+          password = 'passwordformcxrootfs'
+  else:
+      if (user == 'root'):
+          password = ''
+
+  In the above example passwords for logging into the Lab PC tbot finds
+  through:
+  if (board == 'lab'):
+     user = 'name':
+         password = 'gnlmpf' # password 'gnlmpf' for login of user 'name'
+
+- prepare board config file
+  Each board which is found in the VL needs a tbot configuration file
+  pass the config file name with the option '-c' to tbot, tbot searches
+  in the root dir for them.
+
+  board Example (dxr2 board):
+  https://github.com/hsdenx/tbot/blob/master/tbot_dxr2.cfg
+
+  Necessary variables:
+
+  line  3: boardname, here it is the "etamin" board
+             no default value, must be set.
+  line  4: boardlabname: name used for connecting to the board
+             may differ from tb.boardname, default tb.boardname
+  line  5: boardlabpowername: name used for power on/off
+             may differ from tb.boardname, default tb.boardname
+  line  6: tftpboardname: name used for tftp subdir (from where
+             U-Boot loads images for example).
+             may differ from tb.boardname, default tb.boardname
+  line  7: labprompt: linux prompt tbot sets
+             no defaultvalue, must be set (maybe we should introduce
+             "ttbott" as default ...
+  line  8: debug: If True, adds debug output on the tbot shell
+  line  9: debugstatus: enable status debug output on the shell
+  line 10: ip: Where tbot finds the Lab PC
+  line 11: user: As which user does tbot logs into the Lab PC
+  line 12: accept_all: passed to paramiko, accept all connections
+  line 13: keepalivetimout: passed to paramiko, timeout for sending
+             keepalive message.
+  line 14: channel_timeout: passed to paramiko
+  line 15: loglevel: tbots loglevel for adding entries into the logfile.
+  line 16: lap_api: used lap API (currently only 'ssh_std')
+             Should be declared as standard -> this line would be not needed
+             longer.
+  line 17: wdt_timeout: timeout in seconds for tbots watchdog.
+             Watchdog gets triggered if prompt get read.
+  line 20,21: include 'ssh_std' api
+             should be removed.
+  line 24: tc_lab_denx_connect_to_board_tc: Which TC is used for
+             connecting to the boards console the TC, here:
+             https://github.com/hsdenx/tbot/blob/master/src/tc/tc_workfd_connect_with_kermit.py
+  line 27: uboot_prompt: boards U-Boot prompt
+  line 28: linux_prompt: boards linux prompt
+
+  Now comes a list of variables TC needs, this vary from which TC
+  you start on the board.
+
+Thats it ... you now can call tbot and hopefully, it works ;-)
+Find an example log [3] for calling simple U-Boot TC for setting
+an U-Boot Environmentvariable.
+
+If you have problems in setting tbot up, please contact me
+(and may give me ssh access to your Lab PC ;-)
+
+If you have running your first TC [3], you may want to write now your own
+TC (and hopefully share them), so continue with:
+u-boot:tools/tbot/README.create_a_new_testcase
+
+Heiko Schocher <hs@denx.de>
+v1 2016.01.22
+
+--------------
+
+[1] tbot Dokumentation:
+    [2] u-boot:/tools/tbot/README
+    https://github.com/hsdenx/tbot/blob/master/README.md
+
+[3] Example for a first U-Boot TC which should always work:
+    (with commandline option "-v" for verbose output):
+
+hs@localhost:tbot  [master] $ python2.7 src/common/tbot.py -c tbot_dxr2.cfg -t tc_ub_setenv.py -v -l log/tbot.log
+**** option cfg: tbot_dxr2.cfg log: log/tbot.log tc: tc_ub_setenv.py v 1
+('CUR WORK PATH: ', '/home/hs/data/Entwicklung/tbot')
+('CFGFILE ', 'tbot_dxr2.cfg')
+('LOGFILE ', '/home/hs/data/Entwicklung/tbot/log/tbot.log')
+(<denx.tbot_lab_api object at 0x7f53ac1808d0>, <tbotlib.tbot object at 0x7f53a45fd410>, True)
+(<denx.tbot_lab_api object at 0x7f53ac1808d0>, <tbotlib.tbot object at 0x7f53a45fd410>, True)
+read 0: Last login: Fri Jan 22 12:20:12 2016 from 87.97.28.177
+read 0:
+read 0: *************************************************************
+read 0: BDI2000 Assignment:    (last updated:  2015-11-20 12:30 MET)
+read 0: bdi1  => techem     bdi2  => cetec_mx25   bdi3  => lpc3250
+read 0: bdi4  => -          bdi5  => --Rev.B!--   bdi6  => tqm5200s
+read 0: bdi7  => [stefano]  bdi8  => smartweb     bdi9  => sigmatek-nand
+read 0: bdi10 => pcm052     bdi11 => socrates     bdi12 => aristainetos
+read 0: bdi13 => imx53      bdi14 => ib8315       bdi15 => cairo
+read 0: bdi16 => g2c1       bdi17 => lwe090       bdi18 => symphony
+read 0: bdi19 => dxr2       bdi20 => ima3-mx6     bdi21 => sama5d3
+read 0: bdi98 => -          bdi99 => -            bdi0  => -
+read 0: Please power off unused systems when you leave!   Thanks, wd.
+read 0: *************************************************************
+read no ret 0:
+pollux:~ hs $
+write 0: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 0: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 0: hs@pollux [12:21:00] ttbott >
+read 1: Last login: Fri Jan 22 12:20:59 2016 from 87.97.28.177
+read 1:
+read 1: *************************************************************
+read 1: BDI2000 Assignment:    (last updated:  2015-11-20 12:30 MET)
+read 1: bdi1  => techem     bdi2  => cetec_mx25   bdi3  => lpc3250
+read 1: bdi4  => -          bdi5  => --Rev.B!--   bdi6  => tqm5200s
+read 1: bdi7  => [stefano]  bdi8  => smartweb     bdi9  => sigmatek-nand
+read 1: bdi10 => pcm052     bdi11 => socrates     bdi12 => aristainetos
+read 1: bdi13 => imx53      bdi14 => ib8315       bdi15 => cairo
+read 1: bdi16 => g2c1       bdi17 => lwe090       bdi18 => symphony
+read 1: bdi19 => dxr2       bdi20 => ima3-mx6     bdi21 => sama5d3
+read 1: bdi98 => -          bdi99 => -            bdi0  => -
+read 1: Please power off unused systems when you leave!   Thanks, wd.
+read 1: *************************************************************
+read no ret 1:
+pollux:~ hs $
+write 1: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 1: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 1: hs@pollux [12:21:02] ttbott >
+write 0: remote_power dxr2 -l
+read 0: hs@pollux [12:21:00] ttbott >remote_power dxr2 -l
+read 0: dxr2            ON
+read 0: hs@pollux [12:21:02] ttbott >
+read no ret 1:
+hs@pollux [12:21:02] ttbott >
+write 1: ssh hs@lena
+read 1: ssh hs@lena
+read no ret 1:
+hs@lena's password:
+read 1:
+read 1: Last login: Fri Jan 22 12:20:17 2016 from 192.168.1.1
+read 1:
+read no ret 1:
+[hs@lena ~]$
+write 1: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 1: export PS1="\u@\h [\$(date +%k:%M:%S)] ttbott >"
+read 1: hs@lena [12:21:07] ttbott >
+read no ret 1:
+hs@lena [12:21:07] ttbott >
+write 1: stty cols 200
+read 1: stty cols 200
+read 1: hs@lena [12:21:08] ttbott >
+write 1: export TERM=vt200
+read 1: hs@lena [12:21:08] ttbott >export TERM=vt200
+read 1: hs@lena [12:21:08] ttbott >
+write 1: echo $COLUMNS
+read 1: hs@lena [12:21:08] ttbott >echo $COLUMNS
+read 1: 200
+read 1: hs@lena [12:21:08] ttbott >
+write 1: kermit
+read 1: hs@lena [12:21:08] ttbott >kermit
+read 1: C-Kermit 8.0.211, 10 Apr 2004, for Linux
+read 1:
+read 1:  Copyright (C) 1985, 2004,
+read 1:   Trustees of Columbia University in the City of New York.
+read 1: Type ? or HELP for help.
+read 1:
+read 1: (/home/hs/) C-Kermit>
+read 1:
+read no ret 1: (/home/hs/) C-Kermit>
+write 1: set line /dev/ttyUSB0
+read 1: set line /dev/ttyUSB0
+read 1:
+read 1: (/home/hs/) C-Kermit>
+write 1: set speed 115200
+read 1:
+read 1: (/home/hs/) C-Kermit>set speed 115200
+read 1: /dev/ttyUSB0, 115200 bps
+read 1:
+read 1: (/home/hs/) C-Kermit>
+write 1: set flow-control none
+read 1:
+read 1: (/home/hs/) C-Kermit>set flow-control none
+read 1:
+read 1: (/home/hs/) C-Kermit>
+write 1: set carrier-watch off
+read 1:
+read 1: (/home/hs/) C-Kermit>set carrier-watch off
+read 1:
+read 1: (/home/hs/) C-Kermit>
+write 1: connect
+read 1:
+read 1: (/home/hs/) C-Kermit>connect
+read 1: Connecting to /dev/ttyUSB0, speed 115200
+read 1:
+read 1:  Escape character: Ctrl-\ (ASCII 28, FS): enabled
+read 1:
+read 1: Type the escape character followed by C to get back,
+read 1:
+read 1: or followed by ? to see other options.
+read 1:
+read 1: ----------------------------------------------------
+read no ret 1:
+
+write no ret 1:
+
+read 1:
+read 1: Heiko=Schocher
+read no ret 1:
+U-Boot#
+write no ret 1:
+write no ret 1:
+
+read 1: <INTERRUPT>
+read 1: U-Boot#
+write 1: setenv Heiko Schocher
+read 1: U-Boot# setenv Heiko Schocher
+read no ret 1:
+U-Boot#
+write 1: printenv Heiko
+read 1: printenv Heiko
+read 1: Heiko=Schocher
+read no ret 1:
+U-Boot#
+End of TBOT: success
+hs@localhost:tbot  [master] $