Merge branch 'next'

author: Tom Rini <[email protected]> 2026-04-06 12:16:57 -0600
committer: Tom Rini <[email protected]> 2026-04-06 12:16:57 -0600
commit: 93f84ee022a8401421cdaab84fe7d106d83fdb4a (patch)
tree: fb15a4af876e8faf9893fd86c1c0e127265dbe9a /doc
parent: 88dc2788777babfd6322fa655df549a019aa1e69 (diff)
parent: e2138cf1e6088f12ffa874e87cc8f4b198378635 (diff)
31 files changed, 1168 insertions, 493 deletions
diff --git a/doc/api/led.rst b/doc/api/led.rst
index 9ae3f5fe252..fe1904aea0d 100644
--- a/doc/api/led.rst
+++ b/doc/api/led.rst
@@ -8,66 +8,3 @@ LED
 
 .. kernel-doc:: include/led.h
    :internal:
-
-Legacy LED
-==========
-
-Please use the new LED API as defined above. This section is only for reference
-for currently supported devices and to aid for migration to the new API.
-
-Status LED
-----------
-
-This README describes the status LED API.
-
-The API is defined by the include file include/status_led.h
-
-The first step is to enable CONFIG_LED_STATUS in menuconfig::
-
-   > Device Drivers > LED Support.
-
-If the LED support is only for specific board, enable
-CONFIG_LED_STATUS_BOARD_SPECIFIC in the menuconfig.
-
-Status LEDS 0 to 5 are enabled by the following configurations at menuconfig:
-CONFIG_STATUS_LED0, CONFIG_STATUS_LED1, ... CONFIG_STATUS_LED5
-
-The following should be configured for each of the enabled LEDs:
-
-- CONFIG_STATUS_LED_BIT<n>
-- CONFIG_STATUS_LED_STATE<n>
-- CONFIG_STATUS_LED_FREQ<n>
-
-Where <n> is an integer 1 through 5 (empty for 0).
-
-CONFIG_STATUS_LED_BIT is passed into the __led_* functions to identify which LED
-is being acted on. As such, the value choose must be unique with respect to
-the other CONFIG_STATUS_LED_BIT's. Mapping the value to a physical LED is the
-reponsiblity of the __led_* function.
-
-CONFIG_STATUS_LED_STATE is the initial state of the LED. It should be set to one
-of these values: CONFIG_LED_STATUS_OFF or CONFIG_LED_STATUS_ON.
-
-CONFIG_STATUS_LED_FREQ determines the LED blink frequency.
-Values range from 2 to 10.
-
-Some other LED macros
-~~~~~~~~~~~~~~~~~~~~~
-
-CONFIG_STATUS_LED_BOOT is the LED to light when the board is booting.
-This must be a valid LED number (0-5).
-
-General LED functions
-~~~~~~~~~~~~~~~~~~~~~
-The following functions should be defined:
-
-__led_init is called once to initialize the LED to CONFIG_STATUS_LED_STATE.
-One time start up code should be placed here.
-
-__led_set is called to change the state of the LED.
-
-__led_toggle is called to toggle the current state of the LED.
-
-TBD : Describe older board dependent macros similar to what is done for
-
-TBD : Describe general support via asm/status_led.h
diff --git a/doc/board/acer/picasso.rst b/doc/board/acer/picasso.rst
index b1d360defd8..47c6f7f00c5 100644
--- a/doc/board/acer/picasso.rst
+++ b/doc/board/acer/picasso.rst
@@ -5,7 +5,8 @@ U-Boot for the Acer Iconia Tab A500
 
 ``DISCLAMER!`` Moving your Acer Iconia Tab A500 to use U-Boot assumes
 replacement of the vendor Acer bootloader. Vendor Android firmwares will no
-longer be able to run on the device. This replacement IS reversible.
+longer be able to run on the device. This replacement IS reversible if you have
+backups.
 
 Quick Start
 -----------
@@ -13,6 +14,7 @@ Quick Start
 - Build U-Boot
 - Process U-Boot
 - Flashing U-Boot into the eMMC
+- Flashing U-Boot into the eMMC with NvFlash
 - Boot
 - Self Upgrading
 
@@ -36,61 +38,45 @@ in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
 usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+to recover the device in case of a failed update. You need to know your device
+individual SBK to continue.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev a500
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev a500 --sbk <your sbk> --split
 
-Processing for pre-loaded U-Boot
-********************************
+where SBK has next form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
 
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it either by pre-loading vendor bootloader into RAM with the nvflash.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and ``volume up`` buttons on
+turned off tablet connected to the host PC. Host PC should detect APX USB
+device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ nvflash --setbct --bct picasso.bct --configfile flash.cfg --bl bootloader.bin
-        --sbk 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX 0xXXXXXXXX --sync # replace with your SBK
-    $ nvflash --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ ./utils/nvflash_t20 --setbct --bct ./bct/picasso.bct --configfile ./utils/flash.cfg
+        --bl u-boot-dtb-tegra.bin --sbk <your sbk> --sync
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -104,6 +90,37 @@ After, on host PC, do:
 
 Device will reboot.
 
+Flashing U-Boot into the eMMC with NvFlash
+------------------------------------------
+
+``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
+
+This method is discouraged and is used only if fastboot commands from previous
+chapter failed with ``Writing '0.1' FAILED (remote: 'too large for partition')``
+error. This error means that your tablet has 512 Kb boot0/boot1 partitons which
+is too small to contain U-Boot image as the minimum boot partition size must
+me 1 MB. This situation can be workarounded but self-update will not work and
+flashing to eMMC will wipe U-Boot. This should not be a big issue since installing
+OS on microSD is a preferred method anyway.
+
+This method involves use of Nv3p. Nv3p is a custom Nvidia protocol used to
+recover bricked devices. Devices can enter it by pre-loading vendor bootloader
+into RAM with the nvflash.
+
+With Nv3p, ``repart-block.bin`` is used (produced by re-crypt without ``--split``
+key). It contains BCT and a bootloader in encrypted state in form, which can just
+be written RAW at the start of eMMC. Place your ``repart-block.bin`` and vendor
+bootloader with name ``bootloader.bin`` into fusee-tools folder and run:
+
+.. code-block:: bash
+
+    $ ./utils/nvflash_t20 --setbct --bct ./bct/picasso.bct --configfile ./utils/flash.cfg
+        --bl ./bootloader.bin --sbk <your sbk> --sync
+    $ ./utils/nvflash_t20 --resume --rawdevicewrite 0 512 ./repart-block.bin
+
+When flashing is done, reboot the device.
+
 Boot
 ----
 
@@ -113,8 +130,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/asus/grouper.rst b/doc/board/asus/grouper.rst
index 14469582907..78183482a00 100644
--- a/doc/board/asus/grouper.rst
+++ b/doc/board/asus/grouper.rst
@@ -5,7 +5,8 @@ U-Boot for the ASUS/Google Nexus 7 (2012)
 
 ``DISCLAMER!`` Moving your ASUS/Google Nexus 7 (2012) to use U-Boot assumes
 replacement of the vendor ASUS bootloader. Vendor android firmwares will no
-longer be able to run on the device. This replacement IS reversible.
+longer be able to run on the device. This replacement IS reversible if you
+have backups.
 
 Quick Start
 -----------
@@ -39,65 +40,45 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update. You need to know your
-tablet's individual SBK to continue.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update. You need to know your device
+individual SBK to continue.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev grouper --sbk <your sbk>
+    $ ./re-crypt.py --dev grouper --sbk <your sbk> --split # or --dev tilapia
 
 where SBK has next form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
 
