Merge branch 'next'HEADmasterWIP/06Jul2026

22 files changed, 939 insertions, 10 deletions

diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 818b8815ebd..96c544ae11b 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -217,6 +217,10 @@ It's possible to interrupt the fastboot command using Ctrl-c::
    => fastboot usb 0
    Operation aborted.
 
+``CONFIG_CMD_FASTBOOT_ABORT_KEYED`` can be enabled so that *any* keypress
+will interrupt the fastboot command, rather than just Ctrl-c. This can be
+quite useful on mobile devices which lack a means to input Ctrl-c.
+
 You can also specify a kernel image to boot. You have to either specify
 the an image in Android format *or* pass a binary kernel and let the
 fastboot client wrap the Android suite around it. On OMAP for instance you
diff --git a/doc/board/alliedtelesis/index.rst b/doc/board/alliedtelesis/index.rst
new file mode 100644
index 00000000000..a8de2986609
--- /dev/null
+++ b/doc/board/alliedtelesis/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2026 Allied Telesis Labs
+
+Allied Telesis
+==============
+
+.. toctree::
+   :maxdepth: 2
+
+   x220
+
diff --git a/doc/board/alliedtelesis/x220.rst b/doc/board/alliedtelesis/x220.rst
new file mode 100644
index 00000000000..6ca5f61ec4e
--- /dev/null
+++ b/doc/board/alliedtelesis/x220.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2026 Allied Telesis Labs
+
+x220 Platforms
+==============
+
+Introduction
+------------
+
+The x220 has is a range of L2+ switches using the Marvell AlleyCat3 switch with
+integrated ARMv7 CPU. It is also sold under some different brands for different
+markets.
+
+- x220-52GP
+- x220-52GT
+- x220-28GS
+- GS980M/52PS
+- GS980M/52
+- x230-52
+
+DDR Traning (binhdr)
+--------------------
+
+The AlleyCat3 uses a binary blob for it's DDR training. This is launched by
+the built-in bootloader prior to U-Boot starting.
+
+To generate binary.0 from Marvell's bin_hdr.elf use the following command
+
+.. prompt:: bash $
+
+  arm-softfloat-linux-gnueabi-objcopy -S -O binary bin_hdr.elf \
+     board/alliedtelesis/x220/binary.0
+
+Alternatively, it is possible to extract the binary.0 from an existing U-Boot
+image
+
+.. prompt:: bash $
+
+   ./tools/dumpimage -T kwbimage -p 1 -o board/alliedtelesis/x220/binary.0 u-boot.kwb
diff --git a/doc/board/index.rst b/doc/board/index.rst
index fcb4224bae3..4103fef8d8f 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -10,6 +10,7 @@ Board-specific doc
    actions/index
    advantech/index
    andestech/index
+   alliedtelesis/index
    allwinner/index
    amlogic/index
    anbernic/index
diff --git a/doc/board/nxp/index.rst b/doc/board/nxp/index.rst
index 8cd24aecf33..52c8e85fa5b 100644
--- a/doc/board/nxp/index.rst
+++ b/doc/board/nxp/index.rst
@@ -30,3 +30,4 @@ NXP Semiconductors
    mx6ullevk
    rproc
    psb
+   quickboot
diff --git a/doc/board/nxp/quickboot.rst b/doc/board/nxp/quickboot.rst
new file mode 100644
index 00000000000..0fd72b4e13b
--- /dev/null
+++ b/doc/board/nxp/quickboot.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0+
+   Copyright 2026 NXP
+
+DDR QuickBoot flow
+------------------
+
+Some NXP SoCs (which use OEI - iMX943, iMX95, iMX952 etc.) support saving
+DDR training data (collected by OEI during Training flow) from volatile
+to non-volatile memory, which is then available to OEI at next cold reboot.
+OEI uses the saved data to run Quickboot flow and avoid training the DDR again.
+This significantly reduces the boot time.
+
+The location of the quickboot data in NVM is a space left in the bootloader by
+mkimage, with the size of 64K. The qb command searches for this space to
+save the data. Thus, the NVM should also be a boot device and contain
+the bootloader at the time of the saving.
+
+U-Boot provides no authentication for quickboot data, only its integrity
+is verified via the CRC32. The authentication is done in OEI. With
+the exception of iMX95 A0/A1, which use CRC32 as well for verifying
+the data, the rest of the SoCs use ELE to verify the MAC stored
+in the ddrphy_qb_state structure.
+
+If the quickboot data in memory is not valid (CRC32 check fails),
+U-Boot does not save it to NVM. So, if OEI runs Quickboot flow -> no
+data is written to volatile memory -> invalid data -> no saving happens
+(qb save fails during qb check).
+
+After successful saving, U-Boot clears the data in volatile memory so
+that qb check fails at next reboot and the NVM isn't accessed again.
+
+There are 2 ways to save this data, both can be enabled:
+
+1. automatically, in SPL (by enabling CONFIG_SPL_IMX_QB)
+
+- this will save the data on the current boot device (e.g. SD)
+- other configs specific to the boot device need to be enabled (CONFIG_SPL_MMC_WRITE for saving to eMMC/SD)
+- use for: automating qb save / saving quickboot data if using Falcon mode (skipping U-Boot proper)
+
+2. using qb command in U-Boot console (by enabling CONFIG_CMD_IMX_QB)
+
+- supports saving on the current boot device, or on another, specified device.
+- supports specifying the hwpartition for eMMC (for booting from boot0/boot1)
+- if flashing via uuu, the command can be added in an uuu script (boot device needs to be specified)
+- use 'qb erase' to force DDR re-training
+- use for: saving quickboot data during flashing / controlling the NVM to save to / forcing re-training
+
+::
+
+        # To save/erase on current boot device
+        # For eMMC boot1, mmc 0:2 has to be specified explicitly
+        => qb save/erase
+
+        # To save/erase on other boot device
+        => qb save/erase mmc 0   # eMMC boot0
+        => qb save/erase mmc 0:1 # eMMC boot0
+        => qb save/erase mmc 0:2 # eMMC boot1
+        => qb save/erase mmc 1   # SD
+        => qb save/erase spi     # NOR SPI
diff --git a/doc/board/phytec/k3-common.rst b/doc/board/phytec/k3-common.rst
index ffb50b51ad6..3adb176ea8a 100644
--- a/doc/board/phytec/k3-common.rst
+++ b/doc/board/phytec/k3-common.rst
@@ -1,6 +1,53 @@
 .. SPDX-License-Identifier: GPL-2.0+
 .. sectionauthor:: Wadim Egorov <w.egorov@phytec.de>
 
