11 files changed, 193 insertions, 133 deletions
diff --git a/doc/README.TPL b/doc/README.TPL
deleted file mode 100644
index 95b466e4af9..00000000000
--- a/doc/README.TPL
+++ /dev/null
@@ -1,49 +0,0 @@
-Generic TPL framework
-=====================
-
-Overview
---------
-
-TPL---Third Program Loader.
-
-Due to the SPL on some boards(powerpc mpc85xx) has a size limit and cannot
-be compatible with all the external device(e.g. DDR). So add a tertiary
-program loader (TPL) to enable a loader stub loaded by the code from the
-SPL. It loads the final uboot image into DDR, then jump to it to begin
-execution. Now, only the powerpc mpc85xx has this requirement and will
-implemente it.
-
-Keep consistent with SPL, with this framework almost all source files for a
-board can be reused. No code duplication or symlinking is necessary anymore.
-
-How it works
-------------
-
-There has been a directory $(srctree)/spl which contains only a Makefile. The
-Makefile is shared by SPL and TPL.
-
-The object files are built separately for SPL/TPL and placed in the
-directory spl/tpl. The final binaries which are generated are
-u-boot-{spl|tpl}, u-boot-{spl|tpl}.bin and u-boot-{spl|tpl}.map.
-
-During the TPL build a variable named CONFIG_TPL_BUILD is exported in the
-make environment and also appended to CPPFLAGS with -DCONFIG_TPL_BUILD.
-
-The SPL options are shared by SPL and TPL, the board config file should
-determine which SPL options to choose based on whether CONFIG_TPL_BUILD
-is set. Source files can be compiled for TPL with options chosen in the
-board config file.
-
-TPL use a small device tree (u-boot-tpl.dtb), containing only the nodes with
-the pre-relocation properties: 'bootph-all' and 'bootph-pre-sram'
-(see doc/develop/spl.rst for details).
-
-For example:
-
-spl/Makefile:
-LIBS-$(CONFIG_SPL_LIBCOMMON_SUPPORT) += common/libcommon.o
-
-CONFIG_SPL_LIBCOMMON_SUPPORT is defined in board config file:
-#ifdef CONFIG_TPL_BUILD
-#define CONFIG_SPL_LIBCOMMON_SUPPORT
-#endif
diff --git a/doc/board/phytec/imx93-phyboard-segin.rst b/doc/board/phytec/imx93-phycore.rst
index ce17fbec78d..bd110a3ebee 100644
--- a/doc/board/phytec/imx93-phyboard-segin.rst
+++ b/doc/board/phytec/imx93-phycore.rst
@@ -1,9 +1,9 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-phyBOARD-Segin-i.MX93
-=====================
+phyCORE-i.MX 93
+===============
 
-U-Boot for the phyBOARD-Segin-i.MX93.
+U-Boot for the phyCORE-i.MX 93.
 
 Quick Start
 -----------
@@ -51,7 +51,7 @@ Build U-Boot
 
 .. code-block:: bash
 
-   $ make imx93-phyboard-segin_defconfig
+   $ make imx93-phycore_defconfig
    $ make
 
 Burn the flash.bin to MicroSD card offset 32KB:
diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst
index 99848a9e958..fa306974645 100644
--- a/doc/board/phytec/index.rst
+++ b/doc/board/phytec/index.rst
@@ -7,7 +7,7 @@ PHYTEC
    :maxdepth: 2
 
    imx8mm-phygate-tauri-l
-   imx93-phyboard-segin
+   imx93-phycore
    phycore-am62x
    phycore-am64x
    phycore-imx8mm
diff --git a/doc/build/docker.rst b/doc/build/docker.rst
index 45659b3b89d..5896dd5ac4a 100644
--- a/doc/build/docker.rst
+++ b/doc/build/docker.rst
@@ -1,11 +1,30 @@
 GitLab CI / U-Boot runner container
 ===================================
 
