@@ -17,6 +17,12 @@ of the sandbox U-Boot. The purpose of running U-Boot under Linux is to test
all the generic code, not specific to any one architecture. The idea is to
create unit tests which we can run to test this upper level code.
+Sandbox allows development of many types of new features in a traditional way,
+rather than needing to test each iteration on real hardware. Many U-Boot
+features were developed on sandbox, including the core driver model, most
+uclasses, verified boot, bloblist, logging and dozens of others. Sandbox has
+enabled many large-scale code refactors as well.
+
CONFIG_SANDBOX is defined when building a native board.
The board name is 'sandbox' but the vendor name is unset, so there is a
@@ -486,42 +492,10 @@ Testing
-------
U-Boot sandbox can be used to run various tests, mostly in the test/
-directory. These include:
-
-command_ut:
- Unit tests for command parsing and handling
-compression:
- Unit tests for U-Boot's compression algorithms, useful for
- security checking. It supports gzip, bzip2, lzma and lzo.
-driver model:
- Run this pytest::
-
- ./test/py/test.py --bd sandbox --build -k ut_dm -v
-
-image:
- Unit tests for images:
- test/image/test-imagetools.sh - multi-file images
- test/image/test-fit.py - FIT images
-tracing:
- test/trace/test-trace.sh tests the tracing system (see README.trace)
-verified boot:
- See test/vboot/vboot_test.sh for this
-
-If you change or enhance any of the above subsystems, you shold write or
-expand a test and include it with your patch series submission. Test
-coverage in U-Boot is limited, as we need to work to improve it.
-
-Note that many of these tests are implemented as commands which you can
-run natively on your board if desired (and enabled).
-
-To run all tests use "make check".
-
-To run a single test in an existing sandbox build, you can use -T to use the
-test device tree, and -c to select the test:
-
- /tmp/b/sandbox/u-boot -T -c "ut dm pci_busdev"
+directory.
-This runs dm_test_pci_busdev() which is in test/dm/pci.c
+See :doc:`../develop/tests_sandbox` for more information and
+:doc:`../develop/testing` for information about testing generally.
Memory Map
@@ -1,7 +1,47 @@
.. SPDX-License-Identifier: GPL-2.0+
-Tests Under the Hood
-====================
+Sandbox tests
+=============
+
+Test Design
+-----------
+
+Most uclasses and many functions of U-Boot have sandbox tests. This allows much
+of the code to be checked in an developer-friendly environment.
+
+Sandbox provides a way to write and run unit tests. The traditional approach to
+unit tests is to build lots of little executables, one for each test or
+category of tests. With sandbox, so far as possible, all the tests share a
+small number of executables (e.g. 'u-boot' for sandbox, 'u-boot-spl' and
+'u-boot' for sandbox_spl) and can be run very quickly. The vast majority of
+tests can run on the 'sandbox' build,
+
+Available tests
+---------------
+
+Some of the available tests are:
+
+ - command_ut: Unit tests for command parsing and handling
+ - compression: Unit tests for U-Boot's compression algorithms, useful for
+ security checking. It supports gzip, bzip2, lzma and lzo.
+ - image: Unit tests for images:
+
+ - test/image/test-imagetools.sh - multi-file images
+ - test/py/tests/test-fit.py - FIT images
+ - tracing: test/trace/test-trace.sh tests the tracing system (see
+ README.trace)
+ - verified boot: test/py/tests/test_vboot.py
+
+If you change or enhance any U-Boot subsystem, you should write or expand a
+test and include it with your patch series submission. Test coverage in some
+older areas of U-Boot is still somewhat limited and we need to work to improve
+it.
+
+Note that many of these tests are implemented as commands which you can
+run natively on your board if desired (and enabled).
+
+To run all tests, use 'make check'.
+
Running sandbox tests directly
------------------------------
At present some of the documentation about running sandbox tests is in the sandbox docs. It makes more sense to put it in with the other testing docs, with a link there from sandbox. Update the documentation accordingly. Also add a paragraph explaining why sandbox exists and the test philosophy that it uses. Signed-off-by: Simon Glass <sjg@chromium.org> --- (no changes since v1) doc/arch/sandbox.rst | 44 +++++++---------------------------- doc/develop/tests_sandbox.rst | 44 +++++++++++++++++++++++++++++++++-- 2 files changed, 51 insertions(+), 37 deletions(-)