Merge tag v2023.07-rc4 into next

Signed-off-by: Tom Rini <trini@konsulko.com>

26 files changed, 505 insertions, 45 deletions

diff --git a/doc/android/boot-image.rst b/doc/android/boot-image.rst
index c719b4d711..8f247c7093 100644
--- a/doc/android/boot-image.rst
+++ b/doc/android/boot-image.rst
@@ -11,7 +11,7 @@ Android Boot Image is used to boot Android OS. It usually contains kernel image
 (like ``zImage`` file) and ramdisk. Sometimes it can contain additional
 binaries. This image is built as a part of AOSP (called ``boot.img``), and being
 flashed into ``boot`` partition on eMMC. Bootloader then reads that image from
-``boot`` partition to RAM and boots the kernel from it. Kernel than starts
+``boot`` partition to RAM and boots the kernel from it. Kernel then starts
 ``init`` process from the ramdisk. It should be mentioned that recovery image
 (``recovery.img``) also has Android Boot Image format.
 
diff --git a/doc/board/anbernic/index.rst b/doc/board/anbernic/index.rst
new file mode 100644
index 0000000000..03758d8613
--- /dev/null
+++ b/doc/board/anbernic/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Anbernic
+========
+
+.. toctree::
+   :maxdepth: 2
+
+   rgxx3.rst
diff --git a/doc/board/anbernic/rgxx3.rst b/doc/board/anbernic/rgxx3.rst
new file mode 100644
index 0000000000..afa7538282
--- /dev/null
+++ b/doc/board/anbernic/rgxx3.rst
@@ -0,0 +1,47 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+U-Boot for Anbernic RGxx3 Devices
+=================================
+
+This allows U-Boot to boot the following Anbernic devices:
+
+ - Anbernic RG353M
+ - Anbernic RG353P
+ - Anbernic RG353V
+ - Anbernic RG353VS
+ - Anbernic RG503
+
+The correct device is detected automatically by comparing ADC values
+from ADC channel 1. In the event of an RG353V, an attempt is then made
+to probe for an eMMC and if it fails the device is assumed to be an
+RG353VS. Based on the detected device, the environment variables
+"board", "board_name", and "fdtfile" are set to the correct values
+corresponding to the board which can be read by a boot script to boot
+with the correct device tree.
+
+Please note that there are some versions of the RG353 devices with
+different panels. Panel auto-detection is planned for a later date.
+
+Building U-Boot
+---------------
+
+.. code-block:: bash
+
+    $ export CROSS_COMPILE=aarch64-none-elf-
+    $ export BL31=../rkbin/bin/rk35/rk3568_bl31_v1.34.elf
+    $ export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3568_ddr_1056MHz_v1.13.bin
+    $ make anbernic-rgxx3_defconfig
+    $ make
+
+This will build ``u-boot-rockchip.bin`` which can be written to an SD
+card.
+
+Image installation
+------------------
+
+Write the ``u-boot-rockchip.bin`` to an SD card offset 32kb from the
+start.
+
+.. code-block:: bash
+
+    $ dd if=u-boot-rockchip.bin of=/dev/mmcblk0 bs=512 seek=64
diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst
index 4a5f101cad..0fe95af56d 100644
--- a/doc/board/coreboot/coreboot.rst
+++ b/doc/board/coreboot/coreboot.rst
@@ -71,3 +71,32 @@ Memory map
               (typically redirects to 7ab10030 or similar)
          500  Location of coreboot sysinfo table, used during startup
   ==========  ==================================================================
