vhaudiquet/u-boot-krane
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'next'

Browse Source 
Note that this undoes the changes of commit cf6d4535cc ("x86:
emulation: Disable bloblist for now") as that was intended only for the
release due to time.
This commit is contained in:
Tom Rini
2025-04-08 11:43:23 -06:00
parent 34820924ed f892a7f397
commit ff61d6bfd1
2220 changed files with 138631 additions and 30228 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/develop/bootstd/overview.rst
+3 -2
View File
@@ -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
doc/develop/driver-model/design.rst
+4 -2
View File
@@ -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.
doc/develop/py_testing.rst
+8 -8
View File
@@ -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)
@@ -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
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.
doc/develop/tests_writing.rst
+35 -29
View File
@@ -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[]... */
/* with the other SUITE_DECL() declarations */
SUITE_DECL(wibble);
U_BOOT_CMD_MKENT(wibble, CONFIG_SYS_MAXARGS, 1, do_ut_wibble, "", ""),
/* Within suites[]... */
SUITE(wibble, "my test of wibbles");
and adding new help to ut_help_text[]::
"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::
Example commit: 919e7a8fb64 ("test: Add a simple test for bloblist") [1]
#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)
[1] https://gitlab.denx.de/u-boot/u-boot/-/commit/919e7a8fb64
static int wibble_test_init(struct unit_test_state *uts)
{
/* init code here */
return 0;
}
WIBBLE_TEST_INIT(wibble_test_init, 0);
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~