+Boot Flow
+---------
+
+The default `bootcmd` performs three steps:
+
+.. code-block::
+
+  run start_watchdog; bootflow scan -lb; run ${boot}boot
+
+Boot devices are scanned in the order given by `boot_targets`:
+
+.. code-block::
+
+  mmc1 mmc0 spi_flash dhcp
+
+For each device, U-Boot tries the boot methods listed in `bootmeths`:
+
+.. code-block::
+
+  [rauc] script efi extlinux pxe
+
+The `rauc` bootmeth is only present when `CONFIG_BOOTMETH_RAUC=y` is set in
+the A53 defconfig. RAUC slot selection is handled entirely by the bootmeth;
+no environment-side configuration is required.
+
+The legacy `${boot}boot` chain (`mmcboot`, `spiboot`, `netboot`) is kept for
+backwards compatibility and prints a deprecation warning when run. New
+deployments should rely on the standard boot mechanism (`bootflow`) only.
+
+
+Watchdog
+--------
+
+`bootcmd` runs `start_watchdog` before starting the boot flow. When
+`CONFIG_WATCHDOG_TIMEOUT_MSECS` is set to a non-zero value and the
+`watchdog` environment variable points to a watchdog device, U-Boot enables
+the watchdog with that timeout.
+
+After this point the OS is responsible for servicing the watchdog. If it
+does not feed the watchdog before the timeout expires, the SoC will reset.
+Make sure the watchdog driver is enabled and configured in the kernel and
+userspace before relying on this.
+
+To skip the watchdog start, either build with `CONFIG_WATCHDOG_TIMEOUT_MSECS=0`
+or set `watchdog_timeout_ms=0` in the environment.
+
+
 Environment
 -----------
 
diff --git a/doc/board/phytec/phycore-am62ax.rst b/doc/board/phytec/phycore-am62ax.rst
index e1f741011e7..aa3518a07ff 100644
--- a/doc/board/phytec/phycore-am62ax.rst
+++ b/doc/board/phytec/phycore-am62ax.rst
@@ -9,7 +9,7 @@ SoM (System on Module) featuring TI's AM62Ax SoC. It can be used in combination
 with different carrier boards. This module can come with different sizes and
 models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM62Ax family.
 
-A development Kit, called `phyBOARD-Lyra <https://www.phytec.com/product/phyboard-am62x>`_
+A development Kit, called `phyBOARD-Lyra <https://www.phytec.com/product/phyboard-am62a>`_
 is used as a carrier board reference design around the AM62Ax SoM.
 
 Quickstart
@@ -57,10 +57,10 @@ Set the variables corresponding to this platform:
  $ export UBOOT_CFG_CORTEXR=phycore_am62ax_r5_defconfig
  $ export UBOOT_CFG_CORTEXA=phycore_am62ax_a53_defconfig
  $ export TFA_BOARD=lite
- $ # we dont use any extra TFA parameters
+ $ # we don't use any extra TFA parameters
  $ unset TFA_EXTRA_ARGS
  $ export OPTEE_PLATFORM=k3-am62ax
- $ # we dont use any extra OPTEE parameters
+ $ # we don't use any extra OPTEE parameters
  $ unset OPTEE_EXTRA_ARGS
 
 1. Trusted Firmware-A:
@@ -147,7 +147,7 @@ the main domain serial port:
 Boot Modes
 ----------
 
-The phyCORE-AM62x development kit supports booting from many different
+The phyCORE-AM62Ax development kit supports booting from many different
 interfaces. By default, the development kit is set to boot from the micro-SD
 card. To change the boot device, DIP switches S5 and S6 can be used.
 Boot switches should be changed with power off.
diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst
index bd61d0c16cf..5349ba429d4 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -60,7 +60,7 @@ Set the variables corresponding to this platform:
  $ # we don't use any extra TFA parameters
  $ unset TFA_EXTRA_ARGS
  $ export OPTEE_PLATFORM=k3-am62x
- $ # we dont use any extra OPTEE parameters
+ $ # we don't use any extra OPTEE parameters
  $ unset OPTEE_EXTRA_ARGS
 
 .. include::  ../ti/am62x_sk.rst
@@ -177,6 +177,25 @@ Boot switches should be changed with power off.
      - 11001010
      - 00100000
 