+
+
+Debug UART
+----------
+
+It is possible to enable the debug UART with coreboot. To do this, use the
+info from the cbsysinfo command to locate the UART base. For example::
+
+   => cbsysinfo
+   ...
+   Serial I/O port: 00000000
+      base        : 00000000
+      pointer     : 767b51bc
+      type        : 2
+      base        : fe03e000
+      baud        : 0d115200
+      regwidth    : 4
+      input_hz    : 0d1843200
+      PCI addr    : 00000010
+   ...
+
+Here you can see that the UART base is fe03e000, regwidth is 4 (1 << 2) and the
+input clock is 1843200. So you can add the following CONFIG options::
+
+   CONFIG_DEBUG_UART=y
+   CONFIG_DEBUG_UART_BASE=fe03e000
+   CONFIG_DEBUG_UART_CLOCK=1843200
+   CONFIG_DEBUG_UART_SHIFT=2
+   CONFIG_DEBUG_UART_ANNOUNCE=y
diff --git a/doc/board/index.rst b/doc/board/index.rst
index b2da6ec553..9ef25b1091 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -11,6 +11,7 @@ Board-specific doc
    AndesTech/index
    allwinner/index
    amlogic/index
+   anbernic/index
    apple/index
    armltd/index
    atmel/index
@@ -33,6 +34,7 @@ Board-specific doc
    openpiton/index
    purism/index
    qualcomm/index
+   renesas/index
    rockchip/index
    samsung/index
    siemens/index
diff --git a/doc/board/renesas/index.rst b/doc/board/renesas/index.rst
new file mode 100644
index 0000000000..fb6558ec11
--- /dev/null
+++ b/doc/board/renesas/index.rst
@@ -0,0 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Renesas
+=======
+
+.. toctree::
+   :maxdepth: 2
+
+   renesas
+   rzn1
diff --git a/doc/board/renesas/renesas.rst b/doc/board/renesas/renesas.rst
new file mode 100644
index 0000000000..04dee8da24
--- /dev/null
+++ b/doc/board/renesas/renesas.rst
@@ -0,0 +1,45 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Renesas
+=======
+
+About this
+----------
+
+This document describes the information about Renesas supported boards
+and their usage steps.
+
+Renesas boards
+--------------
+
+Renesas is a SoC solutions provider for automotive and industrial applications.
+
+U-Boot supports several Renesas SoC families:
+
+* R-Car Gen2 (32-bit)
+    - Blanche board
+    - Gose board
+    - Koelsch board
+    - Lager board
+    - Silk board
+    - Porter board
+    - Stout board
+* R-Car Gen3 (64-bit)
+    - Condor board
+    - Draak board
+    - Eagle board
+    - Ebisu board
+    - Salvator-X and Salvator-XS boards
+    - ULCB board
+* R-Car Gen4 (64-bit)
+    - Falcon board
+    - Spider board
+    - Whitehawk board
+* RZ/A1 (32-bit)
+    - GR-PEACH board
+* RZ/G
+    - Beacon-rzg2 board
+    - Hihope-rzg2 board
+    - ek874 board
+* RZ/N1 (32-bit)
+    - Schneider rzn1-snarc board
diff --git a/doc/board/renesas/rzn1.rst b/doc/board/renesas/rzn1.rst
new file mode 100644
index 0000000000..e6d636b89e
--- /dev/null
+++ b/doc/board/renesas/rzn1.rst
@@ -0,0 +1,76 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Renesas RZ/N1
+=============
+
+Building
+--------
+
+This document describes how to build and flash U-Boot for the RZ/N1.
+
+U-Boot
+^^^^^^
+
+Clone the U-Boot repository and build it as follows:
+
+.. code-block:: bash
+
+        git clone --depth 1 https://source.denx.de/u-boot/u-boot.git
+        cd u-boot
+        make rzn1_snarc_defconfig
+        make CROSS_COMPILE=arm-linux-gnu-
+
+This produces `u-boot` which is an ELF executable, suitable for use with `gdb`
+and JTAG debugging tools.
+
+It also produceds `u-boot.bin` which is a raw binary.
+
+Binman
+^^^^^^
+
+The BootROM in the RZ/N1 SoC expects to find the boot image in SPKG format.
+This format is documented in Chapter 7.4 of the RZ/N1 User Manual.
+
+The `binman` tool may be used to generate the SPKG format for booting.
+See tools/binman/binman.rst for details on this tool and its pre-requisites.
+
+.. code-block:: bash
+
+    binman -d arch/arm/dts/r9a06g032-rzn1-snarc.dtb -o <OUT>
+
+This will produce `u-boot.bin.spkg` in the specified <OUT> directory. It can
+then be flashed into QSPI, NAND, or loaded via USB-DFU mode.
+
+SPKG image
+^^^^^^^^^^
+
+Alternatively, the same SPKG image can be built by calling `mkimage` as follows:
+
+.. code-block:: bash
+
+    tools/mkimage -n board/schneider/rzn1-snarc/spkgimage.cfg \
+            -T spkgimage -a 0x20040000 -e 0x20040000 \
+            -d u-boot.bin u-boot.bin.spkg
+
+This produces `u-boot.bin.spkg` which can be flashed into QSPI, NAND, or loaded
+via USB-DFU mode.
+
+Take note of the load and execution address, which are encoded into the SPKG
+headers. For development convenience, mkimage computes the execution offset
+(part of the SPKG header) by subtracting the supplied load address from the
+supplied execution address.
+
+Also note there are other parameters, notably ECC configuration in the case of
+boot from NAND, specified in the `spkgimage.cfg` configuration file.
+
+Flashing
+--------
+
+The RZ/N1 is able to boot from QSPI, NAND, or via USB (DFU). In all cases the
+on-board BootROM expects for the binary to be wrapped with a "SPKG" header.
+
+It is possible to recover a bricked unit by using the USB (DFU) boot mode. This
+allows uploading U-Boot into the internal RAM. Thereafter U-Boot can be used to
+program the QSPI and/or NAND, making use of U-Boot dfu mode.
+
+Otherwise the only other option for recovery is via JTAG.
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 1dccb17d72..99376fb54c 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -83,10 +83,16 @@ List of mainline supported Rockchip boards:
      - Khadas Edge-V (hadas-edge-v-rk3399)
      - Orange Pi RK3399 (orangepi-rk3399)
      - Pine64 RockPro64 (rockpro64-rk3399)
