Merge branch 'next'

20 files changed, 484 insertions, 64 deletions

diff --git a/doc/board/nokia/rx51.rst b/doc/board/nokia/rx51.rst
index 061fe7677e..7c6647bce2 100644
--- a/doc/board/nokia/rx51.rst
+++ b/doc/board/nokia/rx51.rst
@@ -158,8 +158,7 @@ UBIFS support add following lines into file ``configs/nokia_rx51_defconfig``::
 
     CONFIG_CMD_UBI=y
     CONFIG_CMD_UBIFS=y
-    CONFIG_MTD_UBI_FASTMAP=y
-    CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
+    CONFIG_MTD_UBI_BEB_LIMIT=10
 
 Run in QEMU
 -----------
diff --git a/doc/build/gcc.rst b/doc/build/gcc.rst
index ee544ad87e..a71f860a48 100644
--- a/doc/build/gcc.rst
+++ b/doc/build/gcc.rst
@@ -152,6 +152,23 @@ of dtc is new enough. It also makes sure that pylibfdt is present, if needed
 Note that the :doc:`tools` are always built with the included version of libfdt
 so it is not possible to build U-Boot tools with a system libfdt, at present.
 
+Link-time optimisation (LTO)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+U-Boot supports link-time optimisation which can reduce the size of the final
+U-Boot binaries, particularly with SPL.
+
+At present this can be enabled by ARM boards by adding `CONFIG_LTO=y` into the
+defconfig file. Other architectures are not supported. LTO is enabled by default
+for sandbox.
+
+This does incur a link-time penalty of several seconds. For faster incremental
+builds during development, you can disable it by setting `NO_LTO` to `1`.
+
+.. code-block:: bash
+
+    NO_LTO=1 make
+
 Other build targets
 ~~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/develop/cyclic.rst b/doc/develop/cyclic.rst
new file mode 100644
index 0000000000..43bedacb9f
--- /dev/null
+++ b/doc/develop/cyclic.rst
@@ -0,0 +1,50 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Cyclic functions
+================
+
+The cyclic function execution infrastruture provides a way to periodically
+execute code, e.g. every 100ms. Examples for such functions might be LED
+blinking etc. The functions that are hooked into this cyclic list should
+be small timewise as otherwise the execution of the other code that relies
+on a high frequent polling (e.g. UART rx char ready check) might be
+delayed too much. To detect cyclic functions with a too long execution
+time, the Kconfig option `CONFIG_CYCLIC_MAX_CPU_TIME_US` is introduced,
+which configures the max allowed time for such a cyclic function. If it's
+execution time exceeds this time, this cyclic function will get removed
+from the cyclic list.
+
+Registering a cyclic function
+-----------------------------
+
+To register a cyclic function, use something like this::
+
+    static void cyclic_demo(void *ctx)
+    {
+        /* Just a small dummy delay here */
+        udelay(10);
+    }
+    
+    int board_init(void)
+    {
+        struct cyclic_info *cyclic;
+        
+        /* Register demo cyclic function */
+        cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+        if (!cyclic)
+        printf("Registering of cyclic_demo failed\n");
+        
+        return 0;
+    }
+
+This will register the function `cyclic_demo()` to be periodically
+executed all 10ms.
+
+How is this cyclic functionality integrated /  executed?
+--------------------------------------------------------
+
+The cyclic infrastructure integrates the main function responsible for
+calling all registered cyclic functions cyclic_run() into the common
+WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed
+very often, which is necessary for the cyclic functions to get scheduled
+and executed at their configured periods.
diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst
index faf3eb5b5f..55aa3eac92 100644
--- a/doc/develop/driver-model/livetree.rst
+++ b/doc/develop/driver-model/livetree.rst
@@ -235,20 +235,9 @@ tree either present or absent. This is to make sure that the flat tree functions
 work correctly even with OF_LIVE is enabled. But if a test modifies the flat
 device tree, then the live tree can become invalid. Any live tree tests that run
 after that point will use a corrupted tree, e.g. with an incorrect property name