+DDR RAM Size
+------------
+
+By default, the R5 SPL detects the populated DDR size by reading the SoM
+EEPROM and configures the DDR controller and the U-Boot device-tree memory
+node accordingly. The phyCORE-AM62x is available with 1 GB, 2 GB, or 4 GB of
+DDR. If the EEPROM cannot be read or is invalid, the SPL falls back to a
+2 GB configuration.
+
+EEPROM-based detection can be bypassed by enabling
+`CONFIG_PHYCORE_AM62X_RAM_SIZE_FIX` in the R5 defconfig and selecting one of:
+
+* `CONFIG_PHYCORE_AM62X_RAM_SIZE_1GB`
+* `CONFIG_PHYCORE_AM62X_RAM_SIZE_2GB`
+* `CONFIG_PHYCORE_AM62X_RAM_SIZE_4GB`
+
+This is mainly useful if no detection is needed or for boards without a
+populated SoM EEPROM.
+
 .. include:: k3-common.rst
 
 Further Information
diff --git a/doc/board/phytec/phycore-am64x.rst b/doc/board/phytec/phycore-am64x.rst
index 71f1fd7b404..20887d443a9 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -60,8 +60,8 @@ Set the variables corresponding to this platform:
  $ # we don't use any extra TFA parameters
  $ unset TFA_EXTRA_ARGS
  $ export OPTEE_PLATFORM=k3-am64x
- # we don't use any extra OPTEE parameters
- unset OPTEE_EXTRA_ARGS
+ $ # we don't use any extra OPTEE parameters
+ $ unset OPTEE_EXTRA_ARGS
 
 .. include::  ../ti/am62x_sk.rst
     :start-after: .. am62x_evm_rst_include_start_build_steps
@@ -148,7 +148,7 @@ Boot Modes
 
 The phyCORE-AM64x development kit supports booting from many different
 interfaces. By default, the development kit is set to boot from the micro-SD
-card. To change the boot device, DIP switches S5 and S6 can be used.
+card. To change the boot device, DIP switches SW3 and SW4 can be used.
 Boot switches should be changed with power off.
 
 .. list-table:: Boot Modes
@@ -175,6 +175,24 @@ Boot switches should be changed with power off.
      - 11011100
      - 00000000
 
+DDR RAM Size
+------------
+
+By default, the R5 SPL detects the populated DDR size by reading the SoM
+EEPROM and configures the DDR controller and the U-Boot device-tree memory
+node accordingly. The phyCORE-AM64x is available with 1 GB or 2 GB of DDR.
+If the EEPROM cannot be read or is invalid, the SPL falls back to a 2 GB
+configuration.
+
+EEPROM-based detection can be bypassed by enabling
+`CONFIG_PHYCORE_AM64X_RAM_SIZE_FIX` in the R5 defconfig and selecting one of:
+
+* `CONFIG_PHYCORE_AM64X_RAM_SIZE_1GB`
+* `CONFIG_PHYCORE_AM64X_RAM_SIZE_2GB`
+
+This is mainly useful if no detection is needed or for boards without a
+populated SoM EEPROM.
+
 .. include:: k3-common.rst
 
 Further Information