-     - Radxa ROCK Pi 4 (rock-pi-4-rk3399)
+     - Radxa ROCK 4C+ (rock-4c-plus-rk3399)
+     - Radxa ROCK 4SE (rock-pi-4-rk3399)
+     - Radxa ROCK Pi 4A/B/A+/B+ (rock-pi-4-rk3399)
+     - Radxa ROCK Pi 4C (rock-pi-4c-rk3399)
      - Rockchip Evb-RK3399 (evb_rk3399)
      - Theobroma Systems RK3399-Q7 SoM - Puma (puma_rk3399)
 
+* rk3566
+     - Anbernic RGxx3 (rgxx3-rk3566)
+
 * rk3568
      - Rockchip Evb-RK3568 (evb-rk3568)
 
diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst
index e898601c41..feaa2da5e9 100644
--- a/doc/board/ti/j721e_evm.rst
+++ b/doc/board/ti/j721e_evm.rst
@@ -268,6 +268,49 @@ Image formats:
                 | +-------------------+ |
                 +-----------------------+
 
+R5 Memory Map:
+--------------
+
+.. list-table::
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Region
+     - Start Address
+     - End Address
+
+   * - SPL
+     - 0x41c00000
+     - 0x41c40000
+
+   * - EMPTY
+     - 0x41c40000
+     - 0x41c81920
+
+   * - STACK
+     - 0x41c85920
+     - 0x41c81920
+
+   * - Global data
+     - 0x41c859f0
+     - 0x41c85920
+
+   * - Heap
+     - 0x41c859f0
+     - 0x41cf59f0
+
+   * - BSS
+     - 0x41cf59f0
+     - 0x41cff9f0
+
+   * - MCU Scratchpad
+     - 0x41cff9fc
+     - 0x41cffbfc
+
+   * - ROM DATA
+     - 0x41cffbfc
+     - 0x41cfffff
+
 OSPI:
 -----
 ROM supports booting from OSPI from offset 0x0.
diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index 5dfa6cfce5..7a2a69fdfc 100644
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -154,7 +154,7 @@ bootmeths
 This environment variable can be used to control the list of bootmeths used and
 their ordering for example::
 
-   setenv bootmeths "syslinux efi"
+   setenv bootmeths "extlinux efi"
 
 Entries may be removed or re-ordered in this list to affect the order the
 bootmeths are tried on each bootdev. If the variable is empty, the default
@@ -389,8 +389,8 @@ Configuration
 -------------
 
 Standard boot is enabled with `CONFIG_BOOTSTD`. Each bootmeth has its own CONFIG
-option also. For example, `CONFIG_BOOTMETH_DISTRO` enables support for distro
-boot from a disk.
+option also. For example, `CONFIG_BOOTMETH_EXTLINUX` enables support for
+booting from a disk using an `extlinux.conf` file.
 
 To enable all feature sof standard boot, use `CONFIG_BOOTSTD_FULL`. This
 includes the full set of commands, more error messages when things go wrong and
@@ -406,8 +406,8 @@ Available bootmeth drivers
 
 Bootmeth drivers are provided for:
 
-   - distro boot from a disk (syslinux)
-   - distro boot from a network (PXE)
+   - extlinux / syslinux boot from a disk
+   - extlinux boot from a network (PXE)
    - U-Boot scripts from disk, network or SPI flash
    - EFI boot using bootefi from disk
    - VBE
@@ -683,8 +683,8 @@ This feature can be added as needed. Note that sandbox is a special case, since
 in that case the host filesystem can be accessed even though the block device
 is NULL.
 
-If we take the example of the `bootmeth_distro` driver, this call ends up at
-`distro_read_bootflow()`. It has the filesystem ready, so tries various
+If we take the example of the `bootmeth_extlinux` driver, this call ends up at
+`extlinux_read_bootflow()`. It has the filesystem ready, so tries various
 filenames to try to find the `extlinux.conf` file, reading it if possible. If
 all goes well the bootflow ends up in the `BOOTFLOWST_READY` state.
 
@@ -697,12 +697,12 @@ the  `BOOTFLOWST_READY` state.
 
 That is the basic operation of scanning for bootflows. The process of booting a
 bootflow is handled by the bootmeth driver for that bootflow. In the case of
-distro boot, this parses and processes the `extlinux.conf` file that was read.
-See `distro_boot()` for how that works. The processing may involve reading
+extlinux boot, this parses and processes the `extlinux.conf` file that was read.
+See `extlinux_boot()` for how that works. The processing may involve reading
 additional files, which is handled by the `read_file()` method, which is
-`distro_read_file()` in this case. All bootmethds should support reading files,
-since the bootflow is typically only the basic instructions and does not include
-the operating system itself, ramdisk, device tree, etc.
+`extlinux_read_file()` in this case. All bootmethds should support reading
+files, since the bootflow is typically only the basic instructions and does not
+include the operating system itself, ramdisk, device tree, etc.
 
 The vast majority of the bootstd code is concerned with iterating through
 partitions on bootdevs and using bootmethds to find bootflows.
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 0b3b32be1b..cbb65c9b17 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -100,7 +100,7 @@ and development only and is not recommended for production devices.
 
 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
 a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed
-in u-boot.bin so you can still just flash u-boot,bin onto your board. If you are
+in u-boot.bin so you can still just flash u-boot.bin onto your board. If you are
 using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
diff --git a/doc/develop/driver-model/livetree.rst b/doc/develop/driver-model/livetree.rst
index 579eef5ca9..20055d559a 100644
--- a/doc/develop/driver-model/livetree.rst
+++ b/doc/develop/driver-model/livetree.rst
@@ -103,7 +103,7 @@ The new code is:
 
     struct udevice *bus;
 
-    i2c_bus->regs = (struct i2c_ctlr *)dev_read_addr(dev);
+    i2c_bus->regs = dev_read_addr_ptr(dev);
     plat->frequency = dev_read_u32_default(bus, "spi-max-frequency", 500000);
 
 The dev_read\_...() interface is more convenient and works with both the
