# 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.
On Debian or Debian-like distributions, the following packages are required.
Some packages are required to execute any test, and others only for specific
tests. Similar package names should exist in other distributions.
| Package | Version tested (Ubuntu 14.04) |
| -------------- | ----------------------------- |
| python | 2.7.5-5ubuntu3 |
| python-pytest | 2.5.1-1 |
| gdisk | 0.8.8-1ubuntu0.1 |
| dfu-util | 0.5-1 |
| dtc | 1.4.0+dfsg-1 |
| openssl | 1.0.1f-1ubuntu2.22 |
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
Older distributions (e.g. Ubuntu 10.04) may not provide all the required
packages, or may provide versions that are too old to run the test suite. One
can use the Python `virtualenv` script to locally install more up-to-date
versions of the required packages without interfering with the OS installation.
For example:
```bash
$ cd /path/to/u-boot
$ sudo apt-get install python python-virtualenv
$ virtualenv venv
$ . ./venv/bin/activate
$ pip install pytest
```
## 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.
- `
没有合适的资源?快使用搜索试试~ 我知道了~
Xilinx 系列芯片移植uboot源码
共2000个文件
h:1733个
c:193个
py:63个
需积分: 5 0 下载量 105 浏览量
2023-09-03
22:25:52
上传
评论
收藏 34.39MB RAR 举报
温馨提示
uboot 针对zynq 7020已经完成编译,可直接用于移植和源码解读。
资源推荐
资源详情
资源评论
收起资源包目录
Xilinx 系列芯片移植uboot源码 (2000个子文件)
deflate.c 66KB
efi_boottime.c 58KB
mxsimage.c 50KB
trees.c 44KB
bzlib.c 43KB
fw_env.c 37KB
bch.c 35KB
inflate.c 34KB
fdtdec.c 33KB
bzlib_blocksort.c 32KB
tpm.c 30KB
ifdtool.c 28KB
imximage.c 27KB
LzmaDec.c 27KB
hashtable.c 24KB
remote.c 23KB
aes.c 23KB
bzlib_compress.c 22KB
fit_image.c 20KB
image-host.c 20KB
bzlib_decompress.c 19KB
fdt_region.c 18KB
vsprintf.c 18KB
mkimage.c 17KB
rsa-sign.c 16KB
efi_device_path.c 15KB
fdt_ro.c 14KB
rbtree.c 14KB
slre.c 14KB
string.c 14KB
kwboot.c 13KB
inftrees.c 13KB
inffast.c 13KB
dhry_1.c 13KB
proftool.c 13KB
efi_console.c 13KB
efi_memory.c 12KB
sunxi-spl-image-builder.c 12KB
fdt_rw.c 12KB
efi_file.c 12KB
efi_selftest_devicepath.c 11KB
crc32.c 10KB
efi_net.c 10KB
efi_runtime.c 10KB
sha1.c 10KB
efi_disk.c 10KB
efi_selftest_snp.c 10KB
efi_selftest_manageprotocols.c 10KB
mips-relocs.c 9KB
trace.c 9KB
md5.c 9KB
efi_stub.c 9KB
rsa-mod-exp.c 9KB
lz4.c 9KB
lmb.c 8KB
membuff.c 8KB
sha256.c 8KB
uuid.c 8KB
mkenvimage.c 8KB
zynqimage.c 8KB
of_live.c 8KB
smbios.c 8KB
efi_selftest.c 8KB
efi_device_path_to_text.c 8KB
pblimage.c 7KB
tiny-printf.c 7KB
list_sort.c 7KB
atmelimage.c 7KB
efi_variable.c 7KB
lzo1x_decompress.c 7KB
bzlib_huffman.c 7KB
rsa-verify.c 7KB
fw_env_main.c 7KB
gunzip.c 7KB
socfpgaimage.c 6KB
bzlib_crctable.c 6KB
dhry_2.c 6KB
errno_str.c 6KB
ublimage.c 6KB
efi_image_loader.c 6KB
efi_selftest_tpl.c 6KB
efi_selftest_watchdog.c 6KB
clocks_get_m_n.c 6KB
bzlib_randtable.c 5KB
efi_selftest_events.c 5KB
fdtdec_test.c 5KB
mkexynosspl.c 5KB
efi_gop.c 5KB
dumpimage.c 5KB
efi_bootmgr.c 4KB
display_options.c 4KB
vybridimage.c 4KB
div64.c 4KB
efi_selftest_console.c 4KB
adler32.c 4KB
LzmaTools.c 4KB
efi_app.c 3KB
lz4_wrapper.c 3KB
strto.c 3KB
charset.c 3KB
共 2000 条
- 1
- 2
- 3
- 4
- 5
- 6
- 20
资源评论
大裤衩儿
- 粉丝: 24
- 资源: 13
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功