26 Nov, 2018

1 commit


11 Jul, 2018

2 commits

  • In python 3.x the xrange() function has been removed, and range()
    returns an iterator much like Python 2.x's xrange(). Simply use range()
    in place of xrange() in order to work on both python 2.x & 3.x. This
    will mean a small cost on python 2.x since range() will return a list
    there rather than an iterator, but the cost should be negligible.

    Signed-off-by: Paul Burton
    Reviewed-by: Stephen Warren

    Paul Burton
     
  • In python 3.x print must be called as a function rather than used as a
    statement. Update uses of print to the function call syntax in order to
    be python 3.x safe.

    Signed-off-by: Paul Burton
    Reviewed-by: Stephen Warren

    Paul Burton
     

07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

15 Jul, 2016

3 commits


12 Apr, 2016

1 commit


08 Feb, 2016

1 commit

  • Implement command--line option --gdbserver COMM, which does two things:

    a) Run the sandbox process under gdbserver, using COMM as gdbserver's
    communication channel.

    b) Disables all timeouts, so that if U-Boot is halted under the debugger,
    tests don't fail. If the user gives up in the middle of a debugging
    session, they can simply CTRL-C the test script to abort it.

    This allows easy debugging of test failures without having to manually
    re-create the failure conditions. Usage is:

    Window 1:
    ./test/py/test.py --bd sandbox --gdbserver localhost:1234

    Window 2:
    gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234'

    When using this option, it likely makes sense to use pytest's -k option
    to limit the set of tests that are executed.

    Simply running U-Boot directly under gdb (rather than gdbserver) was
    also considered. However, this was rejected because:

    a) gdb's output would then be processed by the test script, and likely
    confuse it causing false failures.

    b) pytest by default hides stdout from tests, which would prevent the
    user from interacting with gdb.

    While gdb can be told to redirect the debugee's stdio to a separate
    PTY, this would appear to leave gdb's stdio directed at the test
    scripts and the debugee's stdio directed elsewhere, which is the
    opposite of the desired effect. Perhaps some complicated PTY muxing
    and process hierarchy could invert this. However, the current scheme
    is simple to implement and use, so it doesn't seem worth complicating
    matters.

    c) Using gdbserver allows arbitrary debuggers to be used, even those with
    a GUI. If the test scripts invoked the debugger themselves, they'd have
    to know how to execute arbitary applications. While the user could hide
    this all in a wrapper script, this feels like extra complication.

    An interesting future idea might be a --gdb-screen option, which could
    spawn both U-Boot and gdb separately, and spawn the screen into a newly
    created window under screen. Similar options could be envisaged for
    creating a new xterm/... too.

    --gdbserver currently only supports sandbox, and not real hardware.
    That's primarily because the test hooks are responsible for all aspects of
    hardware control, so there's nothing for the test scripts themselves can
    do to enable gdbserver on real hardware. We might consider introducing a
    separate --disable-timeouts option to support use of debuggers on real
    hardware, and having --gdbserver imply that option.

    Signed-off-by: Stephen Warren

    Stephen Warren
     

29 Jan, 2016

4 commits

  • Some unit tests expect the cwd of the sandbox process to be the root
    of the source tree. Ensure that requirement is met.

    Signed-off-by: Stephen Warren
    Acked-by: Simon Glass

    Stephen Warren
     
  • This is required for at least "ut dm" to operate correctly.

    Signed-off-by: Stephen Warren
    Acked-by: Simon Glass

    Stephen Warren
     
  • Python's coding style docs indicate to use " not ' for docstrings.

    test/py has other violations of the coding style docs, since the docs
    specify a stranger style than I would expect, but nobody has complained
    about those yet:-)

    Signed-off-by: Stephen Warren
    Reviewed-by: Simon Glass

    Stephen Warren
     
  • Prior to this change, U-Boot was lazilly (re-)spawned if/when a test
    attempted to interact with it, and no active connection existed. This
    approach was simple, yet had the disadvantage that U-Boot might be
    spawned in the middle of a test function, e.g. after the test had already
    performed actions such as creating data files, etc. In that case, this
    could cause the log to contain the sequence (1) some test logs, (2)
    U-Boot's boot process, (3) the rest of that test's logs. This isn't
    optimally readable. This issue will affect the upcoming DFU and enhanced
    UMS tests.

    This change converts u_boot_console to be a function-scoped fixture, so
    that pytest attempts to re-create the object for each test invocation.
    This allows the fixture factory function to ensure that U-Boot is spawned
    prior to every test. In practice, the same object is returned each time
    so there is essentially no additional overhead due to this change.

    This allows us to remove:

    - The explicit ensure_spawned() call from test_sleep, since the core now
    ensures that the spawn happens before the test code is executed.

    - The laxy calls to ensure_spawned() in the u_boot_console_*
    implementations.

    The one downside is that test_env's "state_ttest_env" fixture must be
    converted to a function-scoped fixture too, since a module-scoped fixture
    cannot use a function-scoped fixture. To avoid overhead, we use the same
    trick of returning the same object each time.

    Signed-off-by: Stephen Warren
    Acked-by: Simon Glass

    Stephen Warren
     

21 Jan, 2016

1 commit

  • This tool aims to test U-Boot by executing U-Boot shell commands using the
    console interface. A single top-level script exists to execute or attach
    to the U-Boot console, run the entire script of tests against it, and
    summarize the results. Advantages of this approach are:

    - Testing is performed in the same way a user or script would interact
    with U-Boot; there can be no disconnect.
    - There is no need to write or embed test-related code into U-Boot itself.
    It is asserted that writing test-related code in Python is simpler and
    more flexible that writing it all in C.
    - It is reasonably simple to interact with U-Boot in this way.

    A few simple tests are provided as examples. Soon, we should convert as
    many as possible of the other tests in test/* and test/cmd_ut.c too.

    The hook scripts, relay control utilities, and udev rules I use for my
    own HW setup are published at https://github.com/swarren/uboot-test-hooks.

    See README.md for more details!

    Signed-off-by: Stephen Warren
    Signed-off-by: Stephen Warren
    Tested-by: Michal Simek
    Tested-by: Simon Glass
    Acked-by: Simon Glass #v3

    Stephen Warren