diff --git a/doc/board/toradex/aquila-imx95.rst b/doc/board/toradex/aquila-imx95.rst
new file mode 100644
index 00000000000..edd40252657
--- /dev/null
+++ b/doc/board/toradex/aquila-imx95.rst
@@ -0,0 +1,175 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Toradex Aquila iMX95 Module
+===========================
+
+- SoM: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+- Carrier board: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
+
+Quick Start
+-----------
+
+- Setup environment
+- Get ahab-container.img
+- Get DDR PHY Firmware Images
+- Get and Build OEI Images
+- Get and Build System Manager Image
+- Get and Build the ARM Trusted Firmware
+- Build the Bootloader Image
+- Boot
+
+Setup environment
+-----------------
+
+Suggested current toolchains are ARM 14.3 (https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads):
+
+- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-linux-gnueabihf.tar.xz
+- https://developer.arm.com/-/media/Files/downloads/gnu/14.3.rel1/binrel/arm-gnu-toolchain-14.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
+
+.. code-block:: console
+
+    $ export TOOLS=<path/to/directory/with/toolchains>
+    $ export CROSS_COMPILE_32=<path/to/arm/toolchain/bin/>arm-none-linux-gnueabihf-
+    $ export CROSS_COMPILE_64=<path/to/arm64/toolchain/bin/>aarch64-none-linux-gnu-
+
+Get ahab-container.img
+----------------------
+
+Note: `$srctree` is the U-Boot source directory
+
+.. code-block:: console
+
+    $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.2-89161a8.bin
+    $ sh firmware-ele-imx-2.0.2-89161a8.bin --auto-accept
+    $ cp firmware-ele-imx-2.0.2-89161a8/mx95b0-ahab-container.img $(srctree)
+
+Get DDR PHY Firmware Images
+---------------------------
+
+Note: `$srctree` is the U-Boot source directory
+
+.. code-block:: console
+
+    $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.28-994fa14.bin
+    $ sh firmware-imx-8.28-994fa14.bin --auto-accept
+    $ cp firmware-imx-8.28-994fa14/firmware/ddr/synopsys/lpddr5*v202409.bin $(srctree)
+
+Get and Build OEI Images
+------------------------
+
+Note: `$srctree` is the U-Boot source directory
+Get OEI from: https://git.toradex.com/cgit/imx-oei-toradex.git/
+branch: main
+
+.. code-block:: console
+
+    $ git clone -b main https://git.toradex.com/cgit/imx-oei-toradex.git/
+    $ cd imx-oei-toradex
+
+    $ make board=toradex-aquila-imx95 oei=ddr DEBUG=1 r=B0 all
+    $ cp build/toradex-aquila-imx95/ddr/oei-m33-ddr.bin $(srctree)
+
+    $ make board=toradex-aquila-imx95 oei=tcm DEBUG=1 r=B0 all
+    $ cp build/toradex-aquila-imx95/tcm/oei-m33-tcm.bin $(srctree)
+
+The Makefile will set `DDR_CONFIG` automatically based on the selected silicon
+revision.
+
+Get and Build the System Manager Image
+--------------------------------------
+
+Note: `$srctree` is the U-Boot source directory
+Get System Manager from: https://git.toradex.com/cgit/imx-sm-toradex.git/
+branch: main
+
+.. code-block:: console
+
+    $ git clone -b main https://git.toradex.com/cgit/imx-sm-toradex.git/
+    $ cd imx-sm-toradex
+    $ make config=aquila-imx95 all
+    $ cp build/aquila-imx95/m33_image.bin $(srctree)
+
+Get and Build the ARM Trusted Firmware
+--------------------------------------
+
+Note: `$srctree` is the U-Boot source directory
+Get ATF from: https://github.com/nxp-imx/imx-atf/
+branch: lf_v2.12
+
+.. code-block:: console
+
+    $ export CROSS_COMPILE=$CROSS_COMPILE_64
+    $ unset LDFLAGS
+    $ unset AS
+    $ git clone -b lf_v2.12 https://github.com/nxp-imx/imx-atf.git
+    $ cd imx-atf
+    $ make PLAT=imx95 bl31
+    $ cp build/imx95/release/bl31.bin $(srctree)
+
+Build the Bootloader Image
+--------------------------
+
+.. code-block:: console
+
+    $ export CROSS_COMPILE=$CROSS_COMPILE_64
+    $ make aquila-imx95_defconfig
+    $ make
+
+Flash to eMMC
+-------------
+
+.. code-block:: console
+
+    > tftpboot ${loadaddr} flash.bin
+    > setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt ${blkcnt} / 0x200
+    > mmc dev 0 1 && mmc write ${loadaddr} 0x0 ${blkcnt}
+
+As a convenience, instead of the last two commands, one may also use the update
+U-Boot wrapper:
+
+.. code-block:: console
+
+    > run update_uboot
+
+Boot
+----
+
+Boot sequence is:
+
+* SPL ---> ATF (TF-A) ---> U-Boot proper
+
+Output:
+
+.. code-block:: console
+
+    U-Boot SPL 2026.07-rc3-00300-ge16706b72e14 (Jun 11 2026 - 13:07:49 +0200)
+    SYS Boot reason: por, origin: -1, errid: -1
+    WDT:   Started watchdog@42490000 with servicing every 1000ms (40s timeout)
+    Trying to boot from MMC1
+    Load image from MMC/SD 0xd2800
+    NOTICE:  BL31: v2.10.0  (release):lf-6.6.52-2.2.1-dirty
+    NOTICE:  BL31: Built : 06:40:36, Jul  7 2025
+
+
+    U-Boot 2026.07-rc3-00300-ge16706b72e14 (Jun 11 2026 - 13:07:49 +0200)
+
+    CPU:   NXP i.MX95 Rev2.0 A55 at 1800 MHz - invalid sensor data
+    DRAM:  7.8 GiB
+    Core:  321 devices, 30 uclasses, devicetree: separate
+    WDT:   Started watchdog@42490000 with servicing every 1000ms (40s timeout)
+    MMC:   FSL_SDHC: 0, FSL_SDHC: 1
+    Loading Environment from MMC... Reading from MMC(0)... OK
+    In:    serial@44380000
+    Out:   serial@44380000
+    Err:   serial@44380000
+    Model: Toradex 0098 Aquila iMX95 Hexa 8GB WB IT V1.0A
+    Serial#: 12594391
+
+    BuildInfo:
+      - ELE firmware version 2.0.2-c110ba4b
+
+    Net:   WARNING: no MAC address assigned for MAC0
+    imx_get_mac_from_fuse: fuse read err: 0
+    eth0: enetc-0 [PRIME]
+    Hit any key to stop autoboot: 0
+    Aquila iMX95 #
diff --git a/doc/board/toradex/index.rst b/doc/board/toradex/index.rst
index 2a45bde6991..c5955ea1ad8 100644
--- a/doc/board/toradex/index.rst
+++ b/doc/board/toradex/index.rst
@@ -8,6 +8,7 @@ Toradex
 
    apalis-imx8
    aquila-am69
+   aquila-imx95
    colibri_imx7
    colibri-imx8x
    smarc-imx8mp
diff --git a/doc/board/tq/index.rst b/doc/board/tq/index.rst
index d6dc6101c2c..775957474e7 100644
--- a/doc/board/tq/index.rst
+++ b/doc/board/tq/index.rst
@@ -9,4 +9,5 @@ TQ-Systems
 .. toctree::
    :maxdepth: 2
 
+   tqma6ul
    tqma7
