refer in the README to tbots webpage, and delete the README in tools/tbot, as the latest documentation for tbot is on this webpage. Signed-off-by: Heiko Schocher <hs@denx.de>master
parent
f8dbc0734d
commit
630dfede22
@ -1,195 +0,0 @@ |
|||||||
# 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. |
|
||||||
|
|
||||||
- Events |
|
||||||
tbot creates while executing testcases so called events. |
|
||||||
After tbot ended with the testcase it can call event_backends, |
|
||||||
which convert the events to different formats. more info: |
|
||||||
|
|
||||||
https://github.com/hsdenx/tbot/blob/master/doc/README.event |
|
||||||
|
|
||||||
demo for a event backend: |
|
||||||
http://xeidos.ddns.net/tests/test_db_auslesen.php |
|
||||||
|
|
||||||
- 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 |
|
@ -1,62 +0,0 @@ |
|||||||
# 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 |
|
@ -1,117 +0,0 @@ |
|||||||
# 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 |
|
@ -1,310 +0,0 @@ |
|||||||
# 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. |
|
||||||
|
|
||||||
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 = '' |
|
||||||
|
|
||||||
- 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 17: wdt_timeout: timeout in seconds for tbots watchdog. |
|
||||||
Watchdog gets triggered if prompt get read. |
|
||||||
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> |
|
||||||
v2 2016.04.26 |
|
||||||
|
|
||||||
-------------- |
|
||||||
|
|
||||||
[1] tbot Dokumentation: |
|
||||||
[2] u-boot:/tools/tbot/README |
|
||||||
https://github.com/hsdenx/tbot/blob/master/README.md |
|
||||||
tbot-devel@googlegroups.com |
|
||||||
|
|
||||||
[3] Example for a first U-Boot TC which should always work: |
|
||||||
(with commandline option "-v" for verbose output): |
|
||||||
hs@localhost:tbot [event-devel] $ 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') |
|
||||||
tb_ctrl: Last login: Mon Apr 25 14:52:42 2016 from 87.97.29.27 |
|
||||||
************************************************************* |
|
||||||
BDI2000 Assignment: (last updated: 2015-11-20 12:30 MET) |
|
||||||
bdi1 => techem bdi2 => cetec_mx25 bdi3 => lpc3250 |
|
||||||
bdi4 => - bdi5 => --Rev.B!-- bdi6 => tqm5200s |
|
||||||
bdi7 => [stefano] bdi8 => smartweb bdi9 => sigmatek-nand |
|
||||||
bdi10 => pcm052 bdi11 => socrates bdi12 => aristainetos |
|
||||||
bdi13 => imx53 bdi14 => ib8315 bdi15 => cairo |
|
||||||
bdi16 => g2c1 bdi17 => lwe090 bdi18 => symphony |
|
||||||
bdi19 => dxr2 bdi20 => ima3-mx6 bdi21 => sama5d3 |
|
||||||
bdi98 => - bdi99 => - bdi0 => - |
|
||||||
Please power off unused systems when you leave! Thanks, wd. |
|
||||||
************************************************************* |
|
||||||
tb_ctrl: pollux:~ hs $ |
|
||||||
tb_ctrl: export PS1=ttbott |
|
||||||
ttbott |
|
||||||
tb_ctrl: stty cols 200 |
|
||||||
ttbott |
|
||||||
tb_ctrl: export TERM=vt200 |
|
||||||
ttbott |
|
||||||
tb_ctrl: echo $COLUMNS |
|
||||||
200 |
|
||||||
ttbott |
|
||||||
tb_con: Last login: Tue Apr 26 06:28:59 2016 from 87.97.29.27 |
|
||||||
************************************************************* |
|
||||||
BDI2000 Assignment: (last updated: 2015-11-20 12:30 MET) |
|
||||||
bdi1 => techem bdi2 => cetec_mx25 bdi3 => lpc3250 |
|
||||||
bdi4 => - bdi5 => --Rev.B!-- bdi6 => tqm5200s |
|
||||||
bdi7 => [stefano] bdi8 => smartweb bdi9 => sigmatek-nand |
|
||||||
bdi10 => pcm052 bdi11 => socrates bdi12 => aristainetos |
|
||||||
bdi13 => imx53 bdi14 => ib8315 bdi15 => cairo |
|
||||||
bdi16 => g2c1 bdi17 => lwe090 bdi18 => symphony |
|
||||||
bdi19 => dxr2 bdi20 => ima3-mx6 bdi21 => sama5d3 |
|
||||||
bdi98 => - bdi99 => - bdi0 => - |
|
||||||
Please power off unused systems when you leave! Thanks, wd. |
|
||||||
************************************************************* |
|
||||||
tb_con: pollux:~ hs $ |
|
||||||
tb_con: export PS1=ttbot |
|
||||||
tb_con: t |
|
||||||
ttbott |
|
||||||
tb_con: stty cols 200 |
|
||||||
ttbott |
|
||||||
tb_con: export TERM=vt200 |
|
||||||
ttbott |
|
||||||
tb_con: echo $COLUMNS |
|
||||||
200 |
|
||||||
ttbott |
|
||||||
tb_con: ssh hs@lena |
|
||||||
tb_con: hs@lena's password: |
|
||||||
tb_con: |
|
||||||
tb_con: Last login: Mon Apr 25 07:03:29 2016 from 192.168.1.1 |
|
||||||
tb_con: [hs@lena ~]$ |
|
||||||
tb_con: export PS1=ttbott |
|
||||||
ttbott |
|
||||||
tb_con: stty cols 200 |
|
||||||
ttbott |
|
||||||
tb_con: export TERM=vt200 |
|
||||||
ttbott |
|
||||||
tb_con: echo $COLUMNS |
|
||||||
200 |
|
||||||
ttbott |
|
||||||
tb_con: kermit |
|
||||||
C-Kermit 8.0.211, 10 Apr 2004, for Linux |
|
||||||
Copyright (C) 1985, 2004, |
|
||||||
Trustees of Columbia University in the City of New York. |
|
||||||
Type ? or HELP for help. |
|
||||||
(/home/hs/) C-Kermit> |
|
||||||
tb_con: set line /dev/ttyUSB0 |
|
||||||
(/home/hs/) C-Kermit> |
|
||||||
tb_con: set speed 115200 |
|
||||||
/dev/ttyUSB0, 115200 bps |
|
||||||
(/home/hs/) C-Kermit> |
|
||||||
tb_con: set flow-control none |
|
||||||
(/home/hs/) C-Kermit> |
|
||||||
tb_con: set carrier-watch off |
|
||||||
(/home/hs/) C-Kermit> |
|
||||||
tb_con: connect |
|
||||||
Connecting to /dev/ttyUSB0, speed 115200 |
|
||||||
Escape character: Ctrl-\ (ASCII 28, FS): enabled |
|
||||||
Type the escape character followed by C to get back, |
|
||||||
or followed by ? to see other options. |
|
||||||
---------------------------------------------------- |
|
||||||
tb_con: <INTERRUPT> |
|
||||||
U-Boot# |
|
||||||
tb_con: U-Boot# |
|
||||||
U-Boot# |
|
||||||
tb_con: setenv Heiko Schocher |
|
||||||
U-Boot# |
|
||||||
tb_con: printenv Heiko |
|
||||||
Heiko=Schocher |
|
||||||
U-Boot# |
|
||||||
[('tc_workfd_ssh.py', 1, 0), ('tc_workfd_connect_with_kermit.py', 1, 0), ('tc_ub_setenv.py', 1, 0)] |
|
||||||
End of TBOT: success |
|
||||||
hs@localhost:tbot [event-devel] $ |
|
Loading…
Reference in new issue