-or worse. To deal with this we use a flag UT_TESTF_LIVE_OR_FLAT then ensures
-that tests which write to the flat tree are not run if OF_LIVE is enabled. Only
-the live tree version of the test is run, when OF_LIVE is enabled, with
-sandbox_flattree running the flat tree version.
-
-This is of course a work-around, even if a reasonable one. One solution to this
-problem would be to make a copy of the flat tree before the test and restore it
-afterwards, in the same memory location, so that the live tree pointers work
-again. Another would be to regenerate the live tree if a test modified the flat
-tree.
-
-Neither of these solutions is currently implemented, since the situation that
-causes the problem can only occur in sandbox tests, is somewhat esoteric and
-the UT_TESTF_LIVE_OR_FLAT flag deals with it in a reasonable way.
+or worse. To deal with this we take a copy of the device tree and restore it
+after any test that modifies it. Note that this copy is not made on other
+boards, only sandbox.
 
 
 Multiple livetrees
@@ -261,11 +250,14 @@ a flat tree.
 It would be helpful to use livetree for fixups, since adding a lot of nodes and
 properties would involve less memory copying and be more efficient. As a step
 towards this, an `oftree` type has been introduced. It is normally set to
-oftree_default() but can be set to other values. Eventually this should allow
-the use of FDT fixups using the ofnode interface, instead of the low-level
-libfdt one.
+oftree_default() but can be set to other values using oftree_from_fdt().
+So long as OF_LIVE is disabled, it is possible to do fixups using the ofnode
+interface. The OF_LIVE support required addition of the flattening step at the
+end.
 
-See dm_test_ofnode_root() for some examples.
+See dm_test_ofnode_root() for some examples. The ofnode_path_root() function
+causes a flat device tree to be 'registered' such that it can be used by the
+ofnode interface.
 
 
 Internal implementation
@@ -329,10 +321,9 @@ Adding a new function for device-tree access involves the following steps:
 Future work
 -----------
 
-Live tree support was introduced in U-Boot 2017.07. There is still quite a bit
-of work to do to flesh this out:
+Live tree support was introduced in U-Boot 2017.07. Some possible enhancements
+are:
 
-- tests for all access functions
-- more support for livetree modification
-- addition of more access functions as needed
 - support for livetree in SPL and before relocation (if desired)
+- freeing leaked memory caused by writing new nodes / property values to the
+  livetree (ofnode_write_prop())
diff --git a/doc/develop/driver-model/migration.rst b/doc/develop/driver-model/migration.rst
index 5a60436925..742fea5515 100644
--- a/doc/develop/driver-model/migration.rst
+++ b/doc/develop/driver-model/migration.rst
@@ -57,7 +57,7 @@ In concert with maintainers migrating their block device usage to the
 appropriate DM driver, CONFIG_BLK needs to be set as well.  The final deadline
 here coincides with the final deadline for migration of the various block
 subsystems.  At this point we will be able to audit and correct the logic in
-Kconfig around using CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE and make
+Kconfig around using CONFIG_PARTITIONS and CONFIG_SPL_LEGACY_BLOCK and make
 use of CONFIG_BLK / CONFIG_SPL_BLK as needed.
 
 CONFIG_DM_SPI / CONFIG_DM_SPI_FLASH
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 72332f7da6..5934d9ffb1 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -28,6 +28,7 @@ Implementation
    ci_testing
    commands
    config_binding
+   cyclic
    devicetree/index
    distro
    driver-model/index
diff --git a/doc/develop/py_testing.rst b/doc/develop/py_testing.rst
index 06f919609b..92fbd22721 100644
--- a/doc/develop/py_testing.rst
+++ b/doc/develop/py_testing.rst
@@ -121,31 +121,36 @@ more options.
 Running tests in parallel
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Note: This does not fully work yet and is documented only so you can try to
-fix the problems.
+Note: Not all tests can run in parallel at present, so the usual approach is
+to just run those that can.
 
 First install support for parallel tests::
 
+    sudo apt install python3-pytest-xdist
+
+or:::
+
     pip3 install pytest-xdist
 
-Then build sandbox in a suitable build directory. It is not possible to use
-the --build flag with xdist.
+Then run the tests in parallel using the -n flag::
 
-Finally, run the tests in parallel using the -n flag::
+    test/py/test.py -B sandbox --build --build-dir /tmp/b/sandbox -q -k \
+        'not slow and not bootstd and not spi_flash' -n16
 
-    # build sandbox first, in a suitable build directory. It is not possible
-    # to use the --build flag with -n
-    test/py/test.py -B sandbox --build-dir /tmp/b/sandbox -q -k 'not slow' -n32
+You can also use `make pcheck` to run all tests in parallel. This uses a maximum
+of 16 threads, since the setup time is significant and there are under 1000
+tests.
 
-At least the following non-slow tests are known to fail:
+Note that the `test-log.html` output does not work correctly at present with
+parallel testing. All the threads write to it at once, so it is garbled.
 