-The script will produce a ``repart-block.bin`` ready to flash.
-
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with the Fusée Gelée.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and ``volume up`` buttons on
+turned off tablet connected to the host PC. Host PC should detect APX USB
+device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ ./run_bootloader.sh -s T30 -t ./bct/grouper.bct -b android_bootloader.bin
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device. Note that if you have cellular version,
-use ``tilapia.bct``.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ ./run_bootloader.sh -s T30 -t ./bct/grouper.bct --b u-boot-dtb-tegra.bin # or tilapia.bct
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -120,8 +101,8 @@ bootmenu. Bootmenu contains entries to mount eMMC as mass storage, fastboot,
 reboot, reboot RCM, poweroff, enter U-Boot console and update bootloader (check
 the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/asus/transformer_t20.rst b/doc/board/asus/transformer_t20.rst
index 4f4f893c3a8..2b721b4c076 100644
--- a/doc/board/asus/transformer_t20.rst
+++ b/doc/board/asus/transformer_t20.rst
@@ -5,7 +5,8 @@ U-Boot for the ASUS Eee Pad Transformer device family
 
 ``DISCLAMER!`` Moving your ASUS Eee Pad Transformer/Slider to use U-Boot
 assumes replacement of the vendor ASUS bootloader. Vendor Android firmwares
-will no longer be able to run on the device. This replacement IS reversible.
+will no longer be able to run on the device. This replacement IS reversible
+if you have backups.
 
 Quick Start
 -----------
@@ -40,61 +41,46 @@ in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
 usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+to recover the device in case of a failed update. You need to know your device
+individual SBK to continue.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev tf101
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev tf101v1 --split # or tf101v2 or sl101 as --dev
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it either by using ``wheelie`` with the correct ``blob.bin`` file or by
-pre-loading vendor bootloader with the Fusée Gelée.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and ``volume up`` buttons on
+turned off tablet connected to the host PC. Host PC should detect APX USB
+device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ wheelie -1 --bl bootloader.bin --bct tf101.bct --odm 0x300d8011 || break
-    $ nvflash --resume --rawdevicewrite 0 2048 repart-block.bin
-
-When flashing is done, reboot the device.
-
-Flashing with a pre-loaded U-Boot
-*********************************
+    $ ./utils/nvflash_t20 --setbct --bct ./bct/<dev>.bct --configfile ./utils/flash.cfg
+        --bl u-boot-dtb-tegra.bin --sbk <your sbk> --sync
 
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+Where <dev> is your devie codename, either ``tf101`` or ``sl101`` and <your sbk> is SBK
+of your device in the form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -117,8 +103,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/asus/transformer_t30.rst b/doc/board/asus/transformer_t30.rst
index 012a38251aa..cab8b32f97e 100644
--- a/doc/board/asus/transformer_t30.rst
+++ b/doc/board/asus/transformer_t30.rst
@@ -5,7 +5,7 @@ U-Boot for the ASUS Transformer device family
 
 ``DISCLAMER!`` Moving your ASUS Transformer to use U-Boot assumes replacement
 of the vendor ASUS bootloader. Vendor Android firmwares will no longer be
-able to run on the device. This replacement IS reversible.
+able to run on the device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -45,65 +45,51 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update. You need to know your
-tablet's individual SBK to continue.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update. You need to know your device
+individual SBK to continue.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev tf201 --sbk <your sbk>
+    $ ./re-crypt.py --dev tf201 --sbk <your sbk> --split
 
 where SBK has next form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
 
-The script will produce a ``repart-block.bin`` ready to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+``NOTE!`` If you have TF700T it may have different sizes of boot0/boot1 partitions,
+re-crypt sets default boot partition size to 2MB and if you have different size
+add ``--bootsize`` key with yout boot partition size in bytes to the command.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with the Fusée Gelée.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and ``volume up`` buttons on
+turned off tablet connected to the host PC. Host PC should detect APX USB
+device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ ./run_bootloader.sh -s T30 -t ./bct/tf201.bct -b android_bootloader.bin
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device. Note that you should adjust bct file
-name according to your device.
+    $ ./run_bootloader.sh -s T30 -t ./bct/<dev>.bct --b u-boot-dtb-tegra.bin
 
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+Where <dev> is your devie codename (``tf201``, ``tf300t``, ``tf700t`` etc.).
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -124,6 +110,14 @@ Some of Transformers use a separate 4 MB SPI flash, which contains all data
 required for boot. It is flashed from within U-Boot itself, preloaded into RAM
 using Fusée Gelée.
 
+Create ``repart-block.bin`` using re-crypt without ``--split`` key:
+
+.. code-block:: bash
+
+    $ git clone https://gitlab.com/grate-driver/re-crypt.git
+    $ cd re-crypt # place your u-boot-dtb-tegra.bin here
+    $ ./re-crypt.py --dev tf600t --sbk <your sbk>
+
 After creating your ``repart-block.bin`` you have to place it on a 1st partition
 of microSD card formated in fat. Then insert this microSD card into your tablet
 and boot it using Fusée Gelée and U-Boot, which was included into
@@ -147,8 +141,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/htc/endeavoru.rst b/doc/board/htc/endeavoru.rst
index 53df2d09a6f..415356da4e5 100644
--- a/doc/board/htc/endeavoru.rst
+++ b/doc/board/htc/endeavoru.rst
@@ -3,9 +3,9 @@
 U-Boot for the HTC One X (endeavoru)
 ====================================
 
-``DISCLAMER!`` Moving your HTC ONe X to use U-Boot assumes replacement of the
+``DISCLAMER!`` Moving your HTC One X to use U-Boot assumes replacement of the
 vendor hboot. Vendor android firmwares will no longer be able to run on the
-device. This replacement IS reversible.
+device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -35,61 +35,42 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev endeavoru
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev endeavoru --split
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with the Fusée Gelée.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. For HTC One X (endeavoru) this mode can be entered using ``fastboot oem rcm``
+command from modified S-OFF bootloader or using testpad on motherboard. Host PC
+should detect APX USB device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ ./run_bootloader.sh -s T30 -t ./bct/endeavoru.bct -b android_bootloader.bin
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ ./run_bootloader.sh -s T30 -t ./bct/endeavoru.bct --b u-boot-dtb-tegra.bin
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -112,8 +93,8 @@ bootmenu. Bootmenu contains entries to mount eMMC as mass storage, fastboot,
 reboot, reboot RCM, poweroff, enter U-Boot console and update bootloader (check
 the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/lg/star.rst b/doc/board/lg/star.rst
index 9e480929182..580a6ee9468 100644
--- a/doc/board/lg/star.rst
+++ b/doc/board/lg/star.rst
@@ -5,7 +5,7 @@ U-Boot for the LG Optimus 2X P990
 
 ``DISCLAMER!`` Moving your device to use U-Boot assumes replacement of the
 vendor bootloader. Vendor Android firmwares will no longer be able to run on
-the device. This replacement IS reversible.
+the device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -35,62 +35,42 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev star
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev star --split
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue. Additionally you must install ``tegrarcm``.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with nvflash.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and both volume buttons on
+turned off phone connected to the host PC. Host PC should detect APX USB device
+in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ ./nvflash_v1.13.87205 --bct star.bct --setbct --odmdata 0xC8000
-      --configfile flash.cfg --bl android_bootloader.bin --sync
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 2048 repart-block.bin
-
-When flashing is done, reboot the device.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ tegrarcm --bct ./bct/star.bct --bootloader u-boot-dtb-tegra.bin --loadaddr 0x108000
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -113,8 +93,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/lg/x3_t30.rst b/doc/board/lg/x3_t30.rst
index 9ff75034b72..45a75f6d57f 100644
--- a/doc/board/lg/x3_t30.rst
+++ b/doc/board/lg/x3_t30.rst
@@ -5,7 +5,7 @@ U-Boot for the LG X3 T30 device family
 
 ``DISCLAMER!`` Moving your LG P880 or P895 to use U-Boot assumes replacement
 of the vendor LG bootloader. Vendor android firmwares will no longer be able
-to run on the device. This replacement IS reversible.
+to run on the device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -38,62 +38,42 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev p895
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev p895 --split # or --dev p880
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with the Fusée Gelée.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered by holding ``power`` and both buttons on turned
+off phone connected to the host PC. Host PC should detect APX USB device in
+``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
 
 .. code-block:: bash
 
-    $ ./run_bootloader.sh -s T30 -t ./bct/p895.bct -b android_bootloader.bin
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device. Note that if you have Optimus 4x HD,
-use ``p880.bct``.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ ./run_bootloader.sh -s T30 -t ./bct/p895.bct --b u-boot-dtb-tegra.bin # or p880.bct
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -116,8 +96,8 @@ bootmenu. Bootmenu contains entries to mount eMMC as mass storage, fastboot,
 reboot, reboot RCM, poweroff, enter U-Boot console and update bootloader (check
 the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/microsoft/surface-2.rst b/doc/board/microsoft/surface-2.rst
index 8185c6f5ae4..93d9d613cdb 100644
--- a/doc/board/microsoft/surface-2.rst
+++ b/doc/board/microsoft/surface-2.rst
@@ -33,7 +33,7 @@ directory with
 
 .. code-block:: bash
 
-    $ ./run_bootloader.sh -s T30 -t ./bct/surface-2.bct
+    $ ./run_bootloader.sh -s T114 -t ./bct/surface-2.bct
 
 To boot Linux, U-Boot will look for an ``extlinux.conf`` on MicroSD and then on
 eMMC. Additionally, if the Volume Down button is pressed while loading, the
diff --git a/doc/board/motorola/mot.rst b/doc/board/motorola/mot.rst
index d0f89bcd357..80f85ec9dfd 100644
--- a/doc/board/motorola/mot.rst
+++ b/doc/board/motorola/mot.rst
@@ -67,9 +67,26 @@ Flashing U-Boot into the eMMC
 ``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
+
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
+
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. For Motorola Atrix 4G (MB860) and Droid X2 (MB870) this mode can be entered
+from vendor bootloader menu and with special cable from prerequisites chapter.
+Host PC should detect APX USB device in ``lsusb``.
+
 U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
 U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
+
+.. code-block:: bash
+
+    $ ./utils/nvflash_t20 --setbct --bct ./bct/olympus.bct --configfile ./utils/flash.cfg
+      --bl u-boot-dtb-tegra.bin --sbk <your sbk> --sync
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -92,8 +109,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/nxp/imx952_evk.rst b/doc/board/nxp/imx952_evk.rst
new file mode 100644
index 00000000000..f5f4d8d4b0c
--- /dev/null
+++ b/doc/board/nxp/imx952_evk.rst
@@ -0,0 +1,112 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx952_evk
+==========
+
+U-Boot for the NXP i.MX952 15x15 LPDDR4X EVK board
+
+Quick Start
+-----------
+
+- 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
+
+Get ahab-container.img
+----------------------
+
+Note: srctree is U-Boot source directory
+
+.. code-block:: bash
+
+   $ wget https://nl2-nxrm.sw.nxp.com/repository/IMX_Yocto_Internal_Mirror_Recent/firmware-ele-imx-2.0.5-50c4793.bin
+   $ sh firmware-ele-imx-2.0.5-50c4793.bin --auto-accept
+   $ cp firmware-ele-imx-2.0.5-50c4793/mx952a0-ahab-container.img $(srctree)
+
+Get DDR PHY Firmware Images
+---------------------------
+
+Note: srctree is U-Boot source directory
+
+.. code-block:: bash
+
+   $ wget https://nl2-nxrm.sw.nxp.com/repository/IMX_Yocto_Internal_Mirror_Recent/firmware-imx-8.32-c0491e4.bin
+   $ sh firmware-imx-8.32-c0491e4.bin --auto-accept
+   $ cp firmware-imx-8.32-c0491e4/firmware/ddr/synopsys/lpddr4x*v202409.bin $(srctree)
+
+Get and Build OEI Images
+------------------------
+
+Note: srctree is U-Boot source directory
+Get OEI from: https://github.com/nxp-imx/imx-oei
+branch: lf-6.18.2-imx952-er1
+
+.. code-block:: bash
+
+   $ sudo apt -y install make gcc g++-multilib srecord
+   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ tar xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ export TOOLS=$PWD
+   $ git clone https://github.com/nxp-imx/imx-oei/ -b lf-6.18.2-imx952-er1
+   $ cd imx-oei
+   $ make board=mx952lp4x-15 oei=ddr DEBUG=1 all
+   $ cp build/mx952lp4x-15/ddr/oei-m33-ddr.bin $(srctree)
+
+Get and Build System Manager Image
+----------------------------------
+
+Note: srctree is U-Boot source directory
+Get System Manager from: https://github.com/nxp-imx/imx-sm
+branch: lf-6.18.2-imx952-er1
+
+.. code-block:: bash
+
+   $ sudo apt -y install make gcc g++-multilib srecord
+   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ tar xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ export TOOLS=$PWD
+   $ git clone https://github.com/nxp-imx/imx-sm/ -b lf-6.18.2-imx952-er1
+   $ cd imx-sm
+   $ make config=mx952evk all
+   $ cp build/mx952evk/m33_image.bin $(srctree)
+
+Get and Build the ARM Trusted Firmware
+--------------------------------------
+
+Note: srctree is U-Boot source directory
+Get ATF from: https://github.com/nxp-imx/imx-atf/
+branch: lf-6.18.2-imx952-er1
+
+.. code-block:: bash
+
+   $ export CROSS_COMPILE=aarch64-poky-linux-
+   $ unset LDFLAGS
+   $ unset AS
+   $ git clone https://github.com/nxp-imx/imx-atf/ -b lf-6.18.2-imx952-er1
+   $ cd imx-atf
+   $ make PLAT=imx952 bl31
+   $ cp build/imx952/release/bl31.bin $(srctree)
+
+Build the Bootloader Image
+--------------------------
+
+.. code-block:: bash
+
+   $ export CROSS_COMPILE=aarch64-poky-linux-
+   $ make imx952_evk_defconfig
+   $ make
+
+Copy flash.bin to the MicroSD card:
+
+.. code-block:: bash
+
+   $ sudo dd if=flash.bin of=/dev/sd[x] bs=1k seek=32 conv=fsync
+
+Boot
+----
+
+Set i.MX952 boot device to MicroSD card
diff --git a/doc/board/nxp/imx95_evk.rst b/doc/board/nxp/imx95_evk.rst
index b8c3f4bed50..593981e6a65 100644
--- a/doc/board/nxp/imx95_evk.rst
+++ b/doc/board/nxp/imx95_evk.rst
@@ -60,8 +60,8 @@ branch: master
 .. code-block:: bash
 
    $ sudo apt -y install make gcc g++-multilib srecord
-   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/13.3.rel1/binrel/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz
-   $ tar xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz
+   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ tar xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
    $ export TOOLS=$PWD
    $ git clone -b master https://github.com/nxp-imx/imx-oei.git
    $ cd imx-oei
@@ -100,8 +100,8 @@ branch: master
 .. code-block:: bash
 
    $ sudo apt -y install make gcc g++-multilib srecord
-   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/13.3.rel1/binrel/arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz
-   $ tar xvf arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi.tar.xz
+   $ wget https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/binrel/arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
+   $ tar xvf arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz
    $ export TOOLS=$PWD
    $ git clone -b master https://github.com/nxp-imx/imx-sm.git
    $ cd imx-sm
@@ -152,7 +152,7 @@ i.MX95 B0 silicon version on 15x15 LPDDR4X EVK
    $ make imx95_15x15_evk_defconfig
    $ make
 
-Copy imx-boot-imx95.bin to the MicroSD card:
+Copy flash.bin to the MicroSD card:
 
 .. code-block:: bash
 
diff --git a/doc/board/nxp/index.rst b/doc/board/nxp/index.rst
index 01d3468a47d..8cd24aecf33 100644
--- a/doc/board/nxp/index.rst
+++ b/doc/board/nxp/index.rst
@@ -19,6 +19,7 @@ NXP Semiconductors
    imx93_frdm
    imx943_evk
    imx95_evk
+   imx952_evk
    imxrt1020-evk
    imxrt1050-evk
    imxrt1170-evk
diff --git a/doc/board/ouya/ouya.rst b/doc/board/ouya/ouya.rst
index 641affc6294..6cc68b01f90 100644
--- a/doc/board/ouya/ouya.rst
+++ b/doc/board/ouya/ouya.rst
@@ -5,7 +5,7 @@ U-Boot for the Ouya Game Console (ouya)
 
 ``DISCLAMER!`` Moving your Ouya to use U-Boot assumes replacement of the
 vendor bootloader. Vendor android firmwares will no longer be able to run on the
-device. This replacement IS reversible.
+device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -35,62 +35,44 @@ Process U-Boot
 in re-crypt repo issues. NOT HERE!
 
 re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
-usable by device. This process is required only on the first installation or
-to recover the device in case of a failed update.
-
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
+usable by device. This process is required only on the first installation or to
+recover the device in case of a failed update. You need to know your device
+individual SBK to continue.
 
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev ouya
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev ouya --sbk <your sbk> --split
 
-Processing for pre-loaded U-Boot
-********************************
+where SBK has next form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
 
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM. Regardless of the method bct and bootloader
-will end up in boot0 and boot1 partitions of eMMC.
-
-Flashing with the NV3P protocol
-*******************************
-
-``DISCLAMER!`` All questions related to NvFlash should be asked in the proper
+``DISCLAMER!`` All questions related to fusee-tools should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Devices can
-enter it by pre-loading vendor bootloader with the Fusée Gelée.
-
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-.. code-block:: bash
-
-    $ ./run_bootloader.sh -s T30 -t ./bct/ouya.bct -b android_bootloader.bin
-    $ ./utiils/nvflash_v1.13.87205 --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device.
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue.
 
-Flashing with a pre-loaded U-Boot
-*********************************
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered from testpad on motherboard with device connected
+to the host PC. Host PC should detect APX USB device in ``lsusb``.
 
 U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
 U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+fusee-tools:
+
+.. code-block:: bash
+
+    $ ./run_bootloader.sh -s T30 -t ./bct/ouya.bct --b u-boot-dtb-tegra.bin
 
 While pre-loading U-Boot, interrupt bootflow by pressing ``CTRL + C`` (USB keyboard
 must be plugged in before U-Boot is preloaded, else it will not work), input
@@ -113,8 +95,8 @@ bootmenu provides entries to mount eMMC as mass storage, fastboot, reboot,
 reboot RCM, poweroff, enter U-Boot console and update bootloader (check
 the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/phytec/imx93-phycore.rst b/doc/board/phytec/imx91-93-phycore.rst
index bd110a3ebee..42bcda100e0 100644
--- a/doc/board/phytec/imx93-phycore.rst
+++ b/doc/board/phytec/imx91-93-phycore.rst
@@ -1,9 +1,11 @@
 .. SPDX-License-Identifier: GPL-2.0+
 
-phyCORE-i.MX 93
-===============
+phyCORE-i.MX 91/93
+==================
 
-U-Boot for the phyCORE-i.MX 93.
+U-Boot for the phyCORE-i.MX 91/93. Both SoC variants, that is i.MX 91 and i.MX 93,
+are supported by same board code, however each variant uses different defconfig
+and ATF/ELE firmware blobs. Please follow the correct steps for the populated SoC.
 
 Quick Start
 -----------
@@ -18,7 +20,17 @@ Get and Build the ARM Trusted firmware
 
 Note: srctree is U-Boot source directory
 Get ATF from: https://github.com/nxp-imx/imx-atf/
-branch: lf_v2.8
+branch: lf_v2.12
+
+For phyCORE-i.MX 91 variant:
+
+.. code-block:: bash
+
+   $ unset LDFLAGS
+   $ make PLAT=imx91 bl31
+   $ cp build/imx91/release/bl31.bin $(srctree)
+
+For phyCORE-i.MX 93 variant:
 
 .. code-block:: bash
 
@@ -41,14 +53,24 @@ Get ahab-container.img
 
 .. code-block:: bash
 
-   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin
-   $ chmod +x firmware-sentinel-0.11.bin
-   $ ./firmware-sentinel-0.11.bin
-   $ cp firmware-sentinel-0.11/mx93a1-ahab-container.img $(srctree)
+   $ wget  https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-1.3.0-17945fc.bin
+   $ chmod +x firmware-ele-imx-1.3.0-17945fc.bin
+   $ ./firmware-ele-imx-1.3.0-17945fc.bin
+   $ cp firmware-ele-imx-1.3.0-17945fc/mx91a0-ahab-container.img $(srctree)
+   $ cp firmware-ele-imx-1.3.0-17945fc/mx93a1-ahab-container.img $(srctree)
 
 Build U-Boot
 ------------
 
+For phyCORE-i.MX 91 variant:
+
+.. code-block:: bash
+
+   $ make imx91-phycore_defconfig
+   $ make
+
+For phyCORE-i.MX 93 variant:
+
 .. code-block:: bash
 
    $ make imx93-phycore_defconfig
diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst
index dd9edd792f4..4519079ab3d 100644
--- a/doc/board/phytec/index.rst
+++ b/doc/board/phytec/index.rst
@@ -8,7 +8,7 @@ PHYTEC
 
    imx8mp-libra-fpsc
    imx8mm-phygate-tauri-l
-   imx93-phycore
+   imx91-93-phycore
    phycore-am62x
    phycore-am62ax
    phycore-am64x
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 6ae4d4371ff..141071f528a 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -40,15 +40,17 @@ List of mainline supported Rockchip boards:
 * rk3229
      - Rockchip Evb-RK3229 (evb-rk3229)
 * rk3288
-     - Rockchip Evb-RK3288 (evb-rk3288)
+     - Rockchip Evb-RK3288-rk808 (evb-rk3288-rk808)
      - Firefly-RK3288 (firefly-rk3288)
      - MQmaker MiQi (miqi-rk3288)
      - Phytec RK3288 PCM-947 (phycore-rk3288)
      - PopMetal-RK3288 (popmetal-rk3288)
      - Radxa Rock 2 Square (rock2)
+     - Radxa Rock Pi N8 (rock-pi-n8-rk3288)
      - Tinker-RK3288 (tinker-rk3288)
+     - Tinker-S-RK3288 (tinker-s-rk3288)
      - Google Jerry (chromebook_jerry)
-     - Google Mickey (chromebook_mickey)
+     - Google Mickey (chromebit_mickey)
      - Google Minnie (chromebook_minnie)
      - Google Speedy (chromebook_speedy)
      - Amarula Vyasa-RK3288 (vyasa-rk3288)
@@ -101,6 +103,7 @@ List of mainline supported Rockchip boards:
 
 * rk3528
      - ArmSoM Sige1 (sige1-rk3528)
+     - FriendlyElec NanoPi Zero2 (nanopi-zero2-rk3528)
      - Generic RK3528 (generic-rk3528)
      - Radxa E20C (radxa-e20c-rk3528)
      - Radxa ROCK 2A/2F (rock-2-rk3528)
@@ -154,7 +157,7 @@ List of mainline supported Rockchip boards:
      - FriendlyElec NanoPi R6C (nanopi-r6c-rk3588s)
      - FriendlyElec NanoPi R6S (nanopi-r6s-rk3588s)
      - GameForce Ace (gameforce-ace-rk3588s)
-     - Generic RK3588S/RK3588 (generic-rk3588)
+     - Generic RK3582/RK3588S/RK3588 (generic-rk3588)
      - Hardkernel ODROID-M2 (odroid-m2-rk3588s)
      - Indiedroid Nova (nova-rk3588s)
      - Khadas Edge2 (khadas-edge2-rk3588s)
@@ -163,7 +166,7 @@ List of mainline supported Rockchip boards:
      - Radxa ROCK 5 ITX (rock-5-itx-rk3588)
      - Radxa ROCK 5A (rock5a-rk3588s)
      - Radxa ROCK 5B/5B+/5T (rock5b-rk3588)
-     - Radxa ROCK 5C (rock-5c-rk3588s)
+     - Radxa ROCK 5C/5C Lite (rock-5c-rk3588s)
      - Rockchip Toybrick TB-RK3588X (toybrick-rk3588)
      - Theobroma Systems RK3588-SBC Jaguar (jaguar-rk3588)
      - Theobroma Systems SOM-RK3588-Q7 - Tiger (tiger-rk3588)
@@ -244,7 +247,7 @@ To build rk3288 boards:
 
 .. code-block:: bash
 
-        make evb-rk3288_defconfig
+        make evb-rk3288-mk808_defconfig
         make CROSS_COMPILE=arm-linux-gnueabihf-
 
 To build rk3308 boards:
diff --git a/doc/board/samsung/n1.rst b/doc/board/samsung/n1.rst
index 4dbb3141774..89bd2c8d6d1 100644
--- a/doc/board/samsung/n1.rst
+++ b/doc/board/samsung/n1.rst
@@ -5,7 +5,8 @@ U-Boot for the Samsung N1 device family
 
 ``DISCLAMER!`` Moving your Samsung Galaxy R (GT-I9103) or Samsung Captivate Glide
 (SGH-i927) to use U-Boot assumes replacement of the sboot. Vendor android firmwares
-will no longer be able to run on the device. This replacement IS reversible.
+will no longer be able to run on the device. This replacement IS reversible if you
+have backups.
 
 Quick Start
 -----------
diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst
index f85d7376b44..0996e0a68aa 100644
--- a/doc/board/starfive/index.rst
+++ b/doc/board/starfive/index.rst
@@ -10,5 +10,6 @@ StarFive
    milk-v_mars
    milkv_marscm_emmc
    milkv_marscm_lite
+   orangepi_rv
    pine64_star64
    visionfive2
diff --git a/doc/board/starfive/jh7110_common.rst b/doc/board/starfive/jh7110_common.rst
index 77102fcc189..e9c0ed5b022 100644
--- a/doc/board/starfive/jh7110_common.rst
+++ b/doc/board/starfive/jh7110_common.rst
@@ -162,8 +162,8 @@ Build U-Boot
        git -C opensbi.git checkout v1.7
        # always clean build directory when building OpenSBI due to incomplete
        # dependency tracking
-       make -C opensbi.git -O opensbi clean
-       make -C opensbi.git -O opensbi PLATFORM=generic
+       make -C opensbi.git O=opensbi clean
+       make -C opensbi.git O=opensbi PLATFORM=generic
 
 4.  Now build the First Stage BootLoader (U-Boot Secondary Program Loader) and
     Second Boot Loader (OpenSBI + U-Boot Main):
@@ -171,9 +171,8 @@ Build U-Boot
     .. code-block:: console
 
        git clone https://source.denx.de/u-boot/u-boot.git u-boot.git
-       make -C u-boot.git -O u-boot starfive_visionfive2_defconfig
-       export OPENSBI=opensbi/build/platform/generic/firmware/fw_dynamic.bin
-       make -C u-boot.git -O u-boot
+       make -C u-boot.git O=u-boot starfive_visionfive2_defconfig
+       make -C u-boot.git O=u-boot OPENSBI=opensbi/platform/generic/firmware/fw_dynamic.bin
 
     This will generate the U-Boot SPL image object post-processed with StarFive
     SPL headers (u-boot/spl/u-boot-spl.bin.normal.out) as well as the FIT image
@@ -191,7 +190,7 @@ Build U-Boot
          --set-val SPL_DEBUG_UART_BASE 0x10000000 \
          --set-val DEBUG_UART_SHIFT 2
 
-        make -C u-boot.git -O u-boot olddefconfig
+        make -C u-boot.git O=u-boot olddefconfig
 
 Boot description
 ----------------
diff --git a/doc/board/starfive/orangepi_rv.rst b/doc/board/starfive/orangepi_rv.rst
new file mode 100644
index 00000000000..29cc58a1e2b
--- /dev/null
+++ b/doc/board/starfive/orangepi_rv.rst
@@ -0,0 +1,35 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Xunlong OrangePi RV
+===================
+
+U-Boot for the OrangePi RV uses the same U-Boot binaries as the VisionFive 2
+board. In U-Boot SPL the actual board is detected as a VisionFive2 1.3b due to
+a manufacturer problem and having the same EEPROM data as VisionFive2 1.3b.
+
+Device-tree selection
+---------------------
+
+U-Boot will set variable $fdtfile to starfive/jh7110-starfive-visionfive-2-v1.3b.dtb
+
+This is sufficient for U-Boot however fails to work correctly with the Linux Kernel.
+
+To overrule this selection the variable can be set manually and saved in the
+environment
+
+::
+
+    env set fdtfile starfive/jh7110-orangepi-rv.dtb
+    env save
+
+EEPROM modification
+-------------------
+
+For advanced users and developers an EEPROM identifier product serial number
+beginning with "XOPIRV" will match the OrangePi RV and automatically set the
+correct device-tree at U-Boot SPL phase. The procedure for writing EEPROM data
+is not detailed here however is similar to that of the Pine64 Star64 and Milk-V
+Mars CM. The write-protect disable pads on the Orange Pi RV circuit board
+bottom are labeled WP and GND near the M.2 connector.
+
+.. include:: jh7110_common.rst
diff --git a/doc/board/ti/am335x_evm.rst b/doc/board/ti/am335x_evm.rst
index b14ba41917e..904881b4146 100644
--- a/doc/board/ti/am335x_evm.rst
+++ b/doc/board/ti/am335x_evm.rst
@@ -481,3 +481,83 @@ bind with it:
   misc          0  [ + ]   ti-musb-wrapper       |   |-- usb@47400000
   usb           0  [   ]   ti-musb-peripheral    |   |   |-- usb@47401000
   usb           0  [   ]   ti-musb-host          |   |   `-- usb@47401800
+
+Failsafe bootloader update
+--------------------------
+
+As indicated above, the ROM code on the AM335x supports loading SPL
+from one of several different locations. It looks at offsets 0,
+128KiB, 256KiB and 384KiB (sectors 0, 0x100, 0x200, 0x300) for a
+sector containing a valid "TOC structure" (see the reference manual
+for details).
+
+This can be used to implement a scheme for updating SPL which is
+robust against power failure or other interruptions: Suppose we store
+copies of SPL (wrapped in the "MLO" image, which is what includes that
+TOC structure) at offsets 128KiB and 256KiB, and let us refer to those
+two locations as slot 1 and slot 2.
+
+The whole procedure maintains the invariant that at any time, at
+least one of the slots contains a complete and valid MLO image. In
+order to update SPL:
+
+(1) Determine a slot X containing a valid image (by having a proper
+    TOC structure in the first sector). Designate the other
+    slot Y. Since the TOC is always the same 512 bytes (see section
+    26.1.11 in the reference manual), checking for a valid image can
+    be done using something like
+
+.. code-block:: bash
+
+   if cmp -s -n 512 MLO /path/to/SPL-1 ; then
+     X=1
+     Y=2
+   elif cmp -s -n 512 MLO /path/to/SPL-2 ; then
+     X=2
+     Y=1
+   else
+     # invariant broken, fatal error, refuse update...
+   fi
+
+(2) Ensure Y will be deemed invalid by the ROM code by writing all
+    zeroes to the first sector of Y, for example using
+
+.. code-block:: bash
+
+   dd if=/dev/zero of=/path/to/SPL-Y bs=512 count=1 conv=fsync
+
+(3) Write everything but the first sector of the MLO image to slot Y:
+
+.. code-block:: bash
+
+   dd if=MLO of=/path/to/SPL-Y bs=512 skip=1 seek=1 conv=fsync
+
+(4) Write the TOC structure to slot Y:
+
+.. code-block:: bash
+
+   dd if=MLO of=/path/to/SPL-Y bs=512 count=1 conv=fsync
+
+(5) Repeat steps (2)--(4) for slot X.
+
+Now, this procedure only accounts for safely updating SPL. If U-Boot
+proper is only stored in a single location, there is no way to update
+that which is safe against powercut during the update. However, by
+selecting the configuration option CONFIG_SPL_AM33XX_MMCSD_MULTIPLE,
+you can tell SPL to load U-Boot proper from a location which depends on
+where SPL itself was loaded from. Hence, one can for example put
+copies of u-boot.img at offsets 512KiB and 1536KiB, and set
+
+::
+
+  CONFIG_SPL_AM33XX_MMCSD_MULTIPLE=y
+  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR_128K=0x400
+  CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR_256K=0xc00
+
+and amend the step (3) above by
+
+   Write U-Boot proper to the location corresponding to slot Y:
+
+.. code-block:: bash
+
+    dd if=u-boot.img of=/path/to/U-BOOT-Y bs=512 conv=fsync
diff --git a/doc/board/ti/j784s4_evm.rst b/doc/board/ti/j784s4_evm.rst
index d858dc7cdbb..fb767bedbf6 100644
--- a/doc/board/ti/j784s4_evm.rst
+++ b/doc/board/ti/j784s4_evm.rst
@@ -299,6 +299,10 @@ http://www.ti.com/lit/zip/spruj52 under the `Boot Mode Pins` section.
      - 00000000
      - 01110000
 
+   * - PCIe
+     - 10001000
+     - 01010000
+
 For SW7 and SW11, the switch state in the "ON" position = 1.
 
 Boot Mode Pins for AM69-SK
@@ -330,6 +334,307 @@ section.
 
 For SW2, the switch state in the "ON" position = 1.
 
+PCIe Boot
+---------
+
+The J784S4 SoC supports booting over PCIe, allowing the device to function
+as a PCIe endpoint and receive boot loader images from a PCIe Root Complex.
+The PCIe1 instance of PCIe is configured by Boot ROM for Endpoint Mode of
+operation. Hence, the PCIe Connector on the EVM corresponding to PCIe1
+should be utilized for PCIe Boot.
+
+Hardware Setup
+^^^^^^^^^^^^^^
+
+To boot the J784S4 EVM via PCIe, the following hardware setup is required:
+
+1. Configure the boot mode switches on J784S4-EVM for PCIe boot:
+
+   .. code-block:: text
+
+      SW7:  01010000
+      SW11: 10001000
+
+2. Connect the J784S4-EVM (endpoint) to a PCIe Root Complex (e.g., x86 host)
+   using a PCIe cable. Both boards should be powered off before making the
+   connection.
+
+Endpoint Configuration
+^^^^^^^^^^^^^^^^^^^^^^
+
+The following configuration options are enabled by default in
+``j784s4_evm_r5_defconfig`` and ``j784s4_evm_a72_defconfig``:
+
+- ``CONFIG_SPL_PCI_DFU_BAR_SIZE``: Size of the PCIe BAR for DFU/boot image download
+- ``CONFIG_SPL_PCI_DFU_VENDOR_ID``: PCIe vendor ID advertised by the endpoint
+- ``CONFIG_SPL_PCI_DFU_DEVICE_ID``: PCIe device ID advertised by the endpoint
+- ``CONFIG_SPL_PCI_DFU_MAGIC_WORD``: Magic word written by Root Complex to signal image transfer completion
+- ``CONFIG_SPL_PCI_DFU_BOOT_PHASE``: Current boot phase indicator for Root Complex
+
+By default, PCIe Root Complex mode is enabled in the device tree. For PCIe Boot,
+build the Bootloaders with the following content added to k3-j784s4-evm-u-boot.dtsi:
+
+.. code-block:: devicetree
+
+   &serdes0 {
+           /delete-property/ serdes0_usb_link;
+   };
+
+   &serdes_refclk {
+           bootph-all;
+   };
+
+   &serdes0_pcie1_link {
+           bootph-all;
+   };
+
+   &serdes_ln_ctrl {
+           bootph-all;
+   };
+
+   &pcie1_ctrl {
+           bootph-all;
+   };
+
+   &pcie1_rc {
+           status = "disabled";
+   };
+
+   &cbass_main {
+           pcie1_ep: pcie-ep@2910000 {
+                   compatible = "ti,j784s4-pcie-ep";
+                   reg = <0x00 0x02910000 0x00 0x1000>,
+                         <0x00 0x02917000 0x00 0x400>,
+                         <0x00 0x0d800000 0x00 0x00800000>,
+                         <0x00 0x18000000 0x00 0x08000000>;
+                   reg-names = "intd_cfg", "user_cfg", "reg", "mem";
+                   interrupt-names = "link_state";
+                   interrupts = <GIC_SPI 330 IRQ_TYPE_EDGE_RISING>;
+                   ti,syscon-pcie-ctrl = <&pcie1_ctrl 0x0>;
+                   max-link-speed = <3>;
+                   num-lanes = <2>;
+                   power-domains = <&k3_pds 333 TI_SCI_PD_EXCLUSIVE>;
+                   clocks = <&k3_clks 333 0>;
+                   clock-names = "fck";
+                   max-functions = /bits/ 8 <6>;
+                   max-virtual-functions = /bits/ 8 <4 4 4 4 0 0>;
+                   dma-coherent;
+                   phys = <&serdes0_pcie1_link>;
+                   phy-names = "pcie-phy";
+                   bootph-all;
+           };
+   };
+
+PCIe Boot Procedure
+^^^^^^^^^^^^^^^^^^^
+
+The following steps describe the process of booting J784S4-EVM over PCIe:
+
+1. Compile the sample host program (provided after this section):
+
+   .. prompt:: bash
+
+      gcc -o pcie_boot_util pcie_boot_util.c
+
+2. Power on the J784S4-EVM (endpoint) after configuring boot mode switches
+   for PCIe Boot.
+
+3. Copy the compiled sample host program (pcie_boot_util) and the bootloader
+   images to the Root Complex. Check PCIe enumeration on Root Complex to ensure
+   that the J784S4 EVM shows up as the PCIe Endpoint:
+
+   .. prompt:: bash
+
+      lspci
+
+   The endpoint will appear as a RAM device or with multiple functions:
+
+   .. code-block:: text
+
+      0000:00:00.0 PCI bridge: Texas Instruments Device b012
+      0000:01:00.0 RAM memory: Texas Instruments Device b012
+      0000:01:00.1 Non-VGA unclassified device: Texas Instruments Device 0100
+      0000:01:00.2 Non-VGA unclassified device: Texas Instruments Device 0100
+
+4. Copy ``tiboot3.bin`` to the endpoint. Use ``lspci -vv`` to identify the BAR
+   address:
+
+   .. prompt:: bash
+
+      sudo ./pcie_boot_util 0x4007100000 tiboot3.bin
+
+   The sample program automatically writes the image start address to
+   ``0x41CF3FE0`` and the magic word ``0xB17CEAD9`` to ``0x41CF3FE4``.
+
+5. After ``tiboot3.bin`` is processed, the PCIe link will go down briefly.
+   Remove the PCIe device and rescan the bus:
+
+   .. prompt:: bash
+
+      echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
+      echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/rescan
+      lspci
+
+   The enumeration will change to something similar:
+
+   .. code-block:: text
+
+      0000:00:00.0 PCI bridge: Texas Instruments Device b012
+      0000:01:00.0 RAM memory: Texas Instruments Device b010 (rev dc)
+
+   .. note::
+
+      When the Root-Complex enumerates the PCIe Endpoint after a 'remove-rescan' sequence,
+      it is possible that the 'BAR' appears 'disabled'. If so, writing to the BAR via the
+      'pcie_boot_util' to transfer the bootloader image will have no effect. In such cases,
+      run 'setpci -s 0000:01:00.0 COMMAND=0x02' on the Root-Complex after enumeration
+      (with appropriate DOMAIN:BUS:DEVICE.FUNCTION corresponding to the Endpoint) to enable
+      the BAR.
+
+6. Copy ``tispl.bin`` to the new BAR address (use ``lspci -vv`` to find):
+
+   .. prompt:: bash
+
+      sudo ./pcie_boot_util 0x4000400000 tispl.bin
+
+7. After ``tispl.bin`` is processed, the PCIe link will go down again. Remove
+   and rescan the PCIe device:
+
+   .. prompt:: bash
+
+      echo 1 > /sys/bus/pci/devices/0000\:01\:00.0/remove
+      echo 1 > /sys/bus/pci/devices/0000\:00\:00.0/rescan
+
+8. Copy ``u-boot.img``:
+
+   .. prompt:: bash
+
+      sudo ./pcie_boot_util 0x4000400000 u-boot.img
+
+9. After ``u-boot.img`` is successfully loaded, the boot process is complete
+   and endpoint should boot till U-Boot prompt.
+
+.. note::
+
+   During the boot process, "PCIe LINK DOWN" messages might appear in kernel
+   logs. This is expected as the endpoint resets and re-initializes the PCIe
+   link after processing each boot stage.
+
+Sample Host Program
+^^^^^^^^^^^^^^^^^^^
+
+The following C program can be used on the Root Complex to copy bootloader images
+to the J784S4 endpoint:
+
+.. code-block:: c
+
+   #include <stdio.h>
+   #include <stdlib.h>
+   #include <fcntl.h>
+   #include <sys/mman.h>
+   #include <unistd.h>
+   #include <string.h>
+
+   #define MAP_SIZE 0x400000
+
+   /*
+    * bootloader_file: Path to the bootloader image (tiboot3.bin, tispl.bin and u-boot.img)
+    * bootloader_mem: Memory allocated in RAM for reading the bootloader image file
+    * bar_address: Address of BAR to which bootloader image will be written
+    * bar_map_base: Mapping of the BAR Base Address for the program
+    * load_address: Address in BAR region where bootloader is being transferred
+    * transfer_completion_offset: Offset in BAR region to write to notify completion of transfer
+    * fd_mem: File descriptor for opening /dev/mem
+    * fptr: File pointer for bootloader image in filesystem
+    * magic_word: Magic word to notify completion of tiboot3.bin transfer to Boot ROM
+    * use_magic_word: Flag to indicate if Magic Word has to be written
+    * file_size: Size of bootloader image
+    * i: Iterator used during bootloader image transfer
+    */
+   int main(int argc, char *argv[])
+   {
+      off_t bar_address, load_address, transfer_completion_offset;
+      unsigned char *bootloader_mem;
+      const char *bootloader_file;
+      int fd_mem, i, use_magic_word;
+      unsigned int magic_word;
+      void *bar_map_base;
+      long file_size;
+      FILE * fptr;
+
+      if (argc != 3) {
+          printf("Usage: %s <bar_address> <bootloader_file>\n", argv[0]);
+          return 0;
+      }
+
+      bar_address = strtoul(argv[1], NULL, 16);
+      bootloader_file = argv[2];
+
+      printf("Bootloader File: %s\n", bootloader_file);
+      printf("BAR Address: 0x%lx\n", bar_address);
+
+      if(!strcmp(bootloader_file,"tiboot3.bin")) {
+          transfer_completion_offset = 0xF3FE0;
+          load_address = 0x41C00000;
+          magic_word = 0xB17CEAD9;
+          use_magic_word = 1;
+      } else {
+          transfer_completion_offset = MAP_SIZE - 0x4;
+          load_address = 0xDEADBEEF;
+          use_magic_word = 0;
+      }
+
+      fd_mem = open("/dev/mem", O_RDWR | O_SYNC);
+      if(fd_mem == -1) {
+          printf("failed to open /dev/mem\n");
+          return -1;
+      }
+
+      bar_map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd_mem, bar_address);
+      if(bar_map_base == (void *)-1) {
+          printf("failed to map BAR\n");
+          return -1;
+      }
+
+      fptr = fopen(bootloader_file, "rb");
+      if (!fptr) {
+          printf("failed to read bootloader file\n");
+          return -1;
+      }
+
+      fseek(fptr, 0, SEEK_END);
+      file_size = ftell(fptr);
+      rewind(fptr);
+
+      bootloader_mem = (unsigned char *)malloc(sizeof(char) * file_size);
+      if(!bootloader_mem) {
+         printf("failed to allocate local memory for bootloader file\n");
+         return -1;
+      }
+
+      if (fread(bootloader_mem, 1, file_size, fptr) != file_size) {
+          printf("failed to read bootloader file into local memory\n");
+          return -1;
+      }
+
+      for(i = 0; i < file_size; i++) {
+          *((char *)(bar_map_base) + i) = bootloader_mem[i];
+      }
+
+      *(unsigned int *)(bar_map_base + transfer_completion_offset) = (unsigned int)(load_address);
+
+      if(use_magic_word) {
+          *(unsigned int *)(bar_map_base + transfer_completion_offset + 4) = magic_word;
+          printf("Magic word written for Boot ROM\n");
+      }
+
+      printf("Transferred %s to Endpoint\n", bootloader_file);
+      return 0;
+   }
+
+This program copies the boot image to the PCIe endpoint's memory region and
+writes the necessary control words to signal image transfer completion.
+
 Debugging U-Boot
 ----------------
 
diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index ed04a57c167..74ece0c9acf 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -678,6 +678,72 @@ filesystem and then imported
   fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
   env import -t ${loadaddr} ${filesize}
 
+Built-in Self-Test (BIST)
+--------------------------
+
+Built-in Self-test (BIST) is a feature that allows self testing of the memory
+areas and logic circuitry in an Integrated Circuit (IC) without any external
+test equipment. In an embedded system, these tests are typically used during
+boot time or shutdown of the system to check the health of an SoC. PBIST is used
+to test the memory regions in the SoC and provides detection for permanent
+faults. The primary use case for PBIST is when it is invoked at start-up
+providing valuable information on any stuck-at bits in the memory. LBIST is used
+to test the logic circuitry in an SoC associated with the CPU cores. There are
+multiple LBIST instances in the SoC, and each has a different processor core
+associated with it. There are LBIST tests that can be software-initiated.
+
+Current implementation triggers the BIST tests on the MAIN_R5_2_x cores and is
+supported only on J784S4-EVM.
+
+LBIST/PBIST checks of the WKUP_DMSC0 and MCU_R5FSS0 cores and memories are run
+in the WKUP/MCU domain; this check is part of HW POST. HW POST runs in hardware,
+before the ROM code starts and can be selected by MCU_BOOTMODE[09:08] pins.
+
+Enable BIST in (:ref:`A72 SPL build <k3_rst_include_start_build_steps_uboot>`)
+by including its config fragment.
+
+.. prompt:: bash $
+
+  make $UBOOT_CFG_CORTEXA k3_bist.config
+
+K3 DDR Subsystem (DDRSS) with Inline ECC
+----------------------------------------
+
+For SDRAM data integrity, the DDRSS bridge supports inline ECC on the data
+written to or read from the SDRAM. ECC is stored together with the data so that
+a dedicated SDRAM device for ECC is not required. The 8-bit single error
+correction double error detection (SECDED) ECC data is calculated over 64-bit
+data quanta. For every 256-byte data block 32 bytes of ECC is stored inline.
+Thus, 1/9th of the total SDRAM space is used for ECC storage and the remaining
+8/9th of the SDRAM data space are seen as consecutive byte addresses. Even if
+there are non-ECC protected regions the previously described 1/9th-8/9th rule
+still applies and consecutive byte addresses are seen from system point of view.
+
+ECC is calculated for all accesses that are within the address ranges protected
+by it. 1-bit error is correctable by ECC, but multi-bit and multiple 1-bit
+errors are not correctable and will be treated as an uncorrectable error. Any
+uncorrectable error will cause a bus abort.
+
+Enable inline ECC in (:ref:`R5 SPL build <k3_rst_include_start_build_steps_spl_r5>`)
+by including its config fragment:
+
+.. prompt:: bash $
+
+  make $UBOOT_CFG_CORTEXR k3_inline_ecc.config
+
+This enables inline ECC for the entire region. Instead of defaulting for the
+entire DDR region, a partial range can also be selected. In this case, the DDRSS
+driver expects such a node within the memory node, in the absence of which it
+resorts to enabling for the entire DDR region:
+
+.. code-block:: dts
+
+  inline_ecc: protected@9e780000 {
+    device_type = "ecc";
+    reg = <0x9e780000 0x0080000>;
+    bootph-all;
+  };
+
 .. _k3_rst_refer_openocd:
 
 Common Debugging environment - OpenOCD
diff --git a/doc/board/wexler/qc750.rst b/doc/board/wexler/qc750.rst
index 169629c7e47..8cf118032cf 100644
--- a/doc/board/wexler/qc750.rst
+++ b/doc/board/wexler/qc750.rst
@@ -5,7 +5,7 @@ U-Boot for the WEXLER QC750 tablet
 
 ``DISCLAMER!`` Moving your WEXLER QC750 to use U-Boot assumes replacement
 of the vendor bootloader. Vendor Android firmwares will no longer be able
-to run on the device. This replacement IS reversible.
+to run on the device. This replacement IS reversible if you have backups.
 
 Quick Start
 -----------
@@ -38,26 +38,13 @@ re-crypt is a tool that processes the ``u-boot-dtb-tegra.bin`` binary into form
 usable by device. This process is required only on the first installation or
 to recover the device in case of a failed update.
 
-Permanent installation can be performed either by using the tegrarcm or by
-pre-loading just built U-Boot into RAM.
-
-Processing for the NV3P protocol
-********************************
-
 .. code-block:: bash
 
     $ git clone https://gitlab.com/grate-driver/re-crypt.git
     $ cd re-crypt # place your u-boot-dtb-tegra.bin here
-    $ ./re-crypt.py --dev qc750
-
-The script will produce a ``repart-block.bin`` ready to flash.
+    $ ./re-crypt.py --dev qc750 --split
 
-Processing for pre-loaded U-Boot
-********************************
-
-The procedure is the same, but the ``--split`` argument is used with the
-``re-crypt.py``. The script will produce ``bct.img`` and ``ebt.img`` ready
-to flash.
+The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
 Flashing U-Boot into the eMMC
 -----------------------------
@@ -65,31 +52,24 @@ Flashing U-Boot into the eMMC
 ``DISCLAMER!`` All questions related to tegrarcm should be asked in the proper
 place. NOT HERE! Flashing U-Boot will erase all eMMC, so make a backup before!
 
-Permanent installation can be performed either by using the nv3p protocol or by
-pre-loading just built U-Boot into RAM.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
-Flashing with the NV3P protocol
-*******************************
+You have to clone and prepare fusee-tools from here: https://gitlab.com/grate-driver/fusee-tools
+according to fusee-tools README to continue. Additionally you must install ``tegrarcm``.
 
-Nv3p is a custom Nvidia protocol used to recover bricked devices. Tegrarcm is
-used to handle such state.
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered via testpad on unpopulated RCM button on motherboard
+on device connected to the host PC. Host PC should detect APX USB device in ``lsusb``.
 
-With nv3p, ``repart-block.bin`` is used. It contains BCT and a bootloader in
-encrypted state in form, which can just be written RAW at the start of eMMC.
+U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
+U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
+of U-Boot permanently into eMMC. This is how U-Boot can be preloaded using
+tegrarcm:
 
 .. code-block:: bash
 
-    $ tegrarcm --bct qc750.bct --bootloader android_bootloader.bin --loadaddr 0x80108000
-    $ nvflash --resume --rawdevicewrite 0 1024 repart-block.bin
-
-When flashing is done, reboot the device.
-
-Flashing with a pre-loaded U-Boot
-*********************************
-
-U-Boot pre-loaded into RAM acts the same as when it was booted "cold". Currently
-U-Boot supports bootmenu entry fastboot, which allows to write a processed copy
-of U-Boot permanently into eMMC.
+    $ tegrarcm --bct ./bct/qc750.bct --bootloader u-boot-dtb-tegra.bin --loadaddr 0x80108000
 
 While pre-loading U-Boot, hold the ``volume down`` button which will trigger
 the bootmenu. There, select ``fastboot`` using the volume and power buttons.
@@ -112,8 +92,8 @@ device will enter bootmenu. Bootmenu contains entries to mount MicroSD and eMMC
 as mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot console
 and update bootloader (check the next chapter).
 
-Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
-the user to use/partition it in any way the user desires.
+Flashing ``bct.img`` and ``ebt.img`` eliminates vendor restrictions on eMMC and
+allows the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
diff --git a/doc/board/xiaomi/mocha.rst b/doc/board/xiaomi/mocha.rst
index 230081e3287..6339e4eb574 100644
--- a/doc/board/xiaomi/mocha.rst
+++ b/doc/board/xiaomi/mocha.rst
@@ -60,11 +60,15 @@ installation or to recover the device in case of a failed update.
 
 The script will produce ``bct.img`` and ``ebt.img`` ready to flash.
 
-Permanent installation can be performed by pre-loading just built U-Boot
-into RAM via tegrarcm. While pre-loading U-Boot, hold the ``volume down``
-button which will trigger the bootmenu. There, select ``fastboot`` using
-the volume and power buttons.
+Permanent installation can be performed by pre-loading just built U-Boot into RAM.
+Bct and bootloader will end up in boot0 and boot1 partitions of eMMC.
 
+Bootloader preloading is performed to device in APX/RCM mode connected to host
+PC. This mode can be entered via testad on motherboard on turned off device
+connected to the host PC. Host PC should detect APX USB device in ``lsusb``.
+
+While pre-loading U-Boot, hold the ``volume down`` button which will trigger
+the bootmenu. There, select ``fastboot`` using the volume and power buttons.
 After, on host PC, do:
 
 .. code-block:: bash
diff --git a/doc/develop/binman_tests.rst b/doc/develop/binman_tests.rst
index 5e44686b8ad..40865912911 100644
--- a/doc/develop/binman_tests.rst
+++ b/doc/develop/binman_tests.rst
@@ -331,7 +331,7 @@ Here is a simple test:
 
     def testSimple(self):
         """Test a simple binman with a single file"""
-        data = self._DoReadFile('005_simple.dts')
+        data = self._DoReadFile('pack/simple.dts')
         self.assertEqual(U_BOOT_DATA, data)
 
 This test tells Binman to build an image using the description. Then it checks
@@ -402,7 +402,7 @@ Another type of test is one which checks error-handling, for example:
     def testFillNoSize(self):
         """Test for an fill entry type with no size"""
         with self.assertRaises(ValueError) as e:
-            self._DoReadFile('070_fill_no_size.dts')
+            self._DoReadFile('entry/fill_no_size.dts')
         self.assertIn("'fill' entry is missing properties: size",
                       str(e.exception))
 
@@ -436,7 +436,7 @@ correct. You can to this with ``terminal.capture()``, for example:
 .. code-block:: python
 
     with terminal.capture() as (_, stderr):
-        self._DoTestFile('071_gbb.dts', force_missing_bintools='futility',
+        self._DoTestFile('cros/gbb.dts', force_missing_bintools='futility',
                          entry_args=entry_args)
     err = stderr.getvalue()
     self.assertRegex(err, "Image 'image'.*missing bintools.*: futility")
@@ -453,31 +453,15 @@ help with this, but your code will be different.
 
 Generally you are adding a test because you are adding a new entry type
 ('etype'). So start by creating the shortest and simplest image-description you
-can, which contains the new etype. Put it in a numbered file in
-``tool/binman/test`` so that it comes last. All the numbers are unique and there
-are no gaps.
+can, which contains the new etype. Put it under ``tools/binman/test`` in the
+appropriate subdirectory (e.g. ``fit/`` for FIT image tests, ``vendor/`` for
+vendor-specific tests, ``entry/`` for general entry types) with a descriptive
+filename.
 
-Example from ``tools/binman/test/339_nxp_imx8.dts``:
+Example from ``tools/binman/test/vendor/nxp_imx8.dts``:
 
-.. code-block:: devicetree
-
-    // SPDX-License-Identifier: GPL-2.0+
-
-    /dts-v1/;
-
-    / {
-        #address-cells = <1>;
-        #size-cells = <1>;
-
-        binman {
-            nxp-imx8mimage {
-                args;    /* TODO: Needed by mkimage etype superclass */
-                nxp,boot-from = "sd";
-                nxp,rom-version = <1>;
-                nxp,loader-address = <0x10>;
-            };
-        };
-    };
+.. literalinclude:: ../../tools/binman/test/vendor/nxp_imx8.dts
+   :language: devicetree
 
 Note that you should use tabs in the file, not spaces. You can see that this has
 been cut down to the bare minimum, just enough to include the etype and the
@@ -493,7 +477,7 @@ Then create your test by adding a new function at the end of ``ftest.py``:
 
     def testNxpImx8Image(self):
         """Test that binman can produce an iMX8 image"""
-        self._DoTestFile('339_nxp_imx8.dts')
+        self._DoTestFile('vendor/nxp_imx8.dts')
 
 This uses the test file that you created. It doesn't check anything, it just
 runs the image description through binman.
@@ -517,7 +501,7 @@ The next step is to update it to actually check the output:
 
     def testNxpImx8Image(self):
         """Test that binman can produce an iMX8 image"""
-        data = self._DoReadFile('339_nxp_imx8.dts')
+        data = self._DoReadFile('vendor/nxp_imx8.dts')
         print('data', len(data))
 
 The ``_DoReadFile()`` function is documented in the code. It returns the image
@@ -573,7 +557,7 @@ In the above example, here are some possible steps:
        def testNxpImx8ImageMkimageMissing(self):
            """Test that binman can produce an iMX8 image"""
            with terminal.capture() as (_, stderr):
-               self._DoTestFile('339_nxp_imx8.dts',
+               self._DoTestFile('vendor/nxp_imx8.dts',
                                 force_missing_bintools='mkimage')
            err = stderr.getvalue()
            self.assertRegex(err, "Image 'image'.*missing bintools.*: mkimage")
@@ -610,7 +594,7 @@ In the above example, here are some possible steps:
 
         Entry_section.SetImagePos(self, image_pos)
 
-   The solution is to add an entry, e.g. in ``340_nxp_imx8_non_empty.dts``:
+   The solution is to add an entry, e.g. in ``vendor/nxp_imx8_non_empty.dts``:
 
    .. code-block:: devicetree
 
@@ -641,7 +625,7 @@ In the above example, here are some possible steps:
 
        def testNxpImx8ImageNonEmpty(self):
            """Test that binman can produce an iMX8 image with something in it"""
-            data = self._DoReadFile('340_nxp_imx8_non_empty.dts')
+            data = self._DoReadFile('vendor/nxp_imx8_non_empty.dts')
             # check data here
 
    With that, the second red bit goes away, because the for() loop is now used.
diff --git a/doc/develop/uefi/fwu_updates.rst b/doc/develop/uefi/fwu_updates.rst
index 84713581459..c592106f8a8 100644
--- a/doc/develop/uefi/fwu_updates.rst
+++ b/doc/develop/uefi/fwu_updates.rst
@@ -66,7 +66,9 @@ FWU Metadata
 U-Boot supports both versions(1 and 2) of the FWU metadata defined in
 the two revisions of the specification. Support can be enabled for
 either of the two versions through a config flag. The mkfwumdata tool
-can generate metadata for both the supported versions.
+can generate metadata for both the supported versions. On the target side,
+the fwumdata tool can read and update FWU metadata located in memory,
+similarly to how fw_printenv/fw_setenv works.
 
 Setting up the device for GPT partitioned storage
 -------------------------------------------------
diff --git a/doc/fwumdata.1 b/doc/fwumdata.1
new file mode 100644
index 00000000000..66a53fc9403
--- /dev/null
+++ b/doc/fwumdata.1
@@ -0,0 +1,222 @@
+.\" SPDX-License-Identifier: GPL-2.0-or-later
+.\" Copyright (C) 2025 Kory Maincent <[email protected]>
+.TH FWUMDATA 1 2025 U-Boot
+.SH NAME
+fwumdata \- read, display, and modify FWU metadata
+.
+.SH SYNOPSIS
+.SY fwumdata
+.OP \-c config
+.OP \-l
+.OP \-u
+.OP \-a bankid
+.OP \-p bankid
+.RB [ \-s
+.IR bankid " " state ]
+.OP \-i imageid
+.OP \-b bankid
+.OP \-A
+.OP \-C
+.OP \-B num_banks
+.OP \-I num_images
+.YS
+.SY fwumdata
+.B \-h
+.YS
+.
+.SH DESCRIPTION
+.B fwumdata
+reads, displays, and modifies FWU (Firmware Update) metadata from Linux
+userspace.
+.PP
+The tool operates on FWU metadata stored on block or MTD devices, allowing
+userspace manipulation of firmware update state including active bank
+selection, image acceptance, and bank state management.
+.
+.SH OPTIONS
+.TP
+.BR \-c ", " \-\-config " \fIfile\fR"
+Use custom configuration file. By default, the tool searches for
+.I ./fwumdata.config
+then
+.IR /etc/fwumdata.config .
+.
+.TP
+.BR \-l ", " \-\-list
+Display detailed metadata information including all GUIDs, image entries,
+and bank information. Without this option, only a summary is shown.
+.
+.TP
+.BR \-u ", " \-\-update
+Update metadata if CRC validation fails. Useful for recovering from corrupted
+metadata.
+.
+.TP
+.BR \-a ", " \-\-active " \fIbankid\fR"
+Set the active bank index to
+.IR bank .
+.
+.TP
+.BR \-p ", " \-\-previous " \fIbankid\fR"
+Set the previous active bank index to
+.IR bank .
+.
+.TP
+.BR \-s ", " \-\-state " \fIbankid state\fR"
+Set bank index
+.I bankid
+to the specified
+.IR state .
+Valid states are:
+.BR accepted ,
+.BR valid ,
+or
+.BR invalid .
+Supported only with version 2 metadata. When setting a bank to accepted state,
+all firmware images in that bank are automatically marked as accepted.
+.
+.TP
+.BR \-i ", " \-\-image " \fIimageid\fR"
+Specify image number (used with
+.B \-A
+or
+.BR \-C ).
+.
+.TP
+.BR \-b ", " \-\-bank " \fIbankid\fR"
+Specify bank number (used with
+.B \-A
+or
+.BR \-C ).
+.
+.TP
+.BR \-A ", " \-\-accept
+Accept the image specified by
+.B \-i
+in the bank specified by
+.BR \-b .
+Sets the FWU_IMAGE_ACCEPTED flag for the image.
+.
+.TP
+.BR \-C ", " \-\-clear
+Clear the acceptance flag for the image specified by
+.B \-i
+in the bank specified by
+.BR \-b .
+According to the FWU specification, the bank state is automatically set to
+invalid before clearing the acceptance flag.
+.
+.TP
+.BR \-B ", " \-\-nbanks " \fInum_banks\fR"
+Specify total number of banks (required for V1 metadata).
+.
+.TP
+.BR \-I ", " \-\-nimages " \fInum_images\fR"
+Specify total number of images (required for V1 metadata).
+.
+.TP
+.BR \-h ", " \-\-help
+Print usage information and exit.
+.
+.SH CONFIGURATION FILE
+The configuration file specifies the location of FWU metadata on storage
+devices. The format is:
+.PP
+.EX
+.in +4
+# Device Name      Device Offset    Metadata Size    Erase Size
+/dev/mtd0          0x0              0x78             0x1000
+/dev/mtd1          0x0              0x78             0x1000
+.in
+.EE
+.PP
+Lines starting with
+.B #
+are comments.
+.I Erase Size
+is optional and only applies to MTD devices; if omitted, it defaults to the
+metadata size.
+.PP
+Specifying two devices enables redundant metadata support.
+.
+.SH BUGS
+Please report bugs to the
+.UR https://\:source\:.denx\:.de/\:u-boot/\:u-boot/\:issues
+U-Boot bug tracker
+.UE .
+.
+.SH EXAMPLES
+Display FWU metadata summary:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata
+.in
+.EE
+.PP
+Display detailed metadata with all GUIDs:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-l
+.in
+.EE
+.PP
+Set active bank to 1:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-a 1
+.in
+.EE
+.PP
+Set bank 1 to accepted state (automatically accepts all images in that bank):
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-s 1 accepted
+.in
+.EE
+.PP
+Accept image 0 in bank 0:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-i 0 \-b 0 \-A \-l
+.in
+.EE
+.PP
+Clear acceptance for image 0 in bank 1:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-i 0 \-b 1 \-C \-l
+.in
+.EE
+.PP
+Clear acceptance for image 1 in bank 1 with metadata V1:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-B 2 \-I 2 \-i 1 \-b 1 \-C \-l
+.in
+.EE
+.PP
+Use custom configuration file:
+.PP
+.EX
+.in +4
+$ \c
+.B fwumdata \-c /path/to/custom.config
+.in
+.EE
+.
+.SH SEE ALSO
+.BR mkfwumdata (1)
diff --git a/doc/mkeficapsule.1 b/doc/mkeficapsule.1
index a726149ba2c..d6653ec4247 100644
--- a/doc/mkeficapsule.1
+++ b/doc/mkeficapsule.1
@@ -121,8 +121,8 @@ Specify a monotonic count which is set to be monotonically incremented
 at every firmware update.
 
 .TP
-.B "-d\fR,\fB --dump_sig"
-Dump signature data into *.p7 file
+.B "-d\fR,\fB --dump-sig"
+Dump signature data into <capsule-file-name>.p7 file
 
 .SH "GUIDGEN OPTIONS"
 
diff --git a/doc/usage/cmd/test.rst b/doc/usage/cmd/test.rst
index d1379117fca..037a9ee1774 100644
--- a/doc/usage/cmd/test.rst
+++ b/doc/usage/cmd/test.rst
@@ -20,11 +20,14 @@ Synopsis
     test -e <interface> <dev[:part]> <path>
     test <s> =~ <re>
 
+    [ <test expression> ]
+
 Description
 -----------
 
 The ``test`` command is similar to the ordinary shell built-in by the
-same name. Unlike in ordinary shells, it cannot be spelled ``[``.
+same name. Like in ordinary shells, it can also be spelled ``[``,
+provided the test expression is followed by a separate ``]`` argument.
 
 Strings
 ~~~~~~~
author	Tom Rini <[email protected]>	2026-04-06 12:16:57 -0600
committer	Tom Rini <[email protected]>	2026-04-06 12:16:57 -0600
commit	93f84ee022a8401421cdaab84fe7d106d83fdb4a (patch)
tree	fb15a4af876e8faf9893fd86c1c0e127265dbe9a /doc
parent	88dc2788777babfd6322fa655df549a019aa1e69 (diff)
parent	e2138cf1e6088f12ffa874e87cc8f4b198378635 (diff)