mirror of
https://github.com/u-boot/u-boot.git
synced 2025-04-17 18:34:42 +00:00
8308a5eed6
There is quite a bit of code in pytest to try to start up U-Boot on a
board, with timeouts, expects, etc.
This is tedious to maintain and is peripheral to the test system's
purpose. It seems better to put this logic in the lab itself, where is
can provide such support.
With Labgrid we can use the UbootStrategy class to get the board into a
useful state, however it needs to do it. Then it can report to pytest
by writing a suitable string along with the U-Boot version it detected.
Add support for detecting 'lab mode' and simply assume that all is well
in that case. Collect the version string when Labgrid says it is ready.
This is only used with the Labgrid-sjg integration. When Labgrid starts
the UbootStrategy it checks if U_BOOT_SOURCE_DIR is set. If so it emits
a string '{lab mode}' that tells test.py to simply wait for an
indication that the board is ready. All banner-checking is skipped. The
indication comes in the form of another string 'Lab: Board is ready'
which Labgrid sends once the board is sitting at a prompt ready to run
tests. Then test.py emits 'U-Boot is ready' and continues with testing.
Note that Labgrid has the same kind of "check for a string" logic that
is in test.py, except it's not caring about the correct number / order
of banner prints. This checking could be added, however. If something
fails, the complete output is shown, so it is possible to see what went
wrong.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
||
|---|---|---|
| .. | ||
| tests | ||
| .gitignore | ||
| conftest.py | ||
| multiplexed_log.css | ||
| multiplexed_log.py | ||
| pytest.ini | ||
| requirements.txt | ||
| test.py | ||
| u_boot_console_base.py | ||
| u_boot_console_exec_attach.py | ||
| u_boot_console_sandbox.py | ||
| u_boot_spawn.py | ||
| u_boot_utils.py | ||