-- test_fit_ecdsa
-- test_bind_unbind_with_uclass
-- ut_dm_spi_flash
-- test_gpt_rename_partition
-- test_gpt_swap_partitions
-- test_pinmux_status
-- test_sqfs_load
+Note that the `tools/` tests still run each tool's tests once after the other,
+although within that, they do run in parallel. So for example, the buildman
+tests run in parallel, then the binman tests run in parallel. There would be a
+significant advantage to running them all in parallel together, but that would
+require a large amount of refactoring, e.g. with more use of pytest fixtures.
+The code-coverage tests are omitted since they cannot run in parallel due to a
+Python limitation.
 
 
 Testing under a debugger
diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
index 1abe4d7f0f..5afeb42f69 100644
--- a/doc/develop/testing.rst
+++ b/doc/develop/testing.rst
@@ -28,8 +28,12 @@ run. Type this::
 
     make tcheck
 
+You can also run a selection tests in parallel with::
+
+    make pcheck
+
 All of the above use the test/run script with a paremeter to select which tests
-are run.
+are run. See :doc:`py_testing` for more information.
 
 
 Sandbox
diff --git a/doc/develop/tests_sandbox.rst b/doc/develop/tests_sandbox.rst
index 40cf8ecdd7..8e42a32afb 100644
--- a/doc/develop/tests_sandbox.rst
+++ b/doc/develop/tests_sandbox.rst
@@ -119,6 +119,30 @@ You can easily use gdb on these tests, without needing --gdbserver::
 You can then single-step and look at variables as needed.
 
 
+Running tests multiple times
+----------------------------
+
+Some tests can have race conditions which are hard to detect on a single
+one. It is possible to run each individual test multiple times, before moving
+to the next test, with the '-r' flag.
+
+This is most useful when running a single test, since running all tests
+multiple times can take a while.
+
+For example::
+
+   => ut dm -r1000 dm_test_rtc_set_get
+   ...
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   Test: dm_test_rtc_set_get: rtc.c
+   test/dm/rtc.c:257, dm_test_rtc_reset(): old_base_time == base_time: Expected 0x62e7453c (1659323708), got 0x62e7453d (1659323709)
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   Test: dm_test_rtc_set_get: rtc.c
+   Test: dm_test_rtc_set_get: rtc.c (flat tree)
+   ...
+   Test dm_test_rtc_reset failed 3 times
+
+
 Running sandbox_spl tests directly
 ----------------------------------
 
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 941e427093..cd84706953 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -748,7 +748,7 @@ UEFI block IO driver
 The UEFI block IO driver supports devices exposing the EFI_BLOCK_IO_PROTOCOL.
 
 When connected it creates a new U-Boot block IO device with interface type
-IF_TYPE_EFI_LOADER, adds child controllers mapping the partitions, and installs
+UCLASS_EFI_LOADER, adds child controllers mapping the partitions, and installs
 the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL on these. This can be used together with the
 software iPXE to boot from iSCSI network drives [4].
 
