]> git.dujemihanovic.xyz Git - u-boot.git/commit
test: Introduce lab mode
authorSimon Glass <sjg@chromium.org>
Tue, 12 Nov 2024 14:13:19 +0000 (07:13 -0700)
committerTom Rini <trini@konsulko.com>
Wed, 13 Nov 2024 18:01:35 +0000 (12:01 -0600)
commit8308a5eed6e6310625465449916f25b5f9a844c9
tree862de397fc28432c9806f455e5979bc424739d63
parentbf89a8f1fc21cd9574416c4d452d3c4033f0ce08
test: Introduce lab mode

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>
test/py/u_boot_console_base.py