NXP官方的u-boot 5.4启动文件

# U-Boot pytest suite ## Introduction 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 than writing it all in C. - It is reasonably simple to interact with U-Boot in this way. ## Requirements The test suite is implemented using pytest. Interaction with the U-Boot console involves executing some binary and interacting with its stdin/stdout. You will need to implement various "hook" scripts that are called by the test suite at the appropriate time. In order to run the testsuite at a minimum we require that both python3 and pip for python3 be installed. All of the required python modules are described in the requirements.txt file in this directory and can be installed with the command ```pip install -r requirements.txt``` In order to execute certain tests on their supported platforms other tools will be required. The following is an incomplete list: | Package | | -------------- | | gdisk | | dfu-util | | dtc | | openssl | | sudo OR guestmount | | e2fsprogs | | dosfstools | Please use the apporirate commands for your distribution to match these tools up with the package that provides them. The test script supports either: - Executing a sandbox port of U-Boot on the local machine as a sub-process, and interacting with it over stdin/stdout. - Executing an external "hook" scripts to flash a U-Boot binary onto a physical board, attach to the board's console stream, and reset the board. Further details are described later. ### Using `virtualenv` to provide requirements The recommended way to run the test suite, in order to ensure reproducibility is to use `virtualenv` to set up the necessary environment. This can be done via the following commands: ```bash $ cd /path/to/u-boot $ sudo apt-get install python3 python3-virtualenv $ virtualenv -p /usr/bin/python3 venv $ . ./venv/bin/activate $ pip install -r test/py/requirements.txt ``` ## Testing sandbox To run the testsuite on the sandbox port (U-Boot built as a native user-space application), simply execute: ``` ./test/py/test.py --bd sandbox --build ``` The `--bd` option tells the test suite which board type is being tested. This lets the test suite know which features the board has, and hence exactly what can be tested. The `--build` option tells U-Boot to compile U-Boot. Alternatively, you may omit this option and build U-Boot yourself, in whatever way you choose, before running the test script. The test script will attach to U-Boot, execute all valid tests for the board, then print a summary of the test process. A complete log of the test session will be written to `${build_dir}/test-log.html`. This is best viewed in a web browser, but may be read directly as plain text, perhaps with the aid of the `html2text` utility. ### Testing under a debugger If you need to run sandbox under a debugger, you may pass the command-line option `--gdbserver COMM`. This causes two things to happens: - Instead of running U-Boot directly, it will be run under gdbserver, with debug communication via the channel `COMM`. You can attach a debugger to the sandbox process in order to debug it. See `man gdbserver` and the example below for details of valid values for `COMM`. - All timeouts in tests are disabled, allowing U-Boot an arbitrary amount of time to execute commands. This is useful if U-Boot is stopped at a breakpoint during debugging. A usage example is: Window 1: ```shell ./test/py/test.py --bd sandbox --gdbserver localhost:1234 ``` Window 2: ```shell gdb ./build-sandbox/u-boot -ex 'target remote localhost:1234' ``` Alternatively, you could leave off the `-ex` option and type the command manually into gdb once it starts. You can use any debugger you wish, so long as it speaks the gdb remote protocol, or any graphical wrapper around gdb. Some tests deliberately cause the sandbox process to exit, e.g. to test the reset command, or sandbox's CTRL-C handling. When this happens, you will need to attach the debugger to the new sandbox instance. If these tests are not relevant to your debugging session, you can skip them using pytest's -k command-line option; see the next section. ## Command-line options - `--board-type`, `--bd`, `-B` set the type of the board to be tested. For example, `sandbox` or `seaboard`. - `--board-identity`, `--id` set the identity of the board to be tested. This allows differentiation between multiple instances of the same type of physical board that are attached to the same host machine. This parameter is not interpreted by the test script in any way, but rather is simply passed to the hook scripts described below, and may be used in any site-specific way deemed necessary. - `--build` indicates that the test script should compile U-Boot itself before running the tests. If using this option, make sure that any environment variables required by the build process are already set, such as `$CROSS_COMPILE`. - `--build-dir` sets the directory containing the compiled U-Boot binaries. If omitted, this is `${source_dir}/build-${board_type}`. - `--result-dir` sets the directory to write results, such as log files, into. If omitted, the build directory is used. - `--persistent-data-dir` sets the directory used to store persistent test data. This is test data that may be re-used across test runs, such as file- system images. `pytest` also implements a number of its own command-line options. Commonly used options are mentioned below. Please see `pytest` documentation for complete details. Execute `py.test --version` for a brief summary. Note that U-Boot's test.py script passes all command-line arguments directly to `pytest` for processing. - `-k` selects which tests to run. The default is to run all known tests. This option takes a single argument which is used to filter test names. Simple logical operators are supported. For example: - `'ums'` runs only tests with "ums" in their name. - `'ut_dm'` runs only tests with "ut_dm" in their name. Note that in this case, "ut_dm" is a parameter to a test rather than the test name. The full test name is e.g. "test_ut[ut_dm_leak]". - `'not reset'` runs everything except tests with "reset" in their name. - `'ut or hush'` runs only tests with "ut" or "hush" in their name. - `'not (ut or hush)'` runs everything except tests with "ut" or "hush" in their name. - `-s` prevents pytest from hiding a test's stdout. This allows you to see U-Boot's console log in real time on pytest's stdout. ## Testing real hardware The tools and techniques used to interact with real hardware will vary radically between different host and target systems, and the whims of the user. For this reason, the test suite does not attempt to directly interact with real hardware in any way. Rather, it executes a standardized set of "hook" scripts via `$PATH`. These scripts implement certain actions on behalf of the test suite. This keeps the test suite simple and isolated from system variances unrelated to U-Boot features. ### Hook scripts #### Environment variables The following environment variables are set when running hook scripts: - `UBOOT_BOARD_TYPE` the board type being tested. - `UBOOT_BOARD_IDENTITY` the board identity being tested, or `na` if none was specified. - `UBOOT_SOURCE_DIR` the U-Boot source directory. - `UBOOT_TEST_PY_DIR` the full path to `test/py/` in the source directory. - `UBOOT_BUILD_DIR` the U-Boot build directory. - `UBOOT_RESULT_D