diff --git a/doc/device-tree-bindings/pmic/pm8916.txt b/doc/device-tree-bindings/pmic/pm8916.txt
deleted file mode 100644
index 15c598b8c4..0000000000
--- a/doc/device-tree-bindings/pmic/pm8916.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Qualcomm pm8916 PMIC
-
-This PMIC is connected using SPMI bus so should be child of SPMI bus controller.
-
-Required properties:
-- compatible: "qcom,spmi-pmic";
-- reg: SPMI Slave ID, size (ignored)
-- #address-cells: 0x1 (peripheral ID)
-- #size-cells: 0x1 (size of peripheral register space)
-
-Example:
-
-pm8916@0 {
-	compatible = "qcom,spmi-pmic";
-	reg = <0x0 0x1>;
-	#address-cells = <0x1>;
-	#size-cells = <0x1>;
-};
diff --git a/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt b/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
new file mode 100644
index 0000000000..eb78e3ae77
--- /dev/null
+++ b/doc/device-tree-bindings/pmic/qcom,spmi-pmic.txt
@@ -0,0 +1,94 @@
+          Qualcomm SPMI PMICs multi-function device bindings
+
+The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084
+PMICs.  These PMICs use a QPNP scheme through SPMI interface.
+QPNP is effectively a partitioning scheme for dividing the SPMI extended
+register space up into logical pieces, and set of fixed register
+locations/definitions within these regions, with some of these regions
+specifically used for interrupt handling.
+
+The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are
+interfaced to the chip via the SPMI (System Power Management Interface) bus.
+Support for multiple independent functions are implemented by splitting the
+16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes
+each. A function can consume one or more of these fixed-size register regions.
+
+Required properties:
+- compatible:      Should contain one of:
+                   "qcom,pm660",
+                   "qcom,pm660l",
+                   "qcom,pm7325",
+                   "qcom,pm8004",
+                   "qcom,pm8005",
+                   "qcom,pm8019",
+                   "qcom,pm8028",
+                   "qcom,pm8110",
+                   "qcom,pm8150",
+                   "qcom,pm8150b",
+                   "qcom,pm8150c",
+                   "qcom,pm8150l",
+                   "qcom,pm8226",
+                   "qcom,pm8350c",
+                   "qcom,pm8841",
+                   "qcom,pm8901",
+                   "qcom,pm8909",
+                   "qcom,pm8916",
+                   "qcom,pm8941",
+                   "qcom,pm8950",
+                   "qcom,pm8953",
+                   "qcom,pm8994",
+                   "qcom,pm8998",
+                   "qcom,pma8084",
+                   "qcom,pmd9635",
+                   "qcom,pmi8950",
+                   "qcom,pmi8962",
+                   "qcom,pmi8994",
+                   "qcom,pmi8998",
+                   "qcom,pmk8002",
+                   "qcom,pmk8350",
+                   "qcom,pmr735a",
+                   "qcom,smb2351",
+                   or generalized "qcom,spmi-pmic".
+- reg:             Specifies the SPMI USID slave address for this device.
+                   For more information see:
+                   Documentation/devicetree/bindings/spmi/spmi.yaml
+
+Required properties for peripheral child nodes:
+- compatible:      Should contain "qcom,xxx", where "xxx" is a peripheral name.
+
+Optional properties for peripheral child nodes:
+- interrupts:      Interrupts are specified as a 4-tuple. For more information
+                   see:
+                   Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
+- interrupt-names: Corresponding interrupt name to the interrupts property
+
+Each child node of SPMI slave id represents a function of the PMIC. In the
+example below the rtc device node represents a peripheral of pm8941
+SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1.
+
+Example:
+
+	spmi {
+		compatible = "qcom,spmi-pmic-arb";
+
+		pm8941@0 {
+			compatible = "qcom,pm8941", "qcom,spmi-pmic";
+			reg = <0x0 SPMI_USID>;
+
+			rtc {
+				compatible = "qcom,rtc";
+				interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
+				interrupt-names = "alarm";
+			};
+		};
+
+		pm8941@1 {
+			compatible = "qcom,pm8941", "qcom,spmi-pmic";
+			reg = <0x1 SPMI_USID>;
+
+			regulator {
+				compatible = "qcom,regulator";
+				regulator-name = "8941_boost";
+			};
+		};
+	};
diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt
index 6870111840..0a03c942bd 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -23,7 +23,7 @@ in the system memory and passed to bootm as a arguments. Some of them may be
 missing: FDT is not present for legacy platforms, ramdisk is always optional.
 Additionally, old uImage format has been extended to support multi sub-images
 but the support is limited by simple format of the legacy uImage structure.
-Single binary header 'struct image_header' is not flexible enough to cover all
+Single binary header 'struct legacy_img_hdr' is not flexible enough to cover all
 possible scenarios.
 
 All those factors combined clearly show that there is a need for new, more
diff --git a/doc/usage/cmd/bootmenu.rst b/doc/usage/cmd/bootmenu.rst
index 9430f8c9aa..cb3c8d2f93 100644
--- a/doc/usage/cmd/bootmenu.rst
+++ b/doc/usage/cmd/bootmenu.rst
@@ -4,6 +4,15 @@
 bootmenu command
 ================
 
+Synopsis
+--------
+::
+
+    bootmenu [delay]
+
+Description
+-----------
+
 The "bootmenu" command uses U-Boot menu interfaces and provides
 a simple mechanism for creating menus with different boot items.
 The cursor keys "Up" and "Down" are used for navigation through
@@ -79,6 +88,55 @@ The above example will be rendered as below::
 The selected menu entry will be highlighted - it will have inverted
 background and text colors.
 
