Lines Matching refs:to
7 This tool aims to test U-Boot by executing U-Boot shell commands using the
8 console interface. A single top-level script exists to execute or attach to the
14 - There is no need to write or embed test-related code into U-Boot itself.
17 - It is reasonably simple to interact with U-Boot in this way.
24 need to implement various "hook" scripts that are called by the test suite at
27 In order to run the test suite at a minimum we require that both Python 3 and
36 In order to execute certain tests on their supported platforms other tools
54 Please use the appropriate commands for your distribution to match these tools
61 - Executing an external "hook" scripts to flash a U-Boot binary onto a
62 physical board, attach to the board's console stream, and reset the board.
65 Using `virtualenv` to provide requirements
68 The recommended way to run the test suite, in order to ensure reproducibility
69 is to use `virtualenv` to set up the necessary environment. This can be done
75 $ cd /path/to/u-boot
95 The `--build` option tells U-Boot to compile U-Boot. Alternatively, you may
99 The test script will attach to U-Boot, execute all valid tests for the board,
101 will be written to `${build_dir}/test-log.html`. This is best viewed in a web
108 If you need to run sandbox under a debugger, you may pass the command-line
109 option `--gdbserver COMM`. This causes two things to happens:
112 debug communication via the channel `COMM`. You can attach a debugger to the
113 sandbox process in order to debug it. See `man gdbserver` and the example
116 time to execute commands. This is useful if U-Boot is stopped at a breakpoint
139 Some tests deliberately cause the sandbox process to exit, e.g. to test the
141 to attach the debugger to the new sandbox instance. If these tests are not
142 relevant to your debugging session, you can skip them using pytest's -k
149 set the type of the board to be tested. For example, `sandbox` or `seaboard`.
152 sets the identity of the board to be tested. This allows differentiation
154 attached to the same host machine. This parameter is not interpreted by th
155 test script in any way, but rather is simply passed to the hook scripts
164 indicates that `--build` should use buildman to build U-Boot. There is no need
165 to set $CROSS_COMPILE` in this case since buildman handles it.
172 sets the directory to write results, such as log files, into.
176 sets the directory used to store persistent test data. This is test data that
182 test.py script passes all command-line arguments directly to `pytest` for
186 selects which tests to run. The default is to run all known tests. This
187 option takes a single argument which is used to filter test names. Simple
192 case, "ut_dm" is a parameter to a test rather than the test name. The full
200 prevents pytest from hiding a test's stdout. This allows you to see
206 The tools and techniques used to interact with real hardware will vary
208 For this reason, the test suite does not attempt to directly interact with real
212 unrelated to U-Boot features.
226 - `UBOOT_TEST_PY_DIR` the full path to `test/py/` in the source directory.
234 This script provides access to the U-Boot console. The script's stdin/stdout
235 should be connected to the board's console. This process should continue to run
242 If you are able to run U-Boot under a hardware simulator such as QEMU, then
245 cause U-Boot to start execution from scratch each time. Hopefully your
248 process to always communicate with the current simulator instance.
253 Prior to running the test suite against a board, some arrangement must be made
254 so that the board executes the particular U-Boot binary to be tested. Often
255 this involves writing the U-Boot binary to the board's flash ROM. The test
260 cause the newly flashed U-Boot binary to be executed.
266 board's flash prior to running the test suite.
267 - The board allows U-Boot to be downloaded directly into RAM, and executed
274 It is up to the user to determine if those situations exist, and to code this
277 This script will typically be implemented by calling out to some SoC- or
283 Whenever the test suite needs to reset the target board, this script is
284 executed. This is guaranteed to happen at least once, prior to executing the
286 this script again to restore U-Boot to an operational state before running the
290 relay or electronic switch attached to the board's reset signal.
293 start running from scratch. If the U-Boot binary to be tested has been written
294 to flash, pulsing the board's reset signal is likely all this script needs to
296 example, it may call out to some SoC- or board-specific vendor utility in order
297 to download the U-Boot binary directly into RAM and execute it. This would
298 avoid the need for `u-boot-test-flash` to actually write U-Boot to flash, thus
316 to provide board-specific information to the test script. Any global value
331 `u_boot_boardenv_${board_type}_${board_identity}` may exist to provide
332 board-specific and board-identity-specific information to the test script. Any
334 function. The data contained in these is specific to a particular user's
337 should set `$PYTHONPATH` prior to running the test script to allow these
338 modules to be loaded.
352 order to test those features, or indirectly in order to query information from
353 the running U-Boot instance in order to test other features.
356 address to use for the test. This data is parsed from the output of the
381 If you want the test script to compile U-Boot for you too, then you likely
382 need to set `$CROSS_COMPILE` to allow this, and invoke the test script as
392 or, using buildman to handle it:
403 Please refer to the pytest documentation for details of writing pytest tests.
404 Details specific to the U-Boot test suite are described below.
407 provides the means to interact with the U-Boot console, and retrieve board and
414 error messages and the U-Boot sign-on message (in order to detect unexpected
416 "bad" strings. Some test scenarios are expected to trigger these strings. Use
417 `u_boot_console.disable_check()` to temporarily disable checking for specific
425 `u_boot_console.config.buildconfig`, with keys equal to the Kconfig variable