Fork of the vendor (Boundary Devices) u-boot for Reform 2, with minor tweaks. The goal is to migrate to mainstream u-boot or barebox ASAP. The main impediment so far is the 4GB RAM config.
No puede seleccionar más de 25 temas Los temas deben comenzar con una letra o número, pueden incluir guiones ('-') y pueden tener hasta 35 caracteres de largo.
Este repositorio está archivado. Puede ver los archivos y clonarlo, pero no puede subir cambios o reportar incidencias ni pedir Pull Requests.

  1. # Copyright (c) 2016 DENX Software Engineering GmbH
  2. # Heiko Schocher <>
  3. #
  4. # SPDX-License-Identifier: GPL-2.0+
  5. #
  6. What is tbot ?
  7. ==============
  8. tbot is a tool for executing testcases on boards.
  9. Source code found on [1]
  10. Based on DUTS [2]
  11. written in python
  12. Basic Ideas of tbot
  13. ===================
  14. (see also the figure:
  15. )
  16. - Virtual laboratory (VL)
  17. VL is the basic environment that groups:
  18. - [a number of] boards - target devices on which tbot executes testcases.
  19. - one Lab PC
  20. - Test case (TC):
  21. A piece of python code, which uses the tbot class from [1].
  22. Tbot provides functions for sending shell commands and parsing the
  23. shell commands output.
  24. Tbot waits endless for a shell commands end (detected through reading
  25. the consoles prompt).
  26. A TC can also call other TC-es.
  27. remark:
  28. Tbot not really waits endless, for a shell commands end, instead
  29. tbot starts a watchdog in the background, and if it triggers, tbot
  30. ends the TC as failed. In the tbot beginning there was a lot of
  31. timeouts / retry cases, but it turned out, that waiting endless
  32. is robust and easy ...
  33. - Host PC (where tbot runs, currently only linux host tested)
  34. must not a powerful machine (For example [3], I use a
  35. raspberry pi for running tbot and buildbot)
  36. - Lab PC:
  37. - Host PC connects through ssh to the Lab PC
  38. -> so it is possible to test boards, which
  39. are not at the same place as the Host PC.
  40. (Lab PC and Host PC can be the same of course)
  41. -> maybe we can setup a Testsystem, which does nightly
  42. U-Boot/Linux builds and test from current mainline U-Boot
  43. on boards wherever they are accessible.
  44. - necessary tasks a Lab PC must deliver:
  45. - connect to boards console through a shell command.
  46. - power on/off boards through a shell command
  47. - detect the current power state of a board through
  48. a shell command
  49. - optional tasks:
  50. - tftp server (for example loading images)
  51. - nfs server (used as rootfs for linux kernels)
  52. - Internet access for example for downloading
  53. U-Boot source with git.
  54. - toolchains installed for compiling source code
  55. -> a linux machine is preffered.
  56. - currently only Lab PC with an installed linux supported/tested.
  57. - Boards(s):
  58. the boards on which shell commands are executed.
  59. - Board state:
  60. equals to the software, the board is currently running.
  61. Currently tbot supports 2 board states:
  62. - "u-boot", if the board is running U-Boot
  63. - "linux", if the board is running a linux kernel
  64. It should be easy to add other board states to tbot, see
  66. A board state is detected through analysing the boards
  67. shell prompt. In linux, tbot sets a special tbot prompt,
  68. in U-Boot the prompt is static, and configurable in tbot through
  69. a board config file.
  70. A TC can say in which board state it want to send shell commands.
  71. Tbot tries to detect the current board state, if board is not in
  72. the requested board state, tbot tries to switch into the correct
  73. state. If this fails, the TC fails.
  74. It is possible to switch in a single TC between board states.
  75. - Events
  76. tbot creates while executing testcases so called events.
  77. After tbot ended with the testcase it can call event_backends,
  78. which convert the events to different formats. more info:
  80. demo for a event backend:
  82. - tbot cmdline parameters:
  83. $ python2.7 src/common/ --help
  84. Usage: [options]
  85. Options:
  86. -h, --help show this help message and exit
  87. -c CFGFILE, --cfgfile=CFGFILE
  88. the tbot common configfilename
  89. -l LOGFILE, --logfile=LOGFILE
  90. the tbot logfilename, if default, tbot creates a
  91. defaultnamelogfile
  92. -t TC, --testcase=TC the testcase which should be run
  93. -v, --verbose be verbose, print all read/write to stdout
  94. -w WORKDIR, --workdir=WORKDIR
  95. set workdir, default os.getcwd()
  96. $
  97. tbot needs the following files for proper execution:
  98. - tbot board configuration file (option -c):
  99. A board configuration file contains settings tbot needs to
  100. connect to the Lab PC and board specific variable settings
  101. for testcases.
  102. - name of the logfile tbot creates (option -l)
  103. defaultname: 'log/' + now.strftime("%Y-%m-%d-%H-%M") + '.log'
  104. - tbots working directory (option -w)
  105. - the testcasename tbot executes (option -t)
  106. You are interested and want to use tbot?
  107. If so, please read on the file:
  108. tools/tbot/README.install
  109. If not read [3] ;-)
  110. Heiko Schocher <>
  111. v1 2016.01.22
  112. --------------
  113. [1]
  114. [2]
  115. [3] automated Testsetup with buildbot and tbot doing cyclic tests
  116. (buildbot used for starting tbot TC and web presentation of the
  117. results, all testing done through tbot):
  119. Host PC in Letkes/hungary
  120. VL in munich/germany
  121. Fancy things are done here, for example:
  122. -
  123. (I try to cleanup the logfile soon, so it is not so filled with crap ;-)
  124. A first step see here:
  126. (same TC now with the new loglevel = 'CON' ... not yet perfect)
  127. Executed steps:
  128. - clone u-boot.git
  129. - set toolchain
  130. - get a list of patchwork patches from my U-Boots ToDo list
  131. - download all of them, and check them with checkpatch
  132. and apply them to u-boot.git
  133. - compile U-Boot for the smartweb board
  134. - install the resulting images on the smartweb board
  135. - boot U-boot
  136. - test DFU
  137. - more TC should be added here for testing U-Boot
  138. - automatic "git bisect"
  141. If a current U-Boot image not works on the tqm5200 board
  142. this TC can be started. It starts a "git bisect" session,
  143. and compiles for each step U-Boot, install it on the tqm5200
  144. board, and tests if U-Boot works !
  145. At the end, it detects the commit, which breaks the board
  146. This TC is not dependend on U-Boot nor on a special board. It
  147. needs only 3 variables:
  148. tb.board_git_bisect_get_source_tc: TC which gets the source tree, in which
  149. "git bisect" should be executed
  150. tb.board_git_bisect_call_tc: TC which gets called every "git bisect" step,
  151. which executes commands for detecting if current source code is OK or not.
  152. This could be a TC which compiles U-Boot, install it on the board and
  153. executes TC on the new booted U-Boot image. ! Board maybe gets borken,
  154. as not all U-Boot images work, so you must have a TC which install U-Boot
  155. image for example through a debugger.
  156. tb.board_git_bisect_good_commit: last nown good commit id