+UEFI boot variable enumeration
+''''''''''''''''''''''''''''''
+If enabled, the bootmenu command will automatically generate and add
+UEFI-related boot menu entries for the following items.
+
+ * possible bootable media with default file names
+ * user-defined UEFI boot options
+
+The bootmenu automatically enumerates the possible bootable
+media devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
+This auto generated entry is named as "<interface> <devnum>:<part>" format.
+(e.g. "usb 0:1")
+
+The bootmenu displays the UEFI-related menu entries in order of "BootOrder".
+When the user selects the UEFI boot menu entry, the bootmenu sets
+the selected boot variable index to "BootNext" without non-volatile attribute,
+then call the uefi boot manager with the command "bootefi bootmgr".
+
+Example bootmenu is as below::
+
+    *** U-Boot Boot Menu ***
+
+       mmc 0:1
+       mmc 0:2
+       debian
+       nvme 0:1
+       ubuntu
+       nvme 0:2
+       usb 0:2
+       U-Boot console
+
+Default behavior when user exits from the bootmenu
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+User can exit from bootmenu by selecting the last entry
+"U-Boot console"/"Quit" or ESC/CTRL+C key.
+
+When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is disabled,
+user exits from the bootmenu and returns to the U-Boot console.
+
+When the CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not
+enter the U-Boot console. When the user exits from the bootmenu,
+the bootmenu invokes the following default behavior.
+
+ * if CONFIG_CMD_BOOTEFI_BOOTMGR is enabled, execute "bootefi bootmgr" command
+ * "bootefi bootmgr" fails or is not enabled, then execute "run bootcmd" command.
+
+Configuration
+-------------
+
 The "bootmenu" command is enabled by::
 
     CONFIG_CMD_BOOTMENU=y
@@ -88,3 +146,19 @@ To run the bootmenu at startup add these additional settings::
     CONFIG_AUTOBOOT_KEYED=y
     CONFIG_BOOTDELAY=30
     CONFIG_AUTOBOOT_MENU_SHOW=y