-In order to have a reproducible and portable build environment for CI we use a container for building in.  This means that developers can also reproduce the CI environment, to a large degree at least, locally.  This file is located in the tools/docker directory.  To build the image yourself
+In order to have a reproducible and portable build environment for CI we use a container for building in.  This means that developers can also reproduce the CI environment, to a large degree at least, locally.  This file is located in the tools/docker directory.
+
+The docker image supports both amd64 and arm64. Ensure that the
+'docker-buildx' Debian package is installed (or the equivalent on another
+distribution).
+
+You will need a multi-platform container, otherwise this error is shown::
+
+    ERROR: Multi-platform build is not supported for the docker driver.
+    Switch to a different driver, or turn on the containerd image store, and try again.
+
+You can add one with::
+
+    sudo docker buildx create --name multiarch --driver docker-container --use
+
+Building is supported on both amd64 (i.e. 64-bit x86) and arm64 machines. While
+both amd64 and arm64 happen in parallel, the non-native part will take
+considerably longer as it must use QEMU to emulate the foreign code.
+
+To build the image yourself::
 
 .. code-block:: bash
 
-    sudo docker build -t your-namespace:your-tag .
+    sudo docker buildx build --platform linux/arm64/v8,linux/amd64 -t your-namespace:your-tag .
 
 Or to use an existing container
 
diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
index e1783462bb0..e46cd39d601 100644
--- a/doc/develop/environment.rst
+++ b/doc/develop/environment.rst
@@ -18,8 +18,8 @@ The callbacks are named and associated with a function using the
 U_BOOT_ENV_CALLBACK macro in your board or driver code.
 
 These callbacks are associated with variables in one of two ways.  The
-static list can be added to by defining CFG_ENV_CALLBACK_LIST_STATIC
-in the board configuration to a string that defines a list of
+static list can be added to by defining CONFIG_ENV_CALLBACK_LIST_STATIC
+in the board defconfig via menuconfig to a string that defines a list of
 associations.  The list must be in the following format::
 
     entry = variable_name[:callback_name]
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index 30f7fdb8847..d9f2a838207 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -13,6 +13,7 @@ General
    codingstyle
    designprinciples
    docstyle
+   kconfig
    memory
    patman
    process
diff --git a/doc/README.kconfig b/doc/develop/kconfig.rst
index 808cf56e59c..227074dc497 100644
--- a/doc/README.kconfig
+++ b/doc/develop/kconfig.rst
@@ -1,3 +1,5 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
 Kconfig in U-Boot
 =================
 
@@ -5,22 +7,20 @@ This document describes the configuration infrastructure of U-Boot.
 
 The conventional configuration was replaced by Kconfig at v2014.10-rc1 release.
 
-
 Language Specification
 ----------------------
 
-Kconfig originates in Linux Kernel.
-See the file "Documentation/kbuild/kconfig*.txt" in your Linux Kernel
-source directory for a basic specification of Kconfig.
-
+The Kconfig configuration language originates in Linux kernel.
+See the Linux document
+`Kconfig Language <https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html>`_
+for a description of Kconfig.
 
 Difference from Linux's Kconfig
 -------------------------------
 
 Here are some worth-mentioning configuration targets.
 