diff --git a/doc/develop/event.rst b/doc/develop/event.rst
index e60cbf6569..1c1c9ef7f1 100644
--- a/doc/develop/event.rst
+++ b/doc/develop/event.rst
@@ -11,7 +11,7 @@ block device is probed.
 Rather than using weak functions and direct calls across subsystemss, it is
 often easier to use an event.
 
-An event consists of a type (e.g. EVT_DM_POST_INIT) and some optional data,
+An event consists of a type (e.g. EVT_DM_POST_INIT_F) and some optional data,
 in `union event_data`. An event spy can be created to watch for events of a
 particular type. When the event is created, it is sent to each spy in turn.
 
@@ -26,9 +26,9 @@ To declare a spy, use something like this::
         /* do something */
         return 0;
     }
-    EVENT_SPY(EVT_DM_POST_INIT, snow_setup_cpus);
+    EVENT_SPY(EVT_DM_POST_INIT_F, snow_setup_cpus);
 
-Your function is called when EVT_DM_POST_INIT is emitted, i.e. after driver
+Your function is called when EVT_DM_POST_INIT_F is emitted, i.e. after driver
 model is inited (in SPL, or in U-Boot proper before and after relocation).
 
 
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index 41d8edecb8..2c82783a89 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -68,9 +68,9 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2023.07-rc2 was released on Mon 08 May 2023.
 
-.. * U-Boot v2023.07-rc3 was released on Mon 22 May 2023.
+* U-Boot v2023.07-rc3 was released on Mon 29 May 2023.
 
-.. * U-Boot v2023.07-rc4 was released on Mon 05 June 2023.
+* U-Boot v2023.07-rc4 was released on Mon 12 June 2023.
 
 .. * U-Boot v2023.07-rc5 was released on Mon 19 June 2023.
 
diff --git a/doc/device-tree-bindings/bootmeth.txt b/doc/device-tree-bindings/bootmeth.txt
index de6396a7b3..127b09cd1b 100644
--- a/doc/device-tree-bindings/bootmeth.txt
+++ b/doc/device-tree-bindings/bootmeth.txt
@@ -7,8 +7,8 @@ device (bootdev). These are normally created as children of the bootstd device.
 Required properties:
 
 compatible:
-   "u-boot,distro-syslinux" - distro boot from a block device
-   "u-boot,distro-pxe" - distro boot from a network device
+   "u-boot,extlinux" - distro boot from a block device
+   "u-boot,extlinux-pxe" - distro boot from a network device
    "u-boot,distro-efi" - EFI boot from an .efi file
    "u-boot,efi-bootmgr" - EFI boot using boot manager (bootmgr)
 
@@ -21,8 +21,8 @@ Example:
 		filename-prefixes = "/", "/boot/";
 		bootdev-order = "mmc2", "mmc1";
 