+
+UEFI boot variable enumeration is enabled by::
+
+    CONFIG_CMD_BOOTEFI_BOOTMGR=y
+
+To improve the product security, entering U-Boot console from bootmenu
+can be disabled by::
+
+    CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE=y
+
+To scan the discoverable devices connected to the buses such as
+USB and PCIe prior to bootmenu showing up, CONFIG_PREBOOT can be
+used to run the command before showing the bootmenu, i.e.::
+
+    CONFIG_USE_PREBOOT=y
+    CONFIG_PREBOOT="pci enum; usb start; scsi scan; nvme scan; virtio scan"
diff --git a/doc/usage/cmd/cyclic.rst b/doc/usage/cmd/cyclic.rst
new file mode 100644
index 0000000000..3085cc7204
--- /dev/null
+++ b/doc/usage/cmd/cyclic.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+cyclic command
+==============
+
+Synopsis
+--------
+
+::
+
+    cyclic list
+
+Description
+-----------
+
+The cyclic list command provides a list of the currently registered
+cyclic functions.
+
+This shows the following information:
+
+Function
+    Function name
+
+cpu-time
+    Total time spent in this cyclic function.
+
+Frequency
+    Frequency of execution of this function, e.g. 100 times/s for a
+    pediod of 10ms.
+
+
+See :doc:`../../develop/cyclic` for more information on cyclic functions.
+
+Example
+-------
+
+::
+
+    => cyclic list
+    function: cyclic_demo, cpu-time: 52906 us, frequency: 99.20 times/s
+
+Configuration
+-------------
+
+The cyclic command is only available if CONFIG_CMD_CYCLIC=y.
diff --git a/doc/usage/cmd/eficonfig.rst b/doc/usage/cmd/eficonfig.rst
new file mode 100644
index 0000000000..340ebc80db
--- /dev/null
+++ b/doc/usage/cmd/eficonfig.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. (C) Copyright 2022, Masahisa Kojima <masahisa.kojima@linaro.org>
+
+eficonfig command
+=================
+
+Synopsis
+--------
+::
+
+    eficonfig
+
+Description
+-----------
+
+The "eficonfig" command uses U-Boot menu interface and provides
+a menu-driven UEFI variable maintenance feature.
+The "eficonfig" has the following menu entries.
+
+Add Boot Option
+    Add new UEFI Boot Option.
+    User can edit description, file path, and optional_data.
+
+Edit Boot Option
+    Edit the existing UEFI Boot Option
+    User can edit description, file path, and optional_data.
+
+Change Boot Order
+    Change the order of UEFI BootOrder variable.
+
+Delete Boot Option
+    Delete the UEFI Boot Option
+
+Configuration
+-------------
+
+The "eficonfig" command is enabled by::
+
+    CONFIG_CMD_EFICONFIG=y
+
+If CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled, user can not enter
+U-Boot console. In this case, bootmenu can be used to invoke "eficonfig"::
+
+    CONFIG_USE_PREBOOT=y
+    CONFIG_PREBOOT="setenv bootmenu_0 UEFI Maintenance Menu=eficonfig"
+
+How to boot the system with newly added UEFI Boot Option
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+"eficonfig" command is responsible for configuring the UEFI variables,
+not directly handle the system boot.
+The new Boot Option added by "eficonfig" is appended at the last entry
+of UEFI BootOrder variable, user may want to change the boot order
+through "Change Boot Order".
+If the bootmenu is enabled, CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE is enabled,
+and "eficonfig" is configured as preboot command, the newly added Boot Options
+are enumerated in the bootmenu when user exits from the eficonfig menu.
+User may select the entry in the bootmenu to boot the system, or follow
+the U-Boot configuration the system already has.
+
+Auto boot with the UEFI Boot Option
+'''''''''''''''''''''''''''''''''''
+
+To do auto boot according to the UEFI BootOrder variable,
+add "bootefi bootmgr" entry as a default or first bootmenu entry::
+
+    CONFIG_PREBOOT="setenv bootmenu_0 UEFI Boot Manager=bootefi bootmgr; setenv bootmenu_1 UEFI Maintenance Menu=eficonfig"
+
+See also
+--------
+* :doc:`bootmenu<bootmenu>` provides a simple mechanism for creating menus with different boot items
diff --git a/doc/usage/cmd/loady.rst b/doc/usage/cmd/loady.rst
index 2819cc72ae..718af6e128 100644
--- a/doc/usage/cmd/loady.rst
+++ b/doc/usage/cmd/loady.rst
@@ -61,6 +61,13 @@ Configuration
 
 The command is only available if CONFIG_CMD_LOADB=y.
 
+Initial timeout in seconds while waiting for transfer is configured by
+config option CMD_LOADXY_TIMEOUT or by env variable $loadxy_timeout.
+Setting it to 0 means infinite timeout.
+
+Transfer can be cancelled by pressing 3 times <CTRL+C> after two seconds
+of inactivity on terminal.
+
 Return value
 ------------
 
diff --git a/doc/usage/cmd/pause.rst b/doc/usage/cmd/pause.rst
new file mode 100644
index 0000000000..c79e399c02
--- /dev/null
+++ b/doc/usage/cmd/pause.rst
@@ -0,0 +1,53 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later:
+
+pause command
+=============
+
+Synopsis
+--------
+
+::
+
+    pause [prompt]
+
+
+Description
+-----------
+
+The pause command delays execution waiting for any user input.
+
+It can accept a single parameter to change the prompt message.
+
+Examples
+--------
+
+Using with the default prompt:
+
+::
+
+    => pause
+    Press any key to continue...
+
+
+Using with a custom prompt:
+
+::
+
+    => pause 'Prompt for pause...'
+    Prompt for pause...
+
+Note that complex prompts require proper quoting:
+
+::
+
+    => pause Prompt for pause...
+    pause - delay until user input
+    
+    Usage:
+    pause [prompt] - Wait until users presses any key. [prompt] can be used to customize the message.
+
+Return value
+------------
+
+The return value $? is always set to 0 (true), unless invoked in an invalid
+manner.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index f1beeec59c..0fda121026 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -33,8 +33,10 @@ Shell commands
    cmd/bootz
    cmd/cbsysinfo
    cmd/conitrace
+   cmd/cyclic
    cmd/dm
    cmd/echo
+   cmd/eficonfig
    cmd/env
    cmd/event
    cmd/exception
@@ -52,6 +54,7 @@ Shell commands
    cmd/mbr
    cmd/md
    cmd/mmc
+   cmd/pause
    cmd/pinmux
    cmd/printenv
    cmd/pstore
diff --git a/doc/usage/partitions.rst b/doc/usage/partitions.rst
index 2c1a12b6bf..628469bbec 100644
--- a/doc/usage/partitions.rst
+++ b/doc/usage/partitions.rst
@@ -20,7 +20,7 @@ generic syntax.
 interface
         The interface used to access the partition's device, like ``mmc`` or
         ``scsi``. For a full list of supported interfaces, consult the
-        ``if_typename_str`` array in ``drivers/block/blk-uclass.c``
+        ``uclass_idname_str`` array in ``drivers/block/blk-uclass.c``
 
 devnum
         The device number. This defaults to 0.