diff --git a/doc/board/tq/tqma6ul.rst b/doc/board/tq/tqma6ul.rst
new file mode 100644
index 00000000000..2b346715642
--- /dev/null
+++ b/doc/board/tq/tqma6ul.rst
@@ -0,0 +1,105 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later or CC-BY-4.0
+
+.. Copyright (c) 2017-2025 TQ-Systems GmbH <u-boot@ew.tq-group.com>,
+.. D-82229 Seefeld, Germany.
+
+########################################
+U-Boot for the TQ-Systems TQMa6x modules
+########################################
+
+The following hardware revisions are supported:
+
+Modules:
+
++------------+----------+
+| TQMa6ULx   | REV.030x |
++------------+----------+
+| TQMa6ULLx  | REV.030x |
++------------+----------+
+| TQMa6ULxL  | REV.030x |
++------------+----------+
+| TQMa6ULLxL | REV.030x |
++------------+----------+
+
+Mainboards:
+
++----------+----------+
+| MBa6ULx  | REV.020x |
++----------+----------+
+
+Hardware on modules TQMa6ULx, TQMa6ULxL, TQMa6ULLx and TQMa6ULLxL
+
+- eMMC
+- RTC
+- PMIC
+- SPI-NOR (optional)
+- EEPROM
+- Temperature sensor
+- RAM (256 MiB / 512 MiB)
+
+Supported hardware on Starterkit MBa6ULx:
+
+- 2 Ethernet PHY connected to FEC0 / FEC1 (usage depends on CPU)
+- SD-card slot
+- UART
+- USB
+
+Note: To change the Ethernet port to use for networking functionality, use the
+U-Boot generic environment variable ``ethact``.
+
+.. code-block:: bash
+
+    setenv ethact <FEC>
+
+***********
+Boot source
+***********
+
+- SD/eMMC
+- USB/SDP (with NXP UUU tool)
+- SPI NOR (functional but requires additional prepended NXP header.
+  Not supported in U-Boot.)
+
+********
+Building
+********
+
+To build U-Boot for the TQ-Systems TQMa6L modules:
+
+.. code-block:: bash
+
+	make <som>_<baseboard>_<boot>_defconfig
+	make
+
+
+**som**  is a placeholder for the module base variant:
+
++------------+------------+----------------+
+| tqma6ulx   | TQMa6ULx   | i.MX6UL        |
++------------+------------+----------------+
+| tqma6ullx  | TQMa6ULLx  | i.MX6ULL       |
++------------+------------+----------------+
+| tqma6ulxl  | TQMa6ULxL  | i.MX6UL (lga)  |
++------------+------------+----------------+
+| tqma6ullxl | TQMa6ULLxL | i.MX6ULL (lga) |
++------------+------------+----------------+
+
+**baseboard** is a placeholder for the mainboard to compile for:
+
++----------+----------+
+| mba6ul   | MBa6ULx  |
++----------+----------+
+
+**boot** is a placeholder for the boot device:
+
++------+---------+
+| mmc  | SD/eMMC |
++------+---------+
+| spi  | SPI-NOR |
++------+---------+
+
+************
+Support Wiki
+************
+
+See `TQ Embedded Wiki for TQMa6ulx <https://support.tq-group.com/en/arm/tqma6ulx>`_.
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 634114af59a..7d6117d5c4b 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -232,6 +232,64 @@ outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig
 option to specify a list of .dtsi files that will also be included when
 building .dtb files.
 
