We know this is U-Boot so the prefix serves no purpose other than to
make things longer and harder to read. Drop it and rename the files.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # test_android / test_dfu

When a timeout occurs while executing a command a 'Boot fail' message is
written and testing is stopped. The user is left in the dark about the
failure cause.

    ! _pytest.outcomes.Exit: Boot fail: Marking connection bad - no other tests will run !

Add the executed command to the message.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>

When a timeout occurs while executing a command a 'Lab failure' message is
written and testing is stopped. The user is left in the dark about the
failure cause.

    ! _pytest.outcomes.Exit: Lab failure: Marking connection bad - no other tests will run !

Add the word 'Timeout' and the executed command to the message.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

This can take a while and involve multiple steps (e.g. turning the board
back off). Add a section for it and show the output.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

We expect commands to be echoed and this should happen quite quickly,
since U-Boot is sitting at the prompt waiting for a command.

Reduce the timeout for this situation. Try to produce a more useful
error message when something goes wrong. Also handle the case where the
connection has gone away since the last command was issued.

Signed-off-by: Simon Glass <sjg@chromium.org>

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>

Sometimes we know that the board is already running the right software,
so provide an option to allow running of tests directly, without first
resetting the board.

This saves time when re-running a test where only the Python code is
changing.

Note that this feature is open to errors, since the user must know that
the board is in a fit state to execute tests. It is useful for repeated
iteration on a particular test, where it can save quite a bit of time.

Signed-off-by: Simon Glass <sjg@chromium.org>

When Labgrid is used, it can get U-Boot ready for running tests. It
prints a message when it has done so.

Add logic to detect this message and accept it.

Note that this does not change pytest, which still (also) looks for the
U-Boot banner. This change merely makes it possible for pytest to
believe Labgrid when it says that the board is ready for use.

In several cases, the board starts up and Labgrid receives some initial
output, then pytest starts and misses some of that output, because it
came in while Labgrid had the console open. Then pytest fails because
it doesn't see the expected banners.

With this change, Labgrid handles getting U-Boot to a prompt, in a
fully reliable manner. Then pytest starts up and can simply start
running its tests.

But, again, this does not prevent pytest from handling a banner if one
is provided (e.g. if not using the Labgrid integration).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Fix a typo in a comment.

Signed-off-by: Simon Glass <sjg@chromium.org>

Use the new handle_exception() function from ConsoleBase also.

Signed-off-by: Simon Glass <sjg@chromium.org>