-		syslinux {
-			compatible = "u-boot,distro-syslinux";
+		extlinux {
+			compatible = "u-boot,extlinux";
 		};
 
 		efi {
diff --git a/doc/device-tree-bindings/bootstd.txt b/doc/device-tree-bindings/bootstd.txt
index 8706c5f499..1f1b9cba60 100644
--- a/doc/device-tree-bindings/bootstd.txt
+++ b/doc/device-tree-bindings/bootstd.txt
@@ -26,8 +26,8 @@ Example:
 		filename-prefixes = "/", "/boot/";
 		bootdev-order = "mmc2", "mmc1";
 
-		syslinux {
-			compatible = "u-boot,distro-syslinux";
+		extlinux {
+			compatible = "u-boot,extlinux";
 		};
 
 		efi {
diff --git a/doc/mkimage.1 b/doc/mkimage.1
index d8727ec73c..76c7859bb0 100644
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -662,6 +662,51 @@ rk3568
 .TE
 .RE
 .
+.SS spkgimage
+The primary configuration file consists of lines containing key/value pairs
+delimited by whitespace. An example follows.
+.PP
+.RS
+.EX
+# Comments and blank lines may be used
+.I key1 value1
+.I key2 value2
+.EE
+.RE
+.P
+The supported
+.I key
+types are as follows.
+.TP
+.B VERSION
+.TQ
+.B NAND_ECC_BLOCK_SIZE
+.TQ
+.B NAND_ECC_ENABLE
+.TQ
+.B NAND_ECC_SCHEME
+.TQ
+.B NAND_BYTES_PER_ECC_BLOCK
+These all take a positive integer value as their argument.
+The value will be copied directly into the respective field
+of the SPKG header structure. For details on these values,
+refer to Section 7.4 of the Renesas RZ/N1 User's Manual.
+.
+.TP
+.B ADD_DUMMY_BLP
+Takes a numeric argument, which is treated as a boolean. Any nonzero
+value will cause a fake BLp security header to be included in the SPKG
+output.
+.
+.TP
+.B PADDING
+Takes a positive integer value, with an optional
+.B K
+or
+.B M
+suffix, indicating KiB / MiB respectively.
+The output SPKG file will be padded to a multiple of this value.
+.
 .SS sunxi_egon
 The primary configuration is the name to use for the device tree.
 .
diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt
index c71280b63b..21eb3894aa 100644
--- a/doc/uImage.FIT/signature.txt
+++ b/doc/uImage.FIT/signature.txt
@@ -42,8 +42,8 @@ device.
 Algorithms
 ----------
 In principle any suitable algorithm can be used to sign and verify a hash.
-At present only one class of algorithms is supported: SHA1 hashing with RSA.
-This works by hashing the image to produce a 20-byte hash.
+U-Boot supports a few hashing and verification algorithms. See below for
+details.
 
 While it is acceptable to bring in large cryptographic libraries such as
 openssl on the host side (e.g. mkimage), it is not desirable for U-Boot.
@@ -56,10 +56,10 @@ of data from the FDT and exponentiation mod n. Code size impact is a little
 under 5KB on Tegra Seaboard, for example.
 
 It is relatively straightforward to add new algorithms if required. If
-another RSA variant is needed, then it can be added to the table in
-image-sig.c. If another algorithm is needed (such as DSA) then it can be
-placed alongside rsa.c, and its functions added to the table in image-sig.c
-also.
+another RSA variant is needed, then it can be added with the
+U_BOOT_CRYPTO_ALGO() macro. If another algorithm is needed (such as DSA) then
+it can be placed in a directory alongside lib/rsa/, and its functions added
+using U_BOOT_CRYPTO_ALGO().
 
 
 Creating an RSA key pair and certificate
@@ -439,6 +439,7 @@ be enabled:
 
 CONFIG_FIT_SIGNATURE - enable signing and verification in FITs
 CONFIG_RSA - enable RSA algorithm for signing
+CONFIG_ECDSA - enable ECDSA algorithm for signing
 
 WARNING: When relying on signed FIT images with required signature check
 the legacy image format is default disabled by not defining
@@ -694,8 +695,6 @@ bootm.
 
 Possible Future Work
 --------------------
-- Add support for other RSA/SHA variants, such as rsa4096,sha512.
-- Other algorithms besides RSA
 - More sandbox tests for failure modes
 - Passwords for keys/certificates
 - Perhaps implement OAEP
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index cad09bbec9..8590efca21 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -148,7 +148,7 @@ Name       mmc\@7e202000.bootdev.part_2
 Device     mmc\@7e202000.bootdev
 Block dev  mmc\@7e202000.blk
 Type       distro
-Method:    syslinux
+Method:    extlinux
 State      ready
 Partition  2
 Subdir     (none)
diff --git a/doc/usage/cmd/bootmeth.rst b/doc/usage/cmd/bootmeth.rst
index 29d8215a0c..f632d74e1d 100644
--- a/doc/usage/cmd/bootmeth.rst
+++ b/doc/usage/cmd/bootmeth.rst
@@ -45,7 +45,7 @@ The format looks like this:
 =====  ===  ==================  =================================
 Order  Seq  Name                Description
 =====  ===  ==================  =================================
-    0    0  distro              Syslinux boot from a block device
+    0    0  extlinunx           Extlinux boot from a block device
     1    1  efi                 EFI boot from an .efi file
     2    2  pxe                 PXE boot from a network device
     3    3  sandbox             Sandbox boot for testing
@@ -77,7 +77,7 @@ This shows listing bootmeths. All are present and in the normal order::
     => bootmeth list
     Order  Seq  Name                Description
     -----  ---  ------------------  ------------------
-        0    0  distro              Syslinux boot from a block device
+        0    0  distro              Extlinux boot from a block device
         1    1  efi                 EFI boot from an .efi file
         2    2  pxe                 PXE boot from a network device
         3    3  sandbox             Sandbox boot for testing
@@ -92,7 +92,7 @@ Now the order is changed, to include only two of them::
     Order  Seq  Name                Description
     -----  ---  ------------------  ------------------
         0    3  sandbox             Sandbox boot for testing
-        1    0  distro              Syslinux boot from a block device
+        1    0  distro              Extlinux boot from a block device
     -----  ---  ------------------  ------------------
     (2 bootmeths)
 
@@ -102,7 +102,7 @@ which are not::
     => bootmeth list -a
     Order  Seq  Name                Description
     -----  ---  ------------------  ------------------
-        1    0  distro              Syslinux boot from a block device
+        1    0  distro              Extlinux boot from a block device
         -    1  efi                 EFI boot from an .efi file
         -    2  pxe                 PXE boot from a network device
         0    3  sandbox             Sandbox boot for testing
diff --git a/doc/usage/cmd/dm.rst b/doc/usage/cmd/dm.rst
index 236cd02bd6..74c6b01e36 100644
--- a/doc/usage/cmd/dm.rst
+++ b/doc/usage/cmd/dm.rst
@@ -366,7 +366,7 @@ This example shows the abridged sandbox output::
     ..
     sysreset      0  [   ]   sysreset_sandbox      |-- sysreset_sandbox
     bootstd       0  [   ]   bootstd_drv           |-- bootstd
-    bootmeth      0  [   ]   bootmeth_distro       |   |-- syslinux
+    bootmeth      0  [   ]   bootmeth_extlinux     |   |-- extlinux
     bootmeth      1  [   ]   bootmeth_efi          |   `-- efi
     reboot-mod    0  [   ]   reboot-mode-gpio      |-- reboot-mode0
     reboot-mod    1  [   ]   reboot-mode-rtc       |-- reboot-mode@14
diff --git a/doc/usage/cmd/loadb.rst b/doc/usage/cmd/loadb.rst
new file mode 100644
index 0000000000..b37d1d7b59
--- /dev/null
+++ b/doc/usage/cmd/loadb.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+loadb command
+=============
+
+Synopsis
+--------
+
+::
+
+    loadb [addr [baud]]
+
+Description
+-----------
+
+The loady command is used to transfer a file to the device via the serial line
+using the Kermit protocol.
+
+The number of transferred bytes is saved in environment variable filesize.
+
+addr
+    load address, defaults to environment variable loadaddr or if loadaddr is
+    not set to configuration variable CONFIG_SYS_LOAD_ADDR
+
+baud
+    baud rate for the Kermit transmission. After the transmission the baud
+    rate is reset to the original value.
+
+Example
+-------
+
+In the example below the terminal emulation program picocom and G-Kermit
+serve to transfer a file to a device.
+
+.. code-block:: bash
+
+    picocom --baud 115200 --send-cmd "gkermit -iXvs" /dev/ttyUSB0
+
+After entering the loadb command the key sequence <CTRL-A><CTRL-S> is used to
+let picocom prompt for the file name. Picocom invokes G-Kermit for the file
+transfer.
+
+::
+
+    => loadb 60800000 115200
+    ## Ready for binary (kermit) download to 0x60800000 at 115200 bps...
+
+    *** file: helloworld.efi
+    $ gkermit -iXvs helloworld.efi
+    G-Kermit 2.01, The Kermit Project, 2021-11-15
+    Escape back to your local Kermit and give a RECEIVE command.
+
+    KERMIT READY TO SEND...
+    |
+    *** exit status: 0 ***
+    ## Total Size      = 0x00000c00 = 3072 Bytes
+    ## Start Addr      = 0x60800000
+    =>
+
+The transfer can be cancelled by pressing <CTRL+C>.
+
+Configuration
+-------------
+
+The command is only available if CONFIG_CMD_LOADB=y.
+
+Return value
+------------
+
+The return value $? is 0 (true) on success, 1 (false) on error.
diff --git a/doc/usage/cmd/loadx.rst b/doc/usage/cmd/loadx.rst
new file mode 100644
index 0000000000..facca9b969
--- /dev/null
+++ b/doc/usage/cmd/loadx.rst
@@ -0,0 +1,77 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+loadx command
+=============
+
+Synopsis
+--------
+
+::
+
+    loadx [addr [baud]]
+
+Description
+-----------
+
+The loadx command is used to transfer a file to the device via the serial line
+using the XMODEM protocol.
+
+The number of transferred bytes is saved in environment variable filesize.
+
+addr
+    load address, defaults to environment variable loadaddr or if loadaddr is
+    not set to configuration variable CONFIG_SYS_LOAD_ADDR
+
+baud
+    baud rate for the ymodem transmission. After the transmission the baud
+    rate is reset to the original value.
+
+Example
+-------
+
+In the example below the terminal emulation program picocom was used to
+transfer a file to the device.
+
+.. code-block::
+
+    picocom --send-cmd 'sx -b vv' --baud 115200 /dev/ttyUSB0
+
+After entering the loadx command the key sequence <CTRL-A><CTRL-S> is used to
+let picocom prompt for the file name. Picocom invokes the program sx for the
+file transfer.
+
+::
+
+    => loadx 60800000 115200
+    ## Ready for binary (xmodem) download to 0x60800000 at 115200 bps...
+    C
+    *** file: helloworld.efi
+    $ sx -b vv helloworld.efi
+    sx: cannot open vv: No such file or directory
+    Sending helloworld.efi, 24 blocks: Give your local XMODEM receive command now.
+    Xmodem sectors/kbytes sent:   0/ 0kRetry 0: NAK on sector
+    Bytes Sent:   3072   BPS:1147
+
+    Transfer incomplete
+
+    *** exit status: 1 ***
+    ## Total Size      = 0x00000c00 = 3072 Bytes
+    ## Start Addr      = 0x60800000
+    =>
+
+The transfer can be cancelled by pressing 3 times <CTRL+C> after two seconds
+of inactivity on terminal.
+
+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.
+
+Return value
+------------
+
+The return value $? is 0 (true) on success, 1 (false) otherwise.
diff --git a/doc/usage/cmd/loady.rst b/doc/usage/cmd/loady.rst
index 718af6e128..3f8227ecf2 100644
--- a/doc/usage/cmd/loady.rst
+++ b/doc/usage/cmd/loady.rst
@@ -56,6 +56,9 @@ file transfer.
     6165f
     =>
 
+Transfer can be cancelled by pressing 3 times <CTRL+C> after two seconds
+of inactivity on terminal.
+
 Configuration
 -------------
 
@@ -65,10 +68,7 @@ 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
 ------------
 
-The return value $? is always 0 (true).
+The return value $? is 0 (true) on success, 1 (false) otherwise.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 0fde130a54..84ef8a9a42 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -63,7 +63,9 @@ Shell commands
    cmd/gpio
    cmd/host
    cmd/load
+   cmd/loadb
    cmd/loadm
+   cmd/loadx
    cmd/loady
    cmd/mbr
    cmd/md