+Scripts embedded in control DTB
+-------------------------------
+
+The `DEVICE_TREE_INCLUDES` option can also be used to make the control
+DTB serve double duty as a FIT image. By including a `scripts.dtsi`
+file containing something like::
+
+  / {
+	images {
+		default = "boot";
+		boot {
+			description = "Bootscript";
+			data = /incbin/("boot.sh");
+			type = "script";
+			compression = "none";
+		};
+		factory-reset {
+			description = "Script for performing factory reset";
+			data = /incbin/("factory-reset.sh");
+			type = "script";
+			compression = "none";
+		};
+	};
+  };
+
+one can call those scripts using the `source` command in the U-Boot shell::
+
+  source ${fdtcontroladdr}:boot
+
+or just ``source ${fdtcontroladdr}`` for invoking the default.
+
+Since one does not need to separately build a "real" FIT image
+containing those scripts, this simplifies both the build process and
+the boot logic, as the latter does not need to first load the FIT
+image from storage.
+
+Another advantage is that when the bootloader and boot script must be
+updated together, it is easier to achieve a guaranteed atomic update
+when the boot script is embedded inside the U-Boot binary, instead of
+stored separately.
+
+For the above to work, one must enable the `CONTROL_DTB_AS_FIT` config
+option, which will (when the address passed to the `source` command is
+the address of U-Boot's control DTB) elide certain sanity checks that
+are normally done: With the above `.dtsi` snippet, the control DTB
+does not quite become a "real" FIT image - it lacks `timestamp` and
+`description` properties, but more importantly, FIT images cannot
+contain nodes with `@` in their names (unit addresses) anywhere, and
+the control DTB obviously does have such nodes.
+
+This is not a security problem, as the control DTB is necessarily
+trusted. In any secure boot setup where the bootloader is verified,
+that mechanism must also include verification of the control DTB. So
+in fact, since the scripts embedded this way are then also
+automatically verified, it simplifies implementation of secure
+boot. When using a separate FIT image, one must build it with
+appropriate signatures, just as when building a FIT image containing a
+kernel/dtb/initramfs.
 
 Devicetree bindings schema checks
 ---------------------------------
diff --git a/doc/develop/environment.rst b/doc/develop/environment.rst
index e46cd39d601..a7ed4aab0a5 100644
--- a/doc/develop/environment.rst
+++ b/doc/develop/environment.rst
@@ -49,3 +49,43 @@ The signature of the callback functions is::
   include/search.h
 
 The return value is 0 if the variable change is accepted and 1 otherwise.
+
+Flags for environment variables
+-------------------------------
+
+Environment flags validate the values given to environment variables and
+restrict how environment variables can be changed.
+
+The static list is configured with CONFIG_ENV_FLAGS_LIST_STATIC. The list
+must be in the following format::
+
+    type_attribute = [s|d|x|b|i|m]
+    access_attribute = [a|r|o|c|w]
+    attributes = type_attribute[access_attribute]
+    entry = variable_name[:attributes]
+    list = entry[,list]
+
+The type attributes are:
+
+* s - String (default)
+* d - Decimal
+* x - Hexadecimal
+* b - Boolean ([1yYtT|0nNfF])
+* i - IP address, if networking is enabled
+* m - MAC address, if networking is enabled
+
+The access attributes are:
+
+* a - Any (default)
+* r - Read-only
+* o - Write-once
+* c - Change-default
+* w - Writeable, if CONFIG_ENV_WRITEABLE_LIST is enabled
+
+CONFIG_ENV_FLAGS_LIST_DEFAULT defines the ``.flags`` variable in the
+default or embedded environment. Any association in ``.flags`` overrides
+an association in the static list.
+
+If CONFIG_REGEX is defined, the variable name is evaluated as a regular
+expression. This allows multiple variables to define the same flags without
+explicitly listing them all.
diff --git a/doc/develop/memory.rst b/doc/develop/memory.rst
index 5177229630d..3da39bb6c66 100644
--- a/doc/develop/memory.rst
+++ b/doc/develop/memory.rst
@@ -111,6 +111,15 @@ U-Boot Proper Flow
       This follows the same as in SPL flow. In board_init_f(), a part of memory
       is reserved at the end of RAM (see reserve_* functions in init_sequence_f)
 
+   #. Relocation address
+
+      By default U-Boot will try to relocate below the 4GiB boundary. If
+      RELOC_ADDR_TOP is enabled U-Boot will look into the dram bank config of
+      gd->dram[] and try to relocate to the highest available bank. Use this
+      with caution as devices that can only DMA below 4GiB will misbehave
+      since their buffers may be allocated above the 32-bit boundary.
+      Boards can override thre relocation address via board_get_usable_ram_top().
+
    #. Code Relocation
 
       relocate_code() is called which relocates U-Boot code from the current
diff --git a/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml b/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml
index df976c7ae73..ae3b5e6092a 100644
--- a/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml
+++ b/doc/device-tree-bindings/arm/adi/adi,sc5xx.yaml
@@ -18,7 +18,7 @@ properties:
     oneOf:
       - description: SC57X Series Boards
         items:
-          - const: adi,sc573-ezkit
+          - const: adi,sc573-ezlite
           - const: adi,sc57x
 
       - description: SC58X Series Boards
diff --git a/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt b/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt
new file mode 100644
index 00000000000..678fff0e812
--- /dev/null
+++ b/doc/device-tree-bindings/sysinfo/tq,eeprom-sysinfo.txt
@@ -0,0 +1,36 @@
+TQ EEPROM Sysinfo Driver
+------------------------
+
+This binding describes a sysinfo provider which retrieves system
+identification information from an I2C EEPROM device.
+
+Required properties:
+
+- compatible: "tq,eeprom-sysinfo"
+- nvmem-cells: phandle referencing the nvmem cell
+- nvmem-cell-names: string, should be "device_info"
+
+Example:
+
+&i2c1 {
+	eeprom@50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+
+		nvmem-layout {
+			compatible = "fixed-layout";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			module_info: module-info@20 {
+				reg = <0x20 0x60>;
+			};
+		};
+	};
+};
+
+sysinfo {
+	compatible = "tq,eeprom-sysinfo";
+	nvmem-cells = <&module_info>;
+	nvmem-cell-names = "device_info";
+};
diff --git a/doc/usage/cmd/wdt.rst b/doc/usage/cmd/wdt.rst
index 711b74d20da..28abf98def9 100644
--- a/doc/usage/cmd/wdt.rst
+++ b/doc/usage/cmd/wdt.rst
@@ -16,7 +16,7 @@ Synopsis
     wdt start <timeout_ms> [flags]
     wdt stop
     wdt reset
-    wdt expirer [flags]
+    wdt expire [flags]
 
 Description
 -----------
