diff options
Diffstat (limited to 'doc/develop')
| -rw-r--r-- | doc/develop/bootstd/overview.rst | 5 | ||||
| -rw-r--r-- | doc/develop/driver-model/design.rst | 6 | ||||
| -rw-r--r-- | doc/develop/py_testing.rst | 41 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 2 | ||||
| -rw-r--r-- | doc/develop/tests_writing.rst | 64 |
5 files changed, 57 insertions, 61 deletions
diff --git a/doc/develop/bootstd/overview.rst b/doc/develop/bootstd/overview.rst index e3ce97cc4f5..9fe5630ab16 100644 --- a/doc/develop/bootstd/overview.rst +++ b/doc/develop/bootstd/overview.rst @@ -235,8 +235,9 @@ means that `default_get_bootflow()` is used. This simply obtains the block device and calls a bootdev helper function to do the rest. The implementation of `bootdev_find_in_blk()` checks the partition table, and attempts to read a file from a filesystem on the partition number given by the -`@iter->part` parameter. If there are any bootable partitions in the table, -then only bootable partitions are considered. +`@iter->part` parameter. If there are any bootable partitions in the table and +the BOOTFLOWIF_ONLY_BOOTABLE flag is set in `@iter->flags`, then only bootable +partitions are considered. Each bootdev has a priority, which indicates the order in which it is used, if `boot_targets` is not used. Faster bootdevs are used first, since they are diff --git a/doc/develop/driver-model/design.rst b/doc/develop/driver-model/design.rst index 92f638a0204..30093737200 100644 --- a/doc/develop/driver-model/design.rst +++ b/doc/develop/driver-model/design.rst @@ -843,8 +843,10 @@ steps (see device_probe()): activated and 'known' by the uclass. For some platforms, certain devices must be probed to get the platform into -a working state. To help with this, drivers marked with DM_FLAG_PROBE_AFTER_BIND -will be probed immediately after all devices are bound. For now, this happens in +a working state. To help with this, devices marked with DM_FLAG_PROBE_AFTER_BIND +will be probed immediately after all devices are bound. This flag must be set +on the device in its ``bind()`` function with +``dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND)``. For now, this happens in SPL, before relocation and after relocation. See the call to ``dm_autoprobe()`` for where this is done. diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst index b50473039be..502053f09fc 100644 --- a/doc/develop/py_testing.rst +++ b/doc/develop/py_testing.rst @@ -41,13 +41,11 @@ will be required. The following is an incomplete list: * dfu-util * dtc * openssl -* sudo OR guestmount * e2fsprogs * util-linux * coreutils * dosfstools * efitools -* guestfs-tools * mount * mtools * sbsigntool @@ -64,23 +62,12 @@ The test script supports either: physical board, attach to the board's console stream, and reset the board. Further details are described later. -The usage of command 'sudo' should be avoided in tests. To create disk images -use command virt-make-fs which is provided by package guestfs-tools. This -command creates a virtual machine with QEMU in which the disk image is -generated. - -Command virt-make-fs needs read access to the current kernel. On Ubuntu only -root has this privilege. You can add a script /etc/initramfs-tools/hooks/vmlinuz -with the following content to overcome the problem: - -.. code-block:: bash - - #!/bin/sh - echo "chmod a+r vmlinuz-*" - chmod a+r /boot/vmlinuz-* - -The script should be chmod 755. It will be invoked whenever the initial RAM file -system is updated. +The usage of the command 'sudo' is not allowed in tests. Using elevated +priviledges can lead to security concerns. Furthermore not all users may have +administrator rights. Therefore the command 'sudo' must not be used in tests. +To create disk images we have helper functions located in +`test/py/tests/fs_helper.py` which shall be used in any tests that require +creating disk images. Using `virtualenv` to provide requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -125,7 +112,7 @@ browser, but may be read directly as plain text, perhaps with the aid of the If sandbox crashes (e.g. with a segfault) you will see message like this:: - test/py/u_boot_spawn.py:171: in expect + test/py/spawn.py:171: in expect c = os.read(self.fd, 1024).decode(errors='replace') E ValueError: U-Boot exited with signal 11 (Signals.SIGSEGV) @@ -506,24 +493,24 @@ Writing tests Please refer to the pytest documentation for details of writing pytest tests. Details specific to the U-Boot test suite are described below. -A test fixture named `u_boot_console` should be used by each test function. This +A test fixture named `ubman` should be used by each test function. This provides the means to interact with the U-Boot console, and retrieve board and environment configuration information. -The function `u_boot_console.run_command()` executes a shell command on the +The function `ubman.run_command()` executes a shell command on the U-Boot console, and returns all output from that command. This allows validation or interpretation of the command output. This function validates that certain strings are not seen on the U-Boot console. These include shell error messages and the U-Boot sign-on message (in order to detect unexpected -board resets). See the source of `u_boot_console_base.py` for a complete list of +board resets). See the source of `console_base.py` for a complete list of "bad" strings. Some test scenarios are expected to trigger these strings. Use -`u_boot_console.disable_check()` to temporarily disable checking for specific +`ubman.disable_check()` to temporarily disable checking for specific strings. See `test_unknown_cmd.py` for an example. Board- and board-environment configuration values may be accessed as sub-fields -of the `u_boot_console.config` object, for example -`u_boot_console.config.ram_base`. +of the `ubman.config` object, for example +`ubman.config.ram_base`. Build configuration values (from `.config`) may be accessed via the dictionary -`u_boot_console.config.buildconfig`, with keys equal to the Kconfig variable +`ubman.config.buildconfig`, with keys equal to the Kconfig variable names. diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst index b108f9b11e0..cbbc2bad0eb 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -53,7 +53,7 @@ Current Status * U-Boot v2025.04 was released on Monday, 07 April 2025. -* The Merge Window for the next release (v2025.04) is **open** until the -rc1 +* The Merge Window for the next release (v2025.07) is **open** until the -rc1 release on Monday, 28 April 2025. * The next branch is now **closed** until the -rc2 release on Monday, 12 May diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index 54efb7e1b04..7ea17081def 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -116,19 +116,19 @@ below are approximate, as measured on an AMD 2950X system. Here is is the test in Python:: @pytest.mark.buildconfigspec('cmd_memory') - def test_md(u_boot_console): + def test_md(ubman): """Test that md reads memory as expected, and that memory can be modified using the mw command.""" - ram_base = u_boot_utils.find_ram_base(u_boot_console) + ram_base = utils.find_ram_base(ubman) addr = '%08x' % ram_base val = 'a5f09876' expected_response = addr + ': ' + val - u_boot_console.run_command('mw ' + addr + ' 0 10') - response = u_boot_console.run_command('md ' + addr + ' 10') + ubman.run_command('mw ' + addr + ' 0 10') + response = ubman.run_command('md ' + addr + ' 10') assert(not (expected_response in response)) - u_boot_console.run_command('mw ' + addr + ' ' + val) - response = u_boot_console.run_command('md ' + addr + ' 10') + ubman.run_command('mw ' + addr + ' ' + val) + response = ubman.run_command('md ' + addr + ' 10') assert(expected_response in response) This runs a few commands and checks the output. Note that it runs a command, @@ -261,7 +261,7 @@ with the suite. For example, to add a new mem_search test:: /* Test 'ms' command with 32-bit values */ static int mem_test_ms_new_thing(struct unit_test_state *uts) { - /* test code here*/ + /* test code here */ return 0; } @@ -291,32 +291,20 @@ suite. For example:: /* Declare a new wibble test */ #define WIBBLE_TEST(_name, _flags) UNIT_TEST(_name, _flags, wibble_test) - /* Tetss go here */ - - /* At the bottom of the file: */ - - int do_ut_wibble(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]) - { - struct unit_test *tests = UNIT_TEST_SUITE_START(wibble_test); - const int n_ents = UNIT_TEST_SUITE_COUNT(wibble_test); - - return cmd_ut_category("cmd_wibble", "wibble_test_", tests, n_ents, argc, argv); - } + /* Tests go here */ Then add new tests to it as above. Register this new suite in test/cmd_ut.c by adding to cmd_ut_sub[]:: - /* Within cmd_ut_sub[]... */ - - U_BOOT_CMD_MKENT(wibble, CONFIG_SYS_MAXARGS, 1, do_ut_wibble, "", ""), + /* with the other SUITE_DECL() declarations */ + SUITE_DECL(wibble); -and adding new help to ut_help_text[]:: + /* Within suites[]... */ + SUITE(wibble, "my test of wibbles"); - "ut wibble - Test the wibble feature\n" - -If your feature is conditional on a particular Kconfig, then you can use #ifdef -to control that. +If your feature is conditional on a particular Kconfig, you do not need to add +an #ifdef since the suite will automatically be compiled out in that case. Finally, add the test to the build by adding to the Makefile in the same directory:: @@ -326,17 +314,35 @@ directory:: Note that CMDLINE is never enabled in SPL, so this test will only be present in U-Boot proper. See below for how to do SPL tests. -As before, you can add an extra Kconfig check if needed:: +You can add an extra Kconfig check if needed:: ifneq ($(CONFIG_$(XPL_)WIBBLE),) obj-$(CONFIG_$(XPL_)CMDLINE) += wibble.o endif +Each suite can have an optional init and uninit function. These are run before +and after any suite tests, respectively:: + + #define WIBBLE_TEST_INIT(_name, _flags) UNIT_TEST_INIT(_name, _flags, wibble_test) + #define WIBBLE_TEST_UNINIT(_name, _flags) UNIT_TEST_UNINIT(_name, _flags, wibble_test) -Example commit: 919e7a8fb64 ("test: Add a simple test for bloblist") [1] + static int wibble_test_init(struct unit_test_state *uts) + { + /* init code here */ + + return 0; + } + WIBBLE_TEST_INIT(wibble_test_init, 0); -[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/919e7a8fb64 + static int wibble_test_uninit(struct unit_test_state *uts) + { + /* uninit code here */ + + return 0; + } + WIBBLE_TEST_INIT(wibble_test_uninit, 0); +Both functions are included in the totals for each suite. Making the test run from pytest ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |