From 404cdf0cdaacfa8595f8ec268709612d48335f01 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Fri, 7 Feb 2025 11:31:00 -0700 Subject: test: Update documentation Update documentation for how to write tests and the 'ut' command. Signed-off-by: Simon Glass --- doc/develop/tests_writing.rst | 52 ++++++++++++++++++++++++------------------- 1 file changed, 29 insertions(+), 23 deletions(-) (limited to 'doc/develop') diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index 54efb7e1b04..5f3c43d5da2 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From 752c3769874596d012cd8325099d2ae20123f989 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 9 Feb 2025 09:07:14 -0700 Subject: test/py: Shorten u_boot_console This fixture name is quite long and results in lots of verbose code. We know this is U-Boot so the 'u_boot_' part is not necessary. But it is also a bit of a misnomer, since it provides access to all the information available to tests. It is not just the console. It would be too confusing to use con as it would be confused with config and it is probably too short. So shorten it to 'ubman'. Signed-off-by: Simon Glass Link: https://lore.kernel.org/u-boot/CAFLszTgPa4aT_J9h9pqeTtLCVn4x2JvLWRcWRD8NaN3uoSAtyA@mail.gmail.com/ --- doc/develop/py_testing.rst | 12 ++++++------ doc/develop/tests_writing.rst | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) (limited to 'doc/develop') diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst index b50473039be..b88d7e3c8d4 100644 --- a/doc/develop/py_testing.rst +++ b/doc/develop/py_testing.rst @@ -506,24 +506,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 "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/tests_writing.rst b/doc/develop/tests_writing.rst index 5f3c43d5da2..d5917fe674c 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 = u_boot_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, -- cgit v1.2.3 From d9ed4b75add4b4ccc37cf32b54cd9c77f48e3396 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sun, 9 Feb 2025 09:07:15 -0700 Subject: test/py: Drop u_boot_ prefix on test files We know this is U-Boot so the prefix serves no purpose other than to make things longer and harder to read. Drop it and rename the files. Signed-off-by: Simon Glass Reviewed-by: Mattijs Korpershoek # test_android / test_dfu --- doc/develop/py_testing.rst | 4 ++-- doc/develop/tests_writing.rst | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/develop') diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst index b88d7e3c8d4..40a85380343 100644 --- a/doc/develop/py_testing.rst +++ b/doc/develop/py_testing.rst @@ -125,7 +125,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) @@ -515,7 +515,7 @@ 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 `ubman.disable_check()` to temporarily disable checking for specific strings. See `test_unknown_cmd.py` for an example. diff --git a/doc/develop/tests_writing.rst b/doc/develop/tests_writing.rst index d5917fe674c..7ea17081def 100644 --- a/doc/develop/tests_writing.rst +++ b/doc/develop/tests_writing.rst @@ -120,7 +120,7 @@ in Python:: """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(ubman) + ram_base = utils.find_ram_base(ubman) addr = '%08x' % ram_base val = 'a5f09876' expected_response = addr + ': ' + val -- cgit v1.2.3 From 8a0e6212bb5ef547712e922a41555eb7d1aee1ab Mon Sep 17 00:00:00 2001 From: Caleb Connolly Date: Fri, 17 Jan 2025 08:28:56 +0100 Subject: dm: clarify DM_FLAG_PROBE_AFTER_BIND behaviour The DM_FLAG_PROBE_AFTER_BIND flag only makes sense on a per-device basis, however recently added documentation as well as some confused drivers imply that it might be added to a driver definition, this does nothing. Clarify the new documentation and expand on the comment by the definition to point people in the right direction. Signed-off-by: Caleb Connolly Reviewed-by: Simon Glass Acked-by: Michal Simek --- doc/develop/driver-model/design.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'doc/develop') 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. -- cgit v1.2.3 From 6acb0d28b06c408740e8b80e4015e1e656c7faf4 Mon Sep 17 00:00:00 2001 From: Simon Glass Date: Sat, 15 Mar 2025 14:25:58 +0000 Subject: boot: Consider non-bootable partitions Any 'bootable' flag in a DOS partition causes boostd to only scan bootable partitions for that media. This can mean that extlinux.conf files on the root disk are missed. Put this logic behind a flag and update the documentation. For now, the flag is enabled, to preserve the existing behaviour of bootstd which is to ignore non-bootable partitions so long as there is at least one bootable partition on the disk. Future work may provide a command (or some other mechanism) to control this. Signed-off-by: Simon Glass --- doc/develop/bootstd/overview.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'doc/develop') 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 -- cgit v1.2.3