diff --git a/doc/usage/fit/dm-verity.rst b/doc/usage/fit/dm-verity.rst
new file mode 100644
index 00000000000..800a18fceae
--- /dev/null
+++ b/doc/usage/fit/dm-verity.rst
@@ -0,0 +1,304 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+FIT dm-verity Boot Parameters
+=============================
+
+Introduction
+------------
+
+Linux's dm-verity device-mapper target provides transparent integrity
+checking of block devices using a Merkle tree. It is commonly used to
+protect read-only root filesystems such as SquashFS images.
+
+When a FIT image packages the root filesystem as a loadable sub-image of
+type ``filesystem`` (``IH_TYPE_FILESYSTEM``), the verity metadata can be
+stored alongside the image data in a ``dm-verity`` subnode. U-Boot reads
+this metadata at boot time and generates the kernel command-line parameters
+that Linux needs to activate the verity target, eliminating the need for
+an initramfs or userspace helper to set up dm-verity.
+
+This feature is enabled by ``CONFIG_FIT_VERITY`` (see ``boot/Kconfig``).
+
+Prerequisites
+-------------
+
+* **Linux uImage.FIT block driver** – the kernel must include the FIT block
+  driver that exposes loadable sub-images as ``/dev/fit0``, ``/dev/fit1``,
+  etc. The driver assigns device numbers in the order loadables appear in
+  the FIT configuration.
+
+* **dm-verity support in the kernel** – ``CONFIG_DM_VERITY`` must be
+  enabled so the kernel can process the ``dm-mod.create=`` parameter.
+
+* **CONFIG_FIT_VERITY** enabled in U-Boot.
+
+How it works
+------------
+
+The implementation is split into a **build** phase and an **apply** phase,
+both of which run automatically within the ``bootm`` state machine. No boot
+method needs to call verity functions explicitly.
+
+**Build phase** (``BOOTM_STATE_FINDOTHER`` → ``boot_get_loadable()``)
+
+1. After all loadable sub-images have been loaded,
+   ``fit_verity_build_cmdline()`` iterates the configuration's
+   ``loadables`` list.
+
+2. For each loadable that is an ``IH_TYPE_FILESYSTEM`` image **and**
+   contains a ``dm-verity`` child node, a dm-verity target specification is
+   built by the helper ``fit_verity_build_target()``.
+
+3. The dm-verity target references ``/dev/fitN``, where *N* is the
+   zero-based index of the loadable in the configuration. This matches the
+   numbering used by the Linux FIT block driver.
+
+4. The resulting fragments are stored in ``struct bootm_headers``:
+
+   ``images->dm_mod_create``
+     The full dm-verity target table. Multiple targets are separated by ``;``.
+
+   ``images->dm_mod_waitfor``
+     Comma-separated list of ``/dev/fitN`` devices so the kernel waits for
+     the underlying FIT block devices to appear before activating
+     device-mapper.
+
+**Apply phase** (``BOOTM_STATE_OS_PREP``)
+
+5. Just before ``bootm_process_cmdline_env()`` processes the ``bootargs``
+   environment variable, ``fit_verity_apply_bootargs()`` appends the
+   ``dm-mod.create=`` and ``dm-mod.waitfor=`` parameters.
+
+**Bootmeth integration**
+
+  Because the fragments are stored in ``struct bootm_headers``, a boot
+  method can check ``fit_verity_active(images)`` between bootm state
+  invocations. A typical pattern splits ``bootm_run_states()`` into two
+  calls -- one for ``START|FINDOS|FINDOTHER|LOADOS`` and one for
+  ``OS_PREP|OS_GO`` -- and inspects ``fit_verity_active()`` in
+  between to decide whether to add a ``root=`` parameter pointing at the
+  dm-verity device.
+
+FIT image source (.its) example
+-------------------------------
+
+Below is a minimal ``.its`` file showing a kernel and a dm-verity-protected
+root filesystem packaged as a FIT. Only the three user-provided properties
+(``algo``, ``data-block-size``, ``hash-block-size``) are included; ``mkimage``
+computes and fills in ``digest``, ``salt``, ``num-data-blocks``, and
+``hash-start-block`` automatically (see `Generating verity metadata`_ below)::
+
+    /dts-v1/;
+
+    / {
+        description = "Kernel + dm-verity rootfs";
+        #address-cells = <1>;
+
+        images {
+            kernel {
+                description = "Linux kernel";
+                data = /incbin/("./Image.gz");
+                type = "kernel";
+                arch = "arm64";
+                os = "linux";
+                compression = "gzip";
+                load = <0x44000000>;
+                entry = <0x44000000>;
+                hash-1 {
+                    algo = "sha256";
+                };
+            };
+
+            fdt {
+                description = "Device tree blob";
+                data = /incbin/("./board.dtb");
+                type = "flat_dt";
+                arch = "arm64";
+                compression = "none";
+                hash-1 {
+                    algo = "sha256";
+                };
+            };
+
+            rootfs {
+                description = "SquashFS root filesystem";
+                data = /incbin/("./rootfs.squashfs");
+                type = "filesystem";
+                arch = "arm64";
+                compression = "none";
+                hash-1 {
+                    algo = "sha256";
+                };
+
+                dm-verity {
+                    algo = "sha256";
+                    data-block-size = <4096>;
+                    hash-block-size = <4096>;
+                };
+            };
+        };
+
+        configurations {
+            default = "config-1";
+            config-1 {
+                description = "Boot with dm-verity rootfs";
+                kernel = "kernel";
+                fdt = "fdt";
+                loadables = "rootfs";
+            };
+        };
+    };
+
+With this configuration U-Boot produces a kernel command line similar to::
+
+    dm-mod.create="rootfs,,, ro,0 <data_sectors> verity 1 \
+        /dev/fit0 /dev/fit0 4096 4096 3762 3762 sha256 \
+        8e6791637f93cbb81fc45299e203cbe85ca2e47a38f5051bddeece92d7b1c9f9 \
+        aa7b11f8db8fe2e5bfd4eca1d18a22b5de7ea39d2e1b93bb7272ce0c6ca3cc8e" \
+    dm-mod.waitfor=/dev/fit0
+
+dm-verity subnode properties
+----------------------------
+
+User-provided properties (required in the ``.its``):
+
+.. list-table::
+   :header-rows: 1
+   :widths: 20 15 65
+
+   * - Property
+     - Type
+     - Description
+   * - ``algo``
+     - string
+     - Hash algorithm name, e.g. ``"sha256"``.
+   * - ``data-block-size``
+     - u32
+     - Data block size in bytes (>= 512, typically 4096).
+   * - ``hash-block-size``
+     - u32
+     - Hash block size in bytes (>= 512, typically 4096).
+
+Computed properties (filled in by ``mkimage``):
+
+.. list-table::
+   :header-rows: 1
+   :widths: 20 15 65
+
+   * - Property
+     - Type
+     - Description
+   * - ``num-data-blocks``
+     - u32
+     - Number of data blocks in the filesystem image (computed from the
+       image size and ``data-block-size``).
+   * - ``hash-start-block``
+     - u32
+     - Offset in ``hash-block-size``-sized blocks from the start of the
+       sub-image to the root block of the hash tree.
+   * - ``digest``
+     - byte array
+     - Root hash of the Merkle tree, stored as raw bytes. Length must match
+       the output size of ``algo``.
+   * - ``salt``
+     - byte array
+     - Salt used when computing the Merkle tree, stored as raw bytes.
+
+These values are the same ones produced by ``veritysetup format`` and can
+typically be obtained from its output.
+The ``digest`` and ``salt`` byte arrays correspond to the hex-encoded
+``Root hash`` and ``Salt`` printed by ``veritysetup format``.
+
+Optional boolean properties (when present, they are collected and appended
+as dm-verity optional parameters with hyphens converted to underscores):
+
+.. list-table::
+   :header-rows: 1
+   :widths: 30 70
+
+   * - Property
+     - Description
+   * - ``restart-on-corruption``
+     - Restart the system on data corruption.
+   * - ``panic-on-corruption``
+     - Panic the system on data corruption.
+   * - ``restart-on-error``
+     - Restart the system on I/O error.
+   * - ``panic-on-error``
+     - Panic the system on I/O error.
+   * - ``check-at-most-once``
+     - Verify data blocks only on first read.
+
+
+Generating verity metadata
+--------------------------
+
+``mkimage`` automates the entire process. When it encounters a
+``dm-verity`` subnode, it:
+
+1. Writes the embedded image data to a temporary file.
+2. Runs ``veritysetup format`` with the user-supplied algorithm and
+   block sizes.
+3. Parses ``Root hash`` and ``Salt`` from ``veritysetup`` stdout.
+4. Reads the expanded content (original data + Merkle hash tree) back
+   into an in-memory buffer and removes the temporary file.  The
+   external-data section written to the .itb file uses this buffer in
+   place of the original ``data`` property.
+5. Writes the computed ``digest``, ``salt``, ``num-data-blocks``, and
+   ``hash-start-block`` properties into the ``dm-verity`` subnode.
+
+Images with ``dm-verity`` subnodes **must** use external data layout
+(``mkimage -E``). ``mkimage`` will abort with an error if ``-E`` is
+not specified.
+
+Usage::
+
+    # Create the filesystem image
+    mksquashfs rootfs/ rootfs.squashfs -comp xz
+
+    # Build the FIT (dm-verity is computed automatically); align each
+    # external-data section to the block size of the underlying storage
+    # (see the alignment note below).
+    mkimage -E -B 0x1000 -f image.its image.itb
+
+``veritysetup`` (from the cryptsetup_ package) must be installed on
+the build host.
+
+.. _cryptsetup: https://gitlab.com/cryptsetup/cryptsetup
+
+.. note::
+
+   ``veritysetup format`` is invoked with ``--no-superblock``, so no
+   on-disk superblock is written between the data and hash regions.
+   The Merkle hash tree is appended directly to the image data within
+   the FIT external data section. ``hash-start-block`` is therefore
+   computed as ``data_size / hash-block-size`` (the offset of the hash
+   region in units of ``hash-block-size``). When ``data-block-size``
+   equals ``hash-block-size`` this happens to equal ``num-data-blocks``.
+
+.. note::
+
+   The Linux ``fitblk`` driver currently requires each ``filesystem``
+   sub-image to start and end on block boundaries of the underlying
+   block device (typically 512 bytes, sometimes 4 KiB for eMMC or NVMe
+   with 4 KiB native sectors). Use ``mkimage -B <align>`` to pad
+   external-data sections to that boundary; ``-B 0x1000`` is a safe
+   default for the storage in common use.
+
+   This alignment requirement comes from the kernel-side ``fitblk``
+   driver to avoid unaligned-access fix-up overhead in block I/O, and
+   is **independent** of the dm-verity ``data-block-size`` and
+   ``hash-block-size`` properties -- those describe the block sizes
+   used by the device-mapper verity target itself, not storage
+   alignment.
+
+Kconfig
+-------
+
+``CONFIG_FIT_VERITY``
+  Depends on ``CONFIG_FIT`` and ``CONFIG_OF_LIBFDT``.
+  When enabled, ``fit_verity_build_cmdline()`` and
+  ``fit_verity_apply_bootargs()`` are compiled into the boot path.
+  When disabled, the functions are static inlines returning 0, so there
+  is no code-size impact. Works with both the ``bootm`` command and
+  BOOTSTD boot methods.
diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index 6c78d8584ed..d17582b1d64 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -11,6 +11,7 @@ images that it reads and boots. Documentation about FIT is available in
     :maxdepth: 1
 
     beaglebone_vboot
+    dm-verity
     howto
     kernel_fdt
     kernel_fdts_compressed