-- silentoldconfig
-
+silentoldconfig
   This target updates .config, include/generated/autoconf.h and
   include/configs/* as in Linux.  In U-Boot, it also does the following
   for the compatibility with the old configuration system:
@@ -33,31 +33,26 @@ Here are some worth-mentioning configuration targets.
    * create tpl/include/autoconf.mk (TPL only)
 
    If we could completely switch to Kconfig in a long run
-   (i.e. remove all the include/configs/*.h), those additional processings
+   (i.e. remove all the include/configs/\*.h), those additional processings
    above would be removed.
 
-- defconfig
-
+defconfig
   In U-Boot, "make defconfig" is a shorthand of "make sandbox_defconfig"
 
-- <board>_defconfig
-
+<board>_defconfig
   Now it works as in Linux.
-  The prefixes such as "+S:" in *_defconfig are deprecated.
+  The prefixes such as "+S:" in \*_defconfig are deprecated.
   You can simply remove the prefixes.  Do not add them for new boards.
 
-- <board>_config
-
+<board>_config
   This does not exist in Linux's Kconfig.
   "make <board>_config" works the same as "make <board>_defconfig".
   Prior to Kconfig, in U-Boot, "make <board>_config" was used for the
   configuration.  It is still supported for backward compatibility, so
   we do not need to update the distro recipes.
 
-
 The other configuration targets work as in Linux Kernel.
 
-
 Migration steps to Kconfig
 --------------------------
 
@@ -84,68 +79,79 @@ Configuration file for use in makefiles
 When adding a new CONFIG macro, it is highly recommended to add it to Kconfig
 rather than to a header file.
 
-
 Conversion from boards.cfg to Kconfig
 -------------------------------------
 
 Prior to Kconfig, boards.cfg was a primary database that contained Arch, CPU,
-SoC, etc. of all the supported boards.  It was deleted when switching to
-Kconfig.  Each field of boards.cfg was converted as follows:
-
- Status      ->  "S:" entry of MAINTAINERS
- Arch        ->  CONFIG_SYS_ARCH defined by Kconfig
- CPU         ->  CONFIG_SYS_CPU defined by Kconfig
- SoC         ->  CONFIG_SYS_SOC defined by Kconfig
- Vendor      ->  CONFIG_SYS_VENDOR defined by Kconfig
- Board       ->  CONFIG_SYS_BOARD defined by Kconfig
- Target      ->  File name of defconfig (configs/<target>_defconfig)
- Maintainers ->  "M:" entry of MAINTAINERS
-
+SoC, etc. of all the supported boards. It was deleted when switching to
+Kconfig. Each field of boards.cfg was converted as follows:
+
+=========== ====================================================
+From        To
+=========== ====================================================
+Arch        CONFIG_SYS_ARCH defined by Kconfig
+Board       CONFIG_SYS_BOARD defined by Kconfig
+CPU         CONFIG_SYS_CPU defined by Kconfig
+Maintainers "M:" entry of MAINTAINERS
+SoC         CONFIG_SYS_SOC defined by Kconfig
+Status      "S:" entry of MAINTAINERS
+Target      File name of defconfig (configs/<target>\_defconfig)
+Vendor      CONFIG_SYS_VENDOR defined by Kconfig
+=========== ====================================================
 
 Tips to add/remove boards
 -------------------------
 
 When adding a new board, the following steps are generally needed:
 
- [1] Add a header file include/configs/<target>.h
- [2] Make sure to define necessary CONFIG_SYS_* in Kconfig:
-       Define CONFIG_SYS_CPU="cpu" to compile arch/<arch>/cpu/<cpu>
-       Define CONFIG_SYS_SOC="soc" to compile arch/<arch>/cpu/<cpu>/<soc>
-       Define CONFIG_SYS_VENDOR="vendor" to compile board/<vendor>/common/*
-         and board/<vendor>/<board>/*
-       Define CONFIG_SYS_BOARD="board" to compile board/<board>/*
-         (or board/<vendor>/<board>/* if CONFIG_SYS_VENDOR is defined)
-       Define CONFIG_SYS_CONFIG_NAME="target" to include
-         include/configs/<target>.h
- [3] Add a new entry to the board select menu in Kconfig.
-     The board select menu is located in arch/<arch>/Kconfig or
-     arch/<arch>/*/Kconfig.
- [4] Add a MAINTAINERS file
-     It is generally placed at board/<board>/MAINTAINERS or
-     board/<vendor>/<board>/MAINTAINERS
- [5] Add configs/<target>_defconfig
+1. Add a header file include/configs/<target>.h
+
+2. Make sure to define necessary CONFIG_SYS_* in Kconfig:
+
+   * Define CONFIG_SYS_CPU="cpu" to compile arch/<arch>/cpu/<cpu>
+   * Define CONFIG_SYS_SOC="soc" to compile arch/<arch>/cpu/<cpu>/<soc>
+   * Define CONFIG_SYS_VENDOR="vendor" to compile board/<vendor>/common/\*
+     and board/<vendor>/<board>/\*
+   * Define CONFIG_SYS_BOARD="board" to compile board/<board>/\*
+     (or board/<vendor>/<board>/* if CONFIG_SYS_VENDOR is defined)
+     Define CONFIG_SYS_CONFIG_NAME="target" to include
+     include/configs/<target>.h
+
+3. Add a new entry to the board select menu in Kconfig.
+   The board select menu is located in arch/<arch>/Kconfig or
+   arch/<arch>/\*/Kconfig.
+
+4. Add a MAINTAINERS file
+   It is generally placed at board/<board>/MAINTAINERS or
+   board/<vendor>/<board>/MAINTAINERS
+
+5. Add configs/<target>_defconfig
 
 When removing an obsolete board, the following steps are generally needed:
 
- [1] Remove configs/<target>_defconfig
- [2] Remove include/configs/<target>.h if it is not used by any other boards
- [3] Remove board/<vendor>/<board>/* or board/<board>/* if it is not used
-     by any other boards
- [4] Update MAINTAINERS if necessary
- [5] Remove the unused entry from the board select menu in Kconfig
- [6] Add an entry to doc/README.scrapyard
+1. Remove configs/<target>_defconfig
+
+2. Remove include/configs/<target>.h if it is not used by any other boards
+
+3. Remove board/<vendor>/<board>/\* or board/<board>/\* if it is not used
+   by any other boards
+
+4. Update MAINTAINERS if necessary
+
+5. Remove the unused entry from the board select menu in Kconfig
 
+6. Add an entry to doc/README.scrapyard
 
 TODO
 ----
 
-- In the pre-Kconfig, a single board had multiple entries in the boards.cfg
-  file with differences in the option fields.  The corresponding defconfig
-  files were auto-generated when switching to Kconfig.  Now we have too many
-  defconfig files compared with the number of the supported boards.  It is
+* In the pre-Kconfig, a single board had multiple entries in the boards.cfg
+  file with differences in the option fields. The corresponding defconfig
+  files were auto-generated when switching to Kconfig. Now we have too many
+  defconfig files compared with the number of the supported boards. It is
   recommended to have only one defconfig per board and allow users to select
   the config options.
 
-- Move the config macros in header files to Kconfig.  When we move at least
+* Move the config macros in header files to Kconfig. When we move at least
   macros used in makefiles, we can drop include/autoconfig.mk, which makes
   the build scripts much simpler.
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index 1548d2634ff..c742c2f8e20 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -71,7 +71,7 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2025.01-rc2 was released on Mon 11 November 2024.
 
-.. * U-Boot v2025.01-rc3 was released on Mon 25 November 2024.
+* U-Boot v2025.01-rc3 was released on Mon 25 November 2024.
 
 .. * U-Boot v2025.01-rc4 was released on Mon 09 December 2024.
 
diff --git a/doc/usage/cmd/wget.rst b/doc/usage/cmd/wget.rst
index b8ca35bb140..48bedf1e845 100644
--- a/doc/usage/cmd/wget.rst
+++ b/doc/usage/cmd/wget.rst
@@ -11,29 +11,54 @@ Synopsis
 
 ::
 
-    wget address [[hostIPaddr:]path]
+    wget [address] [host:]path
+    wget [address] url          # lwIP only
+
 
 Description
 -----------
 
-The wget command is used to download a file from an HTTP server.
+The wget command is used to download a file from an HTTP(S) server.
+In order to use HTTPS you will need to compile wget with lwIP support.
+
+Legacy syntax
+~~~~~~~~~~~~~
+
+The legacy syntax is supported by the legacy network stack (CONFIG_NET=y)
+as well as by the lwIP base network stack (CONFIG_NET_LWIP=y). It supports HTTP
+only.
 
-wget command will use HTTP over TCP to download files from an HTTP server.
 By default the destination port is 80 and the source port is pseudo-random.
-The environment variable *httpdstp* can be used to set the destination port.
+On the legacy nework stack the environment variable *httpdstp* can be used to
+set the destination port
 
 address
     memory address for the data downloaded
 
-hostIPaddr
-    IP address of the HTTP server, defaults to the value of environment
-    variable *serverip*
+host
+    IP address (or host name if `CONFIG_CMD_DNS` is enabled) of the HTTP
+    server, defaults to the value of environment variable *serverip*.
 
 path
     path of the file to be downloaded.
 
-Example
--------
+New syntax (lwIP only)
+~~~~~~~~~~~~~~~~~~~~~~
+
+In addition to the syntax described above, wget accepts URLs if the network
+stack is lwIP.
+
+address
+    memory address for the data downloaded
+
+url
+    HTTP or HTTPS URL, that is: http[s]://<host>[:<port>]/<path>.
+
+Examples
+--------
+
+Example with the legacy network stack
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In the example the following steps are executed:
 
@@ -52,13 +77,42 @@ In the example the following steps are executed:
     HTTP/1.0 302 Found
     Packets received 4, Transfer Successful
 
+Example with lwIP
+~~~~~~~~~~~~~~~~~
+
+In the example the following steps are executed:
+
+* setup client network address
+* download a file from the HTTPS server
+
+::
+
+   => dhcp
+   DHCP client bound to address 10.0.2.15 (3 ms)
+   => wget https://download.rockylinux.org/pub/rocky/9/isos/aarch64/Rocky-9.4-aarch64-minimal.iso
+   ##########################################################################
+   ##########################################################################
+   ##########################################################################
+   [...]
+   1694892032 bytes transferred in 492181 ms (3.3 MiB/s)
+   Bytes transferred = 1694892032 (65060000 hex)
+
 Configuration
 -------------
 
 The command is only available if CONFIG_CMD_WGET=y.
+To enable lwIP support set CONFIG_NET_LWIP=y.
+
+TCP Selective Acknowledgments in the legacy network stack can be enabled via
+CONFIG_PROT_TCP_SACK=y. This will improve the download speed. Selective
+Acknowledgments are enabled by default with lwIP.
+
+.. note::
 
-TCP Selective Acknowledgments can be enabled via CONFIG_PROT_TCP_SACK=y.
-This will improve the download speed.
+    U-Boot currently has no way to verify certificates for HTTPS.
+    A place to store the root CA certificates is needed, and then MBed TLS would
+    need to walk the entire chain. Therefore, man-in-the middle attacks are
+    possible and HTTPS should not be relied upon for payload authentication.
 
 Return value
 ------------
diff --git a/doc/usage/dfu.rst b/doc/usage/dfu.rst
index 8cc09c308d8..af805514b26 100644
--- a/doc/usage/dfu.rst
+++ b/doc/usage/dfu.rst
@@ -22,6 +22,7 @@ U-Boot implements this DFU capability (CONFIG_DFU) with the command dfu
 Today the supported DFU backends are:
 
 - MMC (RAW or FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT)
+- SCSI (UFS, RAW partition, FAT / EXT2 / EXT3 / EXT4 file system / SKIP / SCRIPT)
 - NAND
 - RAM
 - SF (serial flash)
@@ -51,6 +52,7 @@ The following configuration options are relevant to device firmware upgrade:
 * CONFIG_DFU_MTD
 * CONFIG_DFU_NAND
 * CONFIG_DFU_RAM
+* CONFIG_DFU_SCSI
 * CONFIG_DFU_SF
 * CONFIG_DFU_SF_PART
 * CONFIG_DFU_TIMEOUT
@@ -167,6 +169,36 @@ mmc
     Please note that this means the user will be able to execute any
     arbitrary commands just like in the u-boot's shell.
 
+scsi
+    for UFS storage::
+
+        dfu 0 scsi <dev>
+
+    each element in *dfu_alt_info* being
+
+    * <name> raw <offset> <size>     raw access to SCSI LUN
+    * <name> part <part_id>          raw access to partition
+    * <name> fat <part_id>           file in FAT partition
+    * <name> ext4 <part_id>          file in EXT4 partition
+    * <name> skip 0 0                ignore flashed data
+    * <name> script 0 0              execute commands in shell
+
+    with
+
+    size
+        is the size of the access area (hexadecimal without "0x")
+        or 0 which means whole device
+    partid
+        is the GPT or DOS partition index.
+    dev
+        is the SCSI LU (Logical Unit) index (decimal only)
+
+    A value of environment variable *dfu_alt_info* for UFS could be::
+
+        u-boot part 4;bl2 raw 0x1e 0x1d
+
+    See mmc section above for details on the skip and script types.
+
 nand
     raw slc nand device::
 
@@ -278,6 +310,7 @@ alternate list separated by '&' with the same format for each <alt>::
     mmc <dev>=<alt1>;....;<altN>
     nand <dev>=<alt1>;....;<altN>
     ram <dev>=<alt1>;....;<altN>
+    scsi <dev>=<alt1>;....;<altN>
     sf <dev>=<alt1>;....;<altN>
     mtd <dev>=<alt1>;....;<altN>
     virt <dev>=<alt1>;....;<altN>
diff --git a/doc/usage/fit/howto.rst b/doc/usage/fit/howto.rst
index 280eff724f6..675c9aa5bb0 100644
--- a/doc/usage/fit/howto.rst
+++ b/doc/usage/fit/howto.rst
@@ -57,10 +57,6 @@ own subnode under the /images node, which should then be referenced from one or
 multiple /configurations subnodes. The required images must be enumerated in
 the "loadables" property as a list of strings.
 
-CONFIG_SPL_FIT_GENERATOR can point to a script which generates this image source
-file during the build process. It gets passed a list of device tree files (taken
-from the CONFIG_OF_LIST symbol).
-
 The SPL also records to a DT all additional images (called loadables) which are
 loaded. The information about loadables locations is passed via the DT node with
 fit-images name.