Merge branch 'next'

45 files changed, 1720 insertions, 467 deletions

diff --git a/doc/android/bcb.rst b/doc/android/bcb.rst
index 88616083005..2226517d39f 100644
--- a/doc/android/bcb.rst
+++ b/doc/android/bcb.rst
@@ -41,23 +41,25 @@ requirements enumerated above. Below is the command's help message::
    bcb - Load/set/clear/test/dump/store Android BCB fields
 
    Usage:
-   bcb load  <dev> <part>       - load  BCB from mmc <dev>:<part>
-   bcb set   <field> <val>      - set   BCB <field> to <val>
-   bcb clear [<field>]          - clear BCB <field> or all fields
-   bcb test  <field> <op> <val> - test  BCB <field> against <val>
-   bcb dump  <field>            - dump  BCB <field>
-   bcb store                    - store BCB back to mmc
+   bcb load <interface> <dev> <part>  - load  BCB from <interface> <dev>:<part>
+   load <dev> <part>              - load  BCB from mmc <dev>:<part>
+   bcb set   <field> <val>        - set   BCB <field> to <val>
+   bcb clear [<field>]            - clear BCB <field> or all fields
+   bcb test  <field> <op> <val>   - test  BCB <field> against <val>
+   bcb dump  <field>              - dump  BCB <field>
+   bcb store                      - store BCB back to <interface>
 
    Legend:
-   <dev>   - MMC device index containing the BCB partition
-   <part>  - MMC partition index or name containing the BCB
-   <field> - one of {command,status,recovery,stage,reserved}
-   <op>    - the binary operator used in 'bcb test':
-             '=' returns true if <val> matches the string stored in <field>
-             '~' returns true if <val> matches a subset of <field>'s string
-   <val>   - string/text provided as input to bcb {set,test}
-             NOTE: any ':' character in <val> will be replaced by line feed
-             during 'bcb set' and used as separator by upper layers
+   <interface> - storage device interface (virtio, mmc, etc)
+   <dev>       - storage device index containing the BCB partition
+   <part>      - partition index or name containing the BCB
+   <field>     - one of {command,status,recovery,stage,reserved}
+   <op>        - the binary operator used in 'bcb test':
+                 '=' returns true if <val> matches the string stored in <field>
+                 '~' returns true if <val> matches a subset of <field>'s string
+   <val>       - string/text provided as input to bcb {set,test}
+                 NOTE: any ':' character in <val> will be replaced by line feed
+                 during 'bcb set' and used as separator by upper layers
 
 
 'bcb'. Example of getting reboot reason
@@ -91,7 +93,7 @@ The following Kconfig options must be enabled::
 
    CONFIG_PARTITIONS=y
    CONFIG_MMC=y
-   CONFIG_BCB=y
+   CONFIG_CMD_BCB=y
 
 .. [1] https://android.googlesource.com/platform/bootable/recovery
 .. [2] https://source.android.com/devices/bootloader
diff --git a/doc/board/asus/grouper_common.rst b/doc/board/asus/grouper_common.rst
index 2e4450b40e0..47a854e9163 100644
--- a/doc/board/asus/grouper_common.rst
+++ b/doc/board/asus/grouper_common.rst
@@ -3,26 +3,25 @@
 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.
+``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.
 
 Quick Start
 -----------
 
 - Build U-Boot
-- Pack U-Boot into repart-block
-- Flash repart-block into the eMMC
+- Process U-Boot
+- Flashing U-Boot into the eMMC
 - Boot
 - Self Upgrading
 
 Build U-Boot
 ------------
 
-Device support is implemented by applying config fragment to a generic
-board defconfig. Valid fragments are ``grouper_E1565.config``,
-``grouper_PM269.config`` and ``tilapia.config``.
+Device support is implemented by applying config fragment to a generic board
+defconfig. Valid fragments are ``tilapia.config``, ``grouper_E1565.config``
+and ``grouper_PM269.config``.
 
 .. code-block:: bash
 
@@ -31,64 +30,103 @@ board defconfig. Valid fragments are ``grouper_E1565.config``,
     $ make
 
 After the build succeeds, you will obtain the final ``u-boot-dtb-tegra.bin``
-image, ready for flashing (but check the next section for additional
-adjustments).
+image, ready for further processing.
 
-Pack U-Boot into repar-block
-----------------------------
+Process U-Boot
+--------------
 
-``DISCLAMER!`` All questions related to re-crypt work should be asked
+``DISCLAMER!`` All questions related to the re-crypt work should be asked
 in re-crypt repo issues. NOT HERE!
 
-re-crypt is a small script which packs ``u-boot-dtb-tegra.bin`` in
-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.
+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
+********************************
 
 .. code-block:: bash
 
-    $ git clone https://github.com/clamor-s/re-crypt.git
-    $ cd re-crypt # place your u-boot-dtb-regra.bin here
-    $ ./re-crypt.sh -d grouper -k deadbeefdeadc0dedeadd00dfee1dead
+    $ 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>
+
+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.
+
+Flashing U-Boot into the eMMC
+-----------------------------
+
+``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!
 
-Script will produce you a ``repart-block.bin`` ready to flash.
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
 
-Flash repart-block into the eMMC
---------------------------------
+Flashing with the NV3P protocol
+*******************************
 
-``DISCLAMER!`` All questions related to NvFlash should be asked
-in the proper place. NOT HERE! Flashing repart-block will erase
-all your eMMC, so make a backup before!
+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.
 
-``repart-block.bin`` contains BCT and bootloader in encrypted state
-in form which can just be written RAW at the start of eMMC.
+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.
 
 .. code-block:: bash
 
     $ wheelie --blob blob.bin
     $ 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.
+
+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
+
+    $ fastboot flash 0.1 bct.img
+    $ fastboot flash 0.2 ebt.img
+    $ fastboot reboot
+
+Device will reboot.
+
 Boot
 ----
 
-After flashing ``repart-block.bin`` the device should reboot and turn
-itself off. This is normal behavior if no boot configuration is
-found.
-
-To boot Linux, U-Boot will look for an ``extlinux.conf`` configuration
-on eMMC. Additionally if Volume Down button is pressed while booting
-device will enter bootmenu. Bootmenu contains entries to mount eMMC as
-mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot
-console and update bootloader (check next chapter).
+To boot Linux, U-Boot will look for an ``extlinux.conf`` on eMMC. Additionally,
+if the Volume Down button is pressed while booting, the device will enter
+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 restriction on eMMC
-and allows the user to use/partition it in any way the user desires.
+Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
+the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
 
-Place your ``u-boot-dtb-tegra.bin`` on the first partition of the
-eMMC (using ability of u-boot to mount it). Enter bootmenu, choose
-update bootloader option with Power button and U-Boot should update
-itself. Once the process is completed, U-Boot will ask to press any
-button to reboot.
+Place your ``u-boot-dtb-tegra.bin`` on the first partition of the eMMC (using
+ability of u-boot to mount it). Enter bootmenu, choose update bootloader option
+with Power button and U-Boot should update itself. Once the process is
+completed, U-Boot will ask to press any button to reboot.
diff --git a/doc/board/asus/transformer_t30.rst b/doc/board/asus/transformer_t30.rst
index b6b61015409..ff9792dc0fc 100644
--- a/doc/board/asus/transformer_t30.rst
+++ b/doc/board/asus/transformer_t30.rst
@@ -3,28 +3,27 @@
 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.
+``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.
 
 Quick Start
 -----------
 
 - Build U-Boot
-- Pack U-Boot into repart-block
-- Flash repart-block into the eMMC
-- Flash repart-block into TF600T SPI flash
+- Process U-Boot
+- Flashing U-Boot into the eMMC
+- Flashing U-Boot into the SPI flash
 - Boot
 - Self Upgrading
 
 Build U-Boot
 ------------
 
-Device support is implemented by applying config fragment
-to a generic board defconfig. Valid fragments are ``tf201.config``,
-``tf300t.config``, ``tf300tg.config``, ``tf300tl.config``,
-``tf700t.config``, ``tf600t.config`` and ``p1801-t.config``.
+Device support is implemented by applying a config fragment to a generic board
+defconfig. Valid fragments are ``tf201.config``, ``tf300t.config``,
+``tf300tg.config``, ``tf300tl.config``, ``tf700t.config``, ``tf600t.config`` and
+``p1801-t.config``.
 
 .. code-block:: bash
 
@@ -33,84 +32,124 @@ to a generic board defconfig. Valid fragments are ``tf201.config``,
     $ make
 
 After the build succeeds, you will obtain the final ``u-boot-dtb-tegra.bin``
-image, ready for flashing (but check the next section for additional
-adjustments).
+image, ready for further processing.
 
-Pack U-Boot into repar-block
-----------------------------
+Process U-Boot
+--------------
 
-``DISCLAMER!`` All questions related to re-crypt work should be asked
+``DISCLAMER!`` All questions related to the re-crypt work should be asked
 in re-crypt repo issues. NOT HERE!
 
-re-crypt is a small script which packs ``u-boot-dtb-tegra.bin`` in
-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.
+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
+********************************
 
 .. code-block:: bash
 
-    $ git clone https://github.com/clamor-s/re-crypt.git
-    $ cd re-crypt # place your u-boot-dtb-regra.bin here
-    $ ./re-crypt.sh -d tf201 -k deadbeefdeadc0dedeadd00dfee1dead
+    $ 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>
+
+where SBK has next form ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX`` ``0xXXXXXXXX``
+
+The script will produce a ``repart-block.bin`` ready to flash.
 
-Script will produce you a `repart-block.bin` ready to flash.
+Processing for pre-loaded U-Boot
+********************************
 
-Flash repart-block into the eMMC
---------------------------------
+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.
 
-``DISCLAMER!`` All questions related to NvFlash should be asked
-in the proper place. NOT HERE! Flashing repart-block will erase
-all your eMMC, so make a backup before!
+Flashing U-Boot into the eMMC
+-----------------------------
 
-``repart-block.bin`` contains BCT and bootloader in encrypted state
-in form which can just be written RAW at the start of eMMC.
+``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!
+
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
+
+Flashing with the NV3P protocol
+*******************************
+
+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.
+
+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.
 
 .. code-block:: bash
 
     $ wheelie --blob blob.bin
     $ nvflash --resume --rawdevicewrite 0 1024 repart-block.bin
 
-Flash repart-block into TF600T SPI flash
-----------------------------------------
+When flashing is done, reboot the device.
+
+Flashing with a pre-loaded U-Boot
+*********************************
 
-Unlike other transformers TF600T uses separate 4 MB SPI flash which
-contains all data required for boot. It is flashed from within u-boot
-itself preloaded into RAM using fusee gelee. 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 fusee gelee and u-boot which was included into
-repart-block.bin, while booting you must hold volume down button.
-Process should take less then a minute, if everything goes correct,
-on microSD will appear ``spi-flash-backup.bin`` file, which is dump of
-your spi flash content and can be used to restore UEFI, do not loose it,
-tablet will power itself off.
+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.
 
-Self-updating of u-boot is performed by placing ``u-boot-dtb-tegra.bin``
-on 1st partition of microSD, inserting it into tablet and booting with
-pressed volume down button.
+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
+
+    $ fastboot flash 0.1 bct.img
+    $ fastboot flash 0.2 ebt.img
+    $ fastboot reboot
+
+Device will reboot.
+
+Flashing U-Boot into the SPI Flash
+----------------------------------
+
+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.
+
+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
+``repart-block.bin``, while booting you must hold the ``volume down`` button.
+
+The process should take less than a minute, if everything goes correctly,
+on microSD will appear ``spi-flash-backup.bin`` file, which is the dump of your
+SPI Flash content and can be used to restore UEFI, do not lose it, tablet will
+power itself off.
+
+Self-updating of U-Boot is performed by placing ``u-boot-dtb-tegra.bin`` on 1st
+partition of microSD, inserting it into the tablet and booting with a pressed
+``volume down`` button.
 
 Boot
 ----
 
-After flashing ``repart-block.bin`` the device should reboot and turn
-itself off. This is normal behavior if no boot configuration is
-found.
-
-To boot Linux, U-Boot will look for an ``extlinux.conf`` on MicroSD
-and then on eMMC. Additionally if Volume Down button is pressed
-while booting 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 next
-chapter).
+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 booting, the
+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 restriction on eMMC
-and allows the user to use/partition it in any way the user desires.
+Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
+the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
 
-Place your ``u-boot-dtb-tegra.bin`` on the first partition of the
-MicroSD card and insert it into the tablet. Enter bootmenu, choose
-update bootloader option with Power button and U-Boot should update
-itself. Once the process is completed, U-Boot will ask to press any
-button to reboot.
+Place your ``u-boot-dtb-tegra.bin`` on the first partition of the MicroSD card
+and insert it into the tablet. Enter bootmenu, choose update the bootloader
+option with the Power button and U-Boot should update itself. Once the process
+is completed, U-Boot will ask to press any button to reboot.
diff --git a/doc/board/ti/am62x_beagleplay.rst b/doc/board/beagle/am62x_beagleplay.rst
index 44e728de210..7784e62b0b7 100644
--- a/doc/board/ti/am62x_beagleplay.rst
+++ b/doc/board/beagle/am62x_beagleplay.rst
@@ -23,7 +23,7 @@ Boot Flow:
 ----------
 Below is the pictorial representation of boot flow:
 
-.. image:: img/boot_diagram_k3_current.svg
+.. image:: ../ti/img/boot_diagram_k3_current.svg
   :alt: Boot flow diagram
 
 - On this platform, 'TI Foundational Security' (TIFS) functions as the
@@ -34,7 +34,7 @@ Below is the pictorial representation of boot flow:
 
 Sources:
 --------
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_boot_sources
     :end-before: .. k3_rst_include_end_boot_sources
 
@@ -42,30 +42,30 @@ Build procedure:
 ----------------
 0. Setup the environment variables:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_common_env_vars_desc
     :end-before: .. k3_rst_include_end_common_env_vars_desc
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_board_env_vars_desc
     :end-before: .. k3_rst_include_end_board_env_vars_desc
 
 Set the variables corresponding to this platform:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_common_env_vars_defn
     :end-before: .. k3_rst_include_end_common_env_vars_defn
 .. prompt:: bash $
 
-  export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config"
-  export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config"
+  export UBOOT_CFG_CORTEXR=am62x_beagleplay_r5_defconfig
+  export UBOOT_CFG_CORTEXA=am62x_beagleplay_a53_defconfig
   export TFA_BOARD=lite
   # we dont use any extra TFA parameters
   unset TFA_EXTRA_ARGS
   export OPTEE_PLATFORM=k3-am62x
   export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
 
-.. include::  am62x_sk.rst
+.. include::  ../ti/am62x_sk.rst
     :start-after: .. am62x_evm_rst_include_start_build_steps
     :end-before: .. am62x_evm_rst_include_end_build_steps
 
@@ -82,12 +82,12 @@ Image formats
 
 - tiboot3.bin
 
-.. image:: img/multi_cert_tiboot3.bin.svg
+.. image:: ../ti/img/multi_cert_tiboot3.bin.svg
   :alt: tiboot3.bin image format
 
 - tispl.bin
 
-.. image:: img/dm_tispl.bin.svg
+.. image:: ../ti/img/dm_tispl.bin.svg
   :alt: tispl.bin image format
 
 Additional hardware for U-Boot development
@@ -240,7 +240,7 @@ LED patterns during boot
 A53 SPL DDR Memory Layout
 -------------------------
 
-.. include::  am62x_sk.rst
+.. include::  ../ti/am62x_sk.rst
     :start-after: .. am62x_evm_rst_include_start_ddr_mem_layout
     :end-before: .. am62x_evm_rst_include_end_ddr_mem_layout
 
@@ -284,11 +284,11 @@ detailed setup and debugging information.
   environment's distribution needs to be updated, it might be necessary to
   build OpenOCD from the source.
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_openocd_connect_tag_connect
     :end-before: .. k3_rst_include_end_openocd_connect_tag_connect
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_openocd_cfg_external_intro
     :end-before: .. k3_rst_include_end_openocd_cfg_external_intro
 
diff --git a/doc/board/ti/img/beagleplay_emmc.svg b/doc/board/beagle/img/beagleplay_emmc.svg
index c6ff19b7738..c6ff19b7738 100644
--- a/doc/board/ti/img/beagleplay_emmc.svg
+++ b/doc/board/beagle/img/beagleplay_emmc.svg
diff --git a/doc/board/beagle/index.rst b/doc/board/beagle/index.rst
new file mode 100644
index 00000000000..9124546ebc7
--- /dev/null
+++ b/doc/board/beagle/index.rst
@@ -0,0 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+BeagleBoard.org
+###############
+
+
+ARM based boards
+----------------
+
+.. toctree::
+   :maxdepth: 2
+
+   am62x_beagleplay
+   j721e_beagleboneai64
diff --git a/doc/board/beagle/j721e_beagleboneai64.rst b/doc/board/beagle/j721e_beagleboneai64.rst
new file mode 100644
index 00000000000..d6b9c8ca606
--- /dev/null
+++ b/doc/board/beagle/j721e_beagleboneai64.rst
@@ -0,0 +1,327 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Nishanth Menon <[email protected]>
+
+J721E/TDA4VM Beagleboard.org BeagleBone AI-64
+=============================================
+
+Introduction:
+-------------
+
+BeagleBoard.org BeagleBone AI-64 is an open source hardware single
+board computer based on the Texas Instruments TDA4VM SoC featuring
+dual-core 2.0GHz Arm Cortex-A72 processor, C7x+MMA and 2 C66x
+floating-point VLIW DSPs, 3x dual ARM Cortex-R5 co-processors,
+2x 6-core Programmable Real-Time Unit and Industrial Communication
+SubSystem, PowerVR Rogue 8XE GE8430 3D GPU. The board features 4GB
+DDR4, USB3.0 Type-C, 2x USB SS Type-A, miniDisplayPort, 2x 4-lane
+CSI, DSI, 16GB eMMC flash, 1G Ethernet, M.2 E-key for WiFi/BT, and
+BeagleBone expansion headers.
+
+Further information can be found at:
+
+* Product Page: https://beagleboard.org/ai-64
+* Hardware documentation: https://git.beagleboard.org/beagleboard/beaglebone-ai-64
+
+Boot Flow:
+----------
+Below is the pictorial representation of boot flow:
+
+.. image:: ../ti/img/boot_diagram_j721e.svg
+  :alt: Boot flow diagram
+
+- On this platform, DMSC runs 'TI Foundational Security' (TIFS) which
+  functions as the security enclave master. The 'Device Manager' (DM),
+  also known as the 'TISCI server' in "TI terminology", running on boot
+  R5F, offers all the essential services required for device management.
+  The A72, C7x, C6x or R5F (Aux cores) sends requests to TIFS/DM to
+  accomplish the needed services, as illustrated in the diagram above.
+
+Sources:
+--------
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_boot_sources
+    :end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+----------------
+0. Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_common_env_vars_desc
+    :end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_board_env_vars_desc
+    :end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_common_env_vars_defn
+    :end-before: .. k3_rst_include_end_common_env_vars_defn
+.. prompt:: bash $
+
+  export UBOOT_CFG_CORTEXR=j721e_beagleboneai64_r5_defconfig
+  export UBOOT_CFG_CORTEXA=j721e_beagleboneai64_a72_defconfig
+  export TFA_BOARD=generic
+  # we dont use any extra TFA parameters
+  unset TFA_EXTRA_ARGS
+  export OPTEE_PLATFORM=k3-j721e
+  # we dont use any extra OP-TEE parameters
+  unset OPTEE_EXTRA_ARGS
+
+.. include::  ../ti/j721e_evm.rst
+    :start-after: .. j721e_evm_rst_include_start_build_steps
+    :end-before: .. j721e_evm_rst_include_end_build_steps
+
+Target Images
+--------------
+Copy the below images to an SD card and boot:
+
+* tiboot3-j721e-gp-evm.bin from R5 build as tiboot3.bin
+* tispl.bin_unsigned from Cortex-A build as tispl.bin
+* u-boot.img_unsigned from Cortex-A build as u-boot.img
+
+Image formats
+-------------
+
+- tiboot3.bin
+
+.. image:: ../ti/img/no_multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
+
+- tispl.bin
+
+.. image:: ../ti/img/dm_tispl.bin.svg
+  :alt: tispl.bin image format
+
+- sysfw.itb
+
+.. image:: ../ti/img/sysfw.itb.svg
+  :alt: sysfw.itb image format
+
+Additional hardware for U-Boot development
+------------------------------------------
+
+* Serial Console is critical for U-Boot development on BeagleBone AI-64. See
+  `BeagleBone AI-64 connector documentation
+  <https://docs.beagleboard.org/latest/boards/beaglebone/ai-64/ch07.html>`_.
+* uSD is preferred option over eMMC, and a SD/MMC reader will be needed.
+* (optionally) JTAG is useful when working with very early stages of boot.
+
+Default storage options
+-----------------------
+
+There are multiple storage media options on BeagleBone AI-64, but primarily:
+
+* Onboard eMMC (default) - reliable, fast and meant for deployment use.
+* SD/MMC card interface (hold 'BOOT' switch and power on) - Entirely
+  depends on the SD card quality.
+
+Flash to uSD card or how to deal with "bricked" Board
+--------------------------------------------------------
+
+When deploying or working on Linux, it's common to use the onboard
+eMMC. However, avoiding the eMMC and using the uSD card is safer when
+working with U-Boot.
+
+If you choose to  hand format your own bootable uSD card, be
+aware that it can be difficult. The following information
+may be helpful, but remember that it is only sometimes
+reliable, and partition options can cause issues. These
+can potentially help:
+
+* https://git.ti.com/cgit/arago-project/tisdk-setup-scripts/tree/create-sdcard.sh
+* https://elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD
+
+The simplest option is to start with a standard distribution
+image like those in `BeagleBoard.org Distros Page
+<https://www.beagleboard.org/distros>`_ and download a disk image for
+BeagleBone AI-64. Pick a 16GB+ uSD card to be on the safer side.
+
+With an SD/MMC Card reader and `Balena Etcher
+<https://etcher.balena.io/>`_, having a functional setup in minutes is
+a trivial matter, and it works on almost all Host Operating Systems.
+Yes Windows users, Windows Subsystem for Linux(WSL) based development
+with U-Boot and update uSD card is practical.
+
+Updating U-Boot is a matter of copying the tiboot3.bin, tispl.bin and
+u-boot.img to the "BOOT" partition of the uSD card. Remember to sync
+and unmount (or Eject - depending on the Operating System) the uSD
+card prior to physically removing from SD card reader.
+
+Also see following section on switch setting used for booting using
+uSD card.
+
+.. note::
+  Great news! If the board has not been damaged physically, there's no
+  need to worry about it being "bricked" on this platform. You only have
+  to flash an uSD card, plug it in, and reinstall the image on eMMC. This
+  means that even if you make a mistake, you can quickly fix it and rest
+  easy.
+
+  If you are frequently working with uSD cards, you might find the
+  following useful:
+
+  * `USB-SD-Mux <https://www.linux-automation.com/en/products/usb-sd-mux.html>`_
+  * `SD-Wire <https://wiki.tizen.org/SDWire>`_
+
+Flash to eMMC
+-------------
+
+The eMMC layout selected is user-friendly for developers. The
+boot hardware partition of the eMMC only contains the fixed-size
+tiboot3.bin image. This is because the contents of the boot partitions
+need to run from the SoC's internal SRAM, which remains a fixed size
+constant. The other components of the boot sequence, such as tispl.bin
+and u-boot.img, are located in the /BOOT partition in the User Defined
+Area (UDA) hardware partition of the eMMC. These components can vary
+significantly in size. The choice of keeping tiboot3.bin in boot0 or
+boot1 partition depends on A/B update requirements.
+
+.. image:: img/beagleplay_emmc.svg
+  :alt: eMMC partitions and boot file organization for BeagleBone AI-64
+
+The following are the steps from Linux shell to program eMMC:
+
+.. prompt:: bash #
+
+  # Enable Boot0 boot
+  mmc bootpart enable 1 2 /dev/mmcblk0
+  mmc bootbus set single_backward x1 x8 /dev/mmcblk0
+  mmc hwreset enable /dev/mmcblk0
+
+  # Clear eMMC boot0
+  echo '0' >> /sys/class/block/mmcblk0boot0/force_ro
+  dd if=/dev/zero of=/dev/mmcblk0boot0 count=32 bs=128k
+  # Write tiboot3.bin
+  dd if=tiboot3.bin of=/dev/mmcblk0boot0 bs=128k
+
+  # Copy the rest of the boot binaries
+  mount /dev/mmcblk0p1 /boot/firmware
+  cp tispl.bin /boot/firmware
+  cp u-boot.img /boot/firmware
+  sync
+
+.. warning ::
+
+  U-Boot is configured to prioritize booting from an SD card if it
+  detects a valid boot partition and boot files on it, even if the
+  system initially booted from eMMC. The boot order is set as follows:
+
+  * SD/MMC
+  * eMMC
+  * USB
+  * PXE
+
+LED patterns during boot
+------------------------
+
+.. list-table:: USR LED status indication
+   :widths: 16 16
+   :header-rows: 1
+
+   * - USR LEDs (012345)
+     - Indicates
+
+   * - 00000
+     - Boot failure or R5 image not started up
+
+   * - 11111
+     - A53 SPL/U-boot has started up
+
+   * - 10101
+     - OS boot process has been initiated
+
+   * - 01010
+     - OS boot process failed and drops to U-Boot shell
+
+.. note ::
+
+  In the table above, 0 indicates LED switched off and 1 indicates LED
+  switched ON.
+
+.. warning ::
+
+  The green LED very next to the serial connector labelled "WKUP UART0"
+  is the power LED (LED6). This is the same color as the rest of the USR
+  LEDs. If the "green" LED6 power LED is not glowing, the system power
+  supply is not functional. Please refer to `BeagleBone AI-64 documentation
+  <https://beagleboard.org/ai-64/>`_ for further information.
+
+Switch Setting for Boot Mode
+----------------------------
+
+The boot time option is configured via "BOOT" button on the board.
+See `BeagleBone AI-64 Schematics <https://git.beagleboard.org/beagleboard/beaglebone-ai-64/-/blob/main/BeagleBone_AI-64_SCH.pdf>`_
+for details.
+
+.. list-table:: Boot Modes
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - BOOT Switch Position
+     - Primary Boot
+     - Secondary Boot
+
+   * - Not Pressed
+     - eMMC
+     - SD Card
+
+   * - Pressed
+     - SD Card
+     - SD Card
+
+To switch to SD card boot mode, hold the BOOT button while powering on
+with Type-C power supply, then release when power LED lights up.
+
+Debugging U-Boot
+----------------
+
+See :ref:`Common Debugging environment - OpenOCD<k3_rst_refer_openocd>`: for
+detailed setup and debugging information.
+
+.. warning::
+
+  **OpenOCD support since**: v0.12.0
+
+  If the default package version of OpenOCD in your development
+  environment's distribution needs to be updated, it might be necessary to
+  build OpenOCD from the source.
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_openocd_connect_tag_connect
+    :end-before: .. k3_rst_include_end_openocd_connect_tag_connect
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_openocd_cfg_external_intro
+    :end-before: .. k3_rst_include_end_openocd_cfg_external_intro
+
+For example, with BeagleBone AI-64 (J721e platform), the openocd_connect.cfg:
+
+.. code-block:: tcl
+
+  # TUMPA example:
+  # http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User's_Manual
+  source [find interface/ftdi/tumpa.cfg]
+
+  transport select jtag
+
+  # default JTAG configuration has only SRST and no TRST
+  reset_config srst_only srst_push_pull
+
+  # delay after SRST goes inactive
+  adapter srst delay 20
+
+  if { ![info exists SOC] } {
+    # Set the SoC of interest
+    set SOC j721e
+  }
+
+  source [find target/ti_k3.cfg]
+
+  ftdi tdo_sample_edge falling
+
+  # Speeds for FT2232H are in multiples of 2, and 32MHz is tops
+  # max speed we seem to achieve is ~20MHz.. so we pick 16MHz
+  adapter speed 16000
diff --git a/doc/board/emulation/acpi.rst b/doc/board/emulation/acpi.rst
new file mode 100644
index 00000000000..17b68e1b780
--- /dev/null
+++ b/doc/board/emulation/acpi.rst
@@ -0,0 +1,23 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+ACPI on QEMU
+============
+
+QEMU can provide ACPI tables on ARM, RISC-V (since QEMU v8.0.0), and x86.
+
+The following U-Boot settings are needed for ACPI support::
+
+    CONFIG_CMD_QFW=y
+    CONFIG_ACPI=y
+    CONFIG_GENERATE_ACPI_TABLE=y
+
+On x86 these settings are already included in the defconfig files. ARM and
+RISC-V default to use device-trees.
+
+Instead of updating the configuration manually you can add the configuration
+fragment `acpi.config` to the make command for initializing the configuration.
+E.g.
+
+.. code-block:: bash
+
+    make qemu-riscv64_smode_defconfig acpi.config
diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst
index 932c65adebb..d3d6b8f3d86 100644
--- a/doc/board/emulation/index.rst
+++ b/doc/board/emulation/index.rst
@@ -6,6 +6,7 @@ Emulation
 .. toctree::
    :maxdepth: 1
 
+   acpi
    blkdev
    ../../usage/semihosting
    qemu-arm
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 61137bcbf1c..8a5eb1eda56 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -131,7 +131,13 @@ An attached disk can be emulated in RISC-V virt machine by adding::
     -drive if=none,file=riscv64.img,format=raw,id=mydisk \
     -device ide-hd,drive=mydisk,bus=ahci.0
 
-You will have to run 'scsi scan' to use it.
+or alternatively attach an emulated UFS::
+
+    -device ufs,id=ufs0 \
+    -drive if=none,file=test.img,format=raw,id=lun0 \
+    -device ufs-lu,drive=lun0,bus=ufs0
+
+You will have to run 'scsi scan' to use them.
 
 A video console can be emulated in RISC-V virt machine by removing "-nographic"
 and adding::
diff --git a/doc/board/htc/endeavoru.rst b/doc/board/htc/endeavoru.rst
index 950c713f2fa..e0edefe28ae 100644
--- a/doc/board/htc/endeavoru.rst
+++ b/doc/board/htc/endeavoru.rst
@@ -3,17 +3,16 @@
 U-Boot for the HTC One X (endeavoru)
 ====================================
 
-``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.
+``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.
 
 Quick Start
 -----------
 
 - Build U-Boot
-- Pack U-Boot into repart-block
-- Flash repart-block into the eMMC
+- Process U-Boot
+- Flashing U-Boot into the eMMC
 - Boot
 - Self Upgrading
 
@@ -27,63 +26,100 @@ Build U-Boot
     $ make
 
 After the build succeeds, you will obtain the final ``u-boot-dtb-tegra.bin``
-image, ready for flashing (but check the next section for additional
-adjustments).
+image, ready for further processing.
 
-Pack U-Boot into repar-block
-----------------------------
+Process U-Boot
+--------------
+
+``DISCLAMER!`` All questions related to the re-crypt work should be asked
+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.
 
-``DISCLAMER!`` All questions related to re-crypt work should be
-asked in re-crypt repo issues. NOT HERE!
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
 
-re-crypt is a small script which packs ``u-boot-dtb-tegra.bin`` in
-form usable by device. This process is required only on the first
-installation or to recover the device in case of a failed update.
+Processing for the NV3P protocol
+********************************
 
 .. code-block:: bash
 
-    $ git clone https://github.com/clamor-s/re-crypt.git
-    $ cd re-crypt # place your u-boot-dtb-regra.bin here
-    $ ./re-crypt.sh -d endeavoru
+    $ 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.
+
+Processing for pre-loaded U-Boot
+********************************
 
-Script will produce you a ``repart-block.bin`` ready to flash.
+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.
 
-Flash repart-block into the eMMC
---------------------------------
+Flashing U-Boot into the eMMC
+-----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked
-in the proper place. NOT HERE! Flashing repart-block will erase
-all your eMMC, so make a backup before!
+``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!
 
-``repart-block.bin`` contains BCT and bootloader in encrypted state
-in form which can just be written RAW at the start of eMMC.
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
+
+Flashing with the NV3P protocol
+*******************************
+
+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.
+
+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.
 
 .. code-block:: bash
 
     $ wheelie --blob blob.bin
     $ 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.
+
+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
+
+    $ fastboot flash 0.1 bct.img
+    $ fastboot flash 0.2 ebt.img
+    $ fastboot reboot
+
+Device will reboot.
+
 Boot
 ----
 
-After flashing ``repart-block.bin`` the device should reboot and turn
-itself off. This is normal behavior if no boot configuration is
-found.
-
-To boot Linux, U-Boot will look for an ``extlinux.conf`` configuration
-on eMMC. Additionally if Volume Down button is pressed while booting
-device will enter bootmenu. Bootmenu contains entries to mount eMMC as
-mass storage, fastboot, reboot, reboot RCM, poweroff, enter U-Boot
-console and update bootloader (check next chapter).
+To boot Linux, U-Boot will look for an ``extlinux.conf`` on eMMC. Additionally,
+if the Volume Down button is pressed while booting, the device will enter
+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 restriction on eMMC
-and allows the user to use/partition it in any way the user desires.
+Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
+the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
 
-Place your ``u-boot-dtb-tegra.bin`` on the first partition of the
-eMMC (using ability of u-boot to mount it). Enter bootmenu, choose
-update bootloader option with Power button and U-Boot should update
-itself. Once the process is completed, U-Boot will ask to press any
-button to reboot.
+Place your ``u-boot-dtb-tegra.bin`` on the first partition of the eMMC (using
+ability of u-boot to mount it). Enter bootmenu, choose update bootloader option
+with Power button and U-Boot should update itself. Once the process is
+completed, U-Boot will ask to press any button to reboot.
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 531e547e7e3..c96e5fda281 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -17,6 +17,7 @@ Board-specific doc
    asus/index
    atmel/index
    beacon/index
+   beagle/index
    broadcom/index
    bsh/index
    cloos/index
diff --git a/doc/board/lg/x3_t30.rst b/doc/board/lg/x3_t30.rst
index 5c564aabc6a..618b00d34e3 100644
--- a/doc/board/lg/x3_t30.rst
+++ b/doc/board/lg/x3_t30.rst
@@ -3,17 +3,16 @@
 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.
+``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.
 
 Quick Start
 -----------
 
 - Build U-Boot
-- Pack U-Boot into repart-block
-- Flash repart-block into the eMMC
+- Process U-Boot
+- Flashing U-Boot into the eMMC
 - Boot
 - Self Upgrading
 
@@ -30,64 +29,100 @@ board defconfig. Valid fragments are ``p880.config`` and ``p895.config``.
     $ make
 
 After the build succeeds, you will obtain the final ``u-boot-dtb-tegra.bin``
-image, ready for flashing (but check the next section for additional
-adjustments).
+image, ready for further processing.
 
-Pack U-Boot into repar-block
-----------------------------
+Process U-Boot
+--------------
+
+``DISCLAMER!`` All questions related to the re-crypt work should be asked
+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.
 
-``DISCLAMER!`` All questions related to re-crypt work should be
-asked in re-crypt repo issues. NOT HERE!
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
 
-re-crypt is a small script which packs ``u-boot-dtb-tegra.bin`` in
-form usable by device. This process is required only on the first
-installation or to recover the device in case of a failed update.
+Processing for the NV3P protocol
+********************************
 
 .. code-block:: bash
 
-    $ git clone https://github.com/clamor-s/re-crypt.git
-    $ cd re-crypt # place your u-boot-dtb-regra.bin here
-    $ ./re-crypt.sh -d p895
+    $ 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.
+
+Processing for pre-loaded U-Boot
+********************************
 
-Script will produce you a ``repart-block.bin`` ready to flash.
+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.
 
-Flash repart-block into the eMMC
---------------------------------
+Flashing U-Boot into the eMMC
+-----------------------------
 
-``DISCLAMER!`` All questions related to NvFlash should be asked
-in the proper place. NOT HERE! Flashing repart-block will erase
-all your eMMC, so make a backup before!
+``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!
 
-``repart-block.bin`` contains BCT and bootloader in encrypted state
-in form which can just be written RAW at the start of eMMC.
+Permanent installation can be performed either by using the nv3p protocol or by
+pre-loading just built U-Boot into RAM.
+
+Flashing with the NV3P protocol
+*******************************
+
+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.
+
+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.
 
 .. code-block:: bash
 
     $ wheelie --blob blob.bin
     $ 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.
+
+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
+
+    $ fastboot flash 0.1 bct.img
+    $ fastboot flash 0.2 ebt.img
+    $ fastboot reboot
+
+Device will reboot.
+
 Boot
 ----
 
-After flashing ``repart-block.bin`` the device should reboot and turn
-itself off. This is normal behavior if no boot configuration is
-found.
-
-To boot Linux, U-Boot will look for an ``extlinux.conf`` on MicroSD
-and then on eMMC. Additionally if Volume Down button is pressed
-while booting 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 next
-chapter).
+To boot Linux, U-Boot will look for an ``extlinux.conf`` on eMMC. Additionally,
+if the Volume Down button is pressed while booting, the device will enter
+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 restriction on eMMC
-and allows the user to use/partition it in any way the user desires.
+Flashing ``repart-block.bin`` eliminates vendor restrictions on eMMC and allows
+the user to use/partition it in any way the user desires.
 
 Self Upgrading
 --------------
 
-Place your ``u-boot-dtb-tegra.bin`` on the first partition of the
-eMMC (using ability of u-boot to mount it). Enter bootmenu, choose
-update bootloader option with Power button and U-Boot should update
-itself. Once the process is completed, U-Boot will ask to press any
-button to reboot.
+Place your ``u-boot-dtb-tegra.bin`` on the first partition of the eMMC (using
+ability of u-boot to mount it). Enter bootmenu, choose update bootloader option
+with Power button and U-Boot should update itself. Once the process is
+completed, U-Boot will ask to press any button to reboot.
diff --git a/doc/board/ti/am62ax_sk.rst b/doc/board/ti/am62ax_sk.rst
new file mode 100644
index 00000000000..60726b6652c
--- /dev/null
+++ b/doc/board/ti/am62ax_sk.rst
@@ -0,0 +1,213 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Jai Luthra <[email protected]>
+
+AM62A Platforms
+===============
+
+Introduction:
+-------------
+The AM62A SoC family is built on the K3 Multicore SoC architecture platform,
+providing a deep learning accelerator, multi-camera support with ISP, video
+transcoder and other BOM-saving integrations.
+The AM62A SoC enables cost-sensitive automotive applications including driver
+and in-cabin monitoring systems, next generation of eMirror system, as well as
+a broad set of industrial applications in Factory Automation, Building
+Automation, Robotics and more.
+
+Some highlights of this SoC are:
+
+* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster.
+* Cortex-R5F for general-purpose or safety usage.
+* Deep Learning Accelerator with Single-core C7x Vector DSP with MMA (up to
+  1.0GHz).
+* Vision Processing Accelerator (VPAC) with a 315MPixel/s ISP (up to 5MP @
+  60fps) supporting 16-bit RAW input with RGB-IR separation.
+* 4K Video encoder and decoder for HEVC (Level 5.1 High-tier) and H.264 (Level
+  5.2) supporting upto 240MPixels/s and MJPEG encoder at 416MPixels/s
+* Single display with 24-bit RGB parallel (DPI) interface supporting upto
+  165Mhz pixel clock for 2K resolution.
+* Integrated Giga-bit Ethernet switch supporting up to a total of two
+  external ports (TSN capable).
+* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for
+  NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio,
+  1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals.
+* Dedicated Centralized System Controller for Security, Power, and
+  Resource Management.
+* Multiple low power modes support, ex: Deep sleep, Standby, MCU-only,
+  enabling battery powered system design.
+
+More details can be found in the Technical Reference Manual:
+https://www.ti.com/lit/pdf/spruj16
+
+Platform information:
+
+* https://www.ti.com/tool/SK-AM62A-LP
+
+Boot Flow:
+----------
+Below is the pictorial representation of boot flow:
+
+.. image:: img/boot_diagram_k3_current.svg
+  :alt: Boot flow diagram
+
+- Here TIFS acts as master and provides all the critical services. R5/A53
+  requests TIFS to get these services done as shown in the above diagram.
+
+Sources:
+--------
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_boot_sources
+    :end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+----------------
+0. Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_common_env_vars_desc
+    :end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_board_env_vars_desc
+    :end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_common_env_vars_defn
+    :end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=am62ax_evm_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=am62ax_evm_a53_defconfig
+ $ export TFA_BOARD=lite
+ $ # we dont use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS
+ $ export OPTEE_PLATFORM=k3-am62ax
+ $ # we dont use any extra OPTEE parameters
+ $ unset OPTEE_EXTRA_ARGS
+
+1. Trusted Firmware-A:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_tfa
+    :end-before: .. k3_rst_include_end_build_steps_tfa
+
+2. OP-TEE:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_optee
+    :end-before: .. k3_rst_include_end_build_steps_optee
+
+3. U-Boot:
+
+* 3.1 R5:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_spl_r5
+    :end-before: .. k3_rst_include_end_build_steps_spl_r5
+
+* 3.2 A53:
+
+.. include::  ../ti/k3.rst
+    :start-after: .. k3_rst_include_start_build_steps_uboot
+    :end-before: .. k3_rst_include_end_build_steps_uboot
+
+Target Images
+--------------
+In order to boot we need tiboot3.bin, tispl.bin and u-boot.img.  Each SoC
+variant (GP, HS-FS, HS-SE) requires a different source for these files.
+
+ - GP
+
+        * tiboot3-am62ax-gp-evm.bin from step 3.1
+        * tispl.bin_unsigned, u-boot.img_unsigned from step 3.2
+
+ - HS-FS
+
+        * tiboot3-am62ax-hs-fs-evm.bin from step 3.1
+        * tispl.bin, u-boot.img from step 3.2
+
+ - HS-SE
+
+        * tiboot3-am62ax-hs-evm.bin from step 3.1
+        * tispl.bin, u-boot.img from step 3.2
+
+Image formats:
+--------------
+
+- tiboot3.bin
+
+.. image:: img/multi_cert_tiboot3.bin.svg
+  :alt: tiboot3.bin image format
+
+- tispl.bin
+
+.. image:: img/dm_tispl.bin.svg
+  :alt: tispl.bin image format
+
+Switch Setting for Boot Mode
+----------------------------
+
+Boot Mode pins provide means to select the boot mode and options before the
+device is powered up. After every POR, they are the main source to populate
+the Boot Parameter Tables.
+
+The following table shows some common boot modes used on AM62 platform. More
+details can be found in the Technical Reference Manual:
+https://www.ti.com/lit/pdf/spruj16 under the `Boot Mode Pins` section.
+
+.. list-table:: Boot Modes
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Switch Label
+     - SW2: 12345678
+     - SW3: 12345678
+
+   * - SD
+     - 01000000
+     - 11000010
+
+   * - OSPI
+     - 00000000
+     - 11001110
+
+   * - EMMC
+     - 00000000
+     - 11010010
+
+   * - UART
+     - 00000000
+     - 11011100
+
+   * - USB DFU
+     - 00000000
+     - 11001010
+
+For SW2 and SW1, the switch state in the "ON" position = 1.
+
+Debugging U-Boot
+----------------
+
+See :ref:`Common Debugging environment - OpenOCD<k3_rst_refer_openocd>`: for
+detailed setup information.
+
+.. warning::
+
+  **OpenOCD support since**: August 2023 (git master)
+
+  Until the next stable release of OpenOCD is available in your development
+  environment's distribution, it might be necessary to build OpenOCD `from the
+  source <https://github.com/openocd-org/openocd>`_.
+
+.. include::  k3.rst
+    :start-after: .. k3_rst_include_start_openocd_connect_XDS110
+    :end-before: .. k3_rst_include_end_openocd_connect_XDS110
+
+To start OpenOCD and connect to the board
+
+.. code-block:: bash
+
+  openocd -f board/ti_am62a7evm.cfg
diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst
index 113475d7c9d..a422a9bf1a0 100644
--- a/doc/board/ti/j721e_evm.rst
+++ b/doc/board/ti/j721e_evm.rst
@@ -48,7 +48,7 @@ support. Below is the pictorial representation of boot flow:
 Sources:
 --------
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_boot_sources
     :end-before: .. k3_rst_include_end_boot_sources
 
@@ -56,17 +56,17 @@ Build procedure:
 ----------------
 0. Setup the environment variables:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_common_env_vars_desc
     :end-before: .. k3_rst_include_end_common_env_vars_desc
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_board_env_vars_desc
     :end-before: .. k3_rst_include_end_board_env_vars_desc
 
 Set the variables corresponding to this platform:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_common_env_vars_defn
     :end-before: .. k3_rst_include_end_common_env_vars_defn
 .. prompt:: bash $
@@ -84,14 +84,14 @@ Set the variables corresponding to this platform:
 
 1. Trusted Firmware-A:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_build_steps_tfa
     :end-before: .. k3_rst_include_end_build_steps_tfa
 
 
 2. OP-TEE:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_build_steps_optee
     :end-before: .. k3_rst_include_end_build_steps_optee
 
@@ -99,13 +99,13 @@ Set the variables corresponding to this platform:
 
 * 3.1 R5:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_build_steps_spl_r5
     :end-before: .. k3_rst_include_end_build_steps_spl_r5
 
 * 3.2 A72:
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_build_steps_uboot
     :end-before: .. k3_rst_include_end_build_steps_uboot
 .. j721e_evm_rst_include_end_build_steps
@@ -249,7 +249,7 @@ detailed setup information.
   environment's distribution needs to be updated, it might be necessary to
   build OpenOCD from the source.
 
-.. include::  k3.rst
+.. include::  ../ti/k3.rst
     :start-after: .. k3_rst_include_start_openocd_connect_XDS110
     :end-before: .. k3_rst_include_end_openocd_connect_XDS110
 
diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 5167925c9c6..7dfe39c5fa5 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -30,12 +30,14 @@ K3 Based SoCs
 .. toctree::
    :maxdepth: 1
 
-   am62x_beagleplay
+   am62ax_sk
    am62x_sk
+   ../beagle/am62x_beagleplay
    ../toradex/verdin-am62
    am64x_evm
    am65x_evm
    j7200_evm
+   ../beagle/j721e_beagleboneai64
    j721e_evm
    j721s2_evm
 
@@ -102,6 +104,49 @@ firmware can be loaded on the now free core in the wakeup domain.
 For more information on the bootup process of your SoC, consult the
 device specific boot flow documentation.
 
+Secure Boot
+-----------
+
+K3 HS-SE (High Security - Security Enforced) devices enforce an
+authenticated boot flow for secure boot. HS-FS (High Security - Field
+Securable) is the state of a K3 device before it has been eFused with
+customer security keys.  In the HS-FS state the authentication still can
+function as in HS-SE but as there are no customer keys to verify the
+signatures against the authentication will pass for certificates signed
+with any key.
+
+Chain of trust
+^^^^^^^^^^^^^^
+
+1) Public ROM loads the tiboot3.bin (R5 SPL, TIFS)
+2) R5 SPL loads tispl.bin (ATF, OP-TEE, DM, SPL)
+3) SPL loads u-boot.img (U-Boot)
+4) U-Boot loads fitImage (Linux and DTBs)
+
+Steps 1-3 are all authenticated by either the Secure ROM or TIFS as the
+authenticating entity and step 4 uses U-boot standard mechanism for
+authenticating.
+
+All the authentication that are done for ROM/TIFS are done through x509
+certificates that are signed.
+
+Firewalls
+^^^^^^^^^
+
+1) Secure ROM comes up and sets up firewalls that are needed by itself
+2) TIFS will setup it's own firewalls to protect core system resources
+3) R5 SPL will remove any firewalls that are leftover from the Secure ROM stage
+   that are no longer required.
+4) Each stage beyond this: such as tispl.bin containing TFA/OPTEE uses OIDs to
+   set up firewalls to protect themselves (enforced by TIFS)
+5) TFA/OP-TEE can configure other firewalls at runtime if required as they
+   are already authenticated and firewalled off from illegal access.
+6) All later stages can setup or remove firewalls that have not been already
+   configured by previous stages, such as those created by TIFS, TFA, and OP-TEE.
+
+Futhur, firewalls have a lockdown bit in hardware that enforces the setting
+(and cannot be over-ridden) until the full system is reset.
+
 Software Sources
 ----------------
 
@@ -246,6 +291,8 @@ Building tiboot3.bin
    the final `tiboot3.bin` binary. (or the `sysfw.itb` if your device
    uses the split binary flow)
 
+.. _k3_rst_include_start_build_steps_spl_r5:
+
 .. k3_rst_include_start_build_steps_spl_r5
 .. prompt:: bash $
 
@@ -310,6 +357,8 @@ use the `lite` option.
    finished, we can jump back into U-Boot again, this time running on a
    64bit core in the main domain.
 
+.. _k3_rst_include_start_build_steps_uboot:
+
 .. k3_rst_include_start_build_steps_uboot
 .. prompt:: bash $
 
@@ -318,6 +367,13 @@ use the `lite` option.
  make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
         BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
         TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
+
+.. note::
+   It is also possible to pick up a custom DM binary by adding TI_DM argument
+   pointing to the file. If not provided, it defaults to picking up the DM
+   binary from BINMAN_INDIRS. This is only applicable to devices that utilize
+   split firmware.
+
 .. k3_rst_include_end_build_steps_uboot
 
 At this point you should have every binary needed initialize both the
@@ -328,144 +384,212 @@ wakeup and main domain and to boot to the U-Boot prompt
    | `tispl.bin` for HS devices or `tispl.bin_unsigned` for GP devices
    | `u-boot.img` for HS devices or `u-boot.img_unsigned` for GP devices
 
-Fit Signature Signing
+FIT signature signing
 ---------------------
 
-K3 Platforms have fit signature signing enabled by default on their primary
-platforms. Here we'll take an example for creating fit image for J721e platform
+K3 platforms have FIT signature signing enabled by default on their primary
+platforms. Here we'll take an example for creating FIT Image for J721E platform
 and the same can be extended to other platforms
 
-1. Describing FIT source
+Pre-requisites:
+
+* U-boot build (:ref:`U-boot build <k3_rst_include_start_build_steps_spl_r5>`)
+* Linux Image and Linux DTB prebuilt
 
-  .. code-block:: bash
+Describing FIT source
+^^^^^^^^^^^^^^^^^^^^^
+
+FIT Image is a packed structure containing binary blobs and configurations.
+The Kernel FIT Image that we have has Kernel Image, DTB and the DTBOs.  It
+supports packing multiple images and configurations that allow you to
+choose any configuration at runtime to boot from.
+
+.. code-block::
 
     /dts-v1/;
 
     / {
-            description = "Kernel fitImage for j721e-hs-evm";
-            #address-cells = <1>;
+        description = "FIT Image description";
+        #address-cells = <1>;
 
-            images {
-                    kernel-1 {
-                            description = "Linux kernel";
-                            data = /incbin/("Image");
-                            type = "kernel";
-                            arch = "arm64";
-                            os = "linux";
-                            compression = "none";
-                            load = <0x80080000>;
-                            entry = <0x80080000>;
-                            hash-1 {
-                                    algo = "sha512";
-                            };
+        images {
+            [image-1]
+            [image-2]
+            [fdt-1]
+            [fdt-2]
+        }
 
-                    };
-                    fdt-ti_k3-j721e-common-proc-board.dtb {
-                            description = "Flattened Device Tree blob";
-                            data = /incbin/("k3-j721e-common-proc-board.dtb");
-                            type = "flat_dt";
-                            arch = "arm64";
-                            compression = "none";
-                            load = <0x83000000>;
-                            hash-1 {
-                                    algo = "sha512";
-                            };
+        configurations {
+            default = <conf-1>
+            [conf-1: image-1,fdt-1]
+            [conf-2: image-2,fdt-1]
+        }
+    }
 
-                    };
-            };
+* Sample Images
 
-            configurations {
-                    default = "conf-ti_k3-j721e-common-proc-board.dtb";
-                    conf-ti_k3-j721e-common-proc-board.dtb {
-                            description = "Linux kernel, FDT blob";
-                            fdt = "fdt-ti_k3-j721e-common-proc-board.dtb";
-                            kernel = "kernel-1";
-                            signature-1 {
-                                    algo = "sha512,rsa4096";
-                                    key-name-hint = "custMpk";
-                                    sign-images = "kernel", "fdt";
-                            };
-                    };
+.. code-block::
+
+    kernel-1 {
+            description = "Linux kernel";
+            data = /incbin/("linux.bin");
+            type = "kernel";
+            arch = "arm64";
+            os = "linux";
+            compression = "gzip";
+            load = <0x81000000>;
+            entry = <0x81000000>;
+            hash-1 {
+                    algo = "sha512";
+            };
+    };
+    fdt-ti_k3-j721e-common-proc-board.dtb {
+            description = "Flattened Device Tree blob";
+            data = /incbin/("arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb");
+            type = "flat_dt";
+            arch = "arm64";
+            compression = "none";
+            load = <0x83000000>;
+            hash-1 {
+                    algo = "sha512";
+            };
+    };
+    # Optional images
+    fdt-ti_k3-j721e-evm-virt-mac-client.dtbo {
+            description = "Flattened Device Tree blob";
+            data = /incbin/("arch/arm64/boot/dts/ti/k3-j721e-evm-virt-mac-client.dtbo");
+            type = "flat_dt";
+            arch = "arm64";
+            compression = "none";
+            load = <0x83080000>;
+            hash-1 {
+                    algo = "sha512";
             };
     };
 
-  You would require to change the '/incbin/' lines to point to the respective
-  files in your local machine and the key-name-hint also needs to be changed
-  if you are using some other key other than the TI dummy key that we are
-  using for this example.
+.. note::
+
+    Change the path in data variables to point to the respective files in your
+    local machine. For e.g change "linux.bin" to "<path-to-kernel-image>".
+
+For enabling usage of FIT signature, add the signature node to the
+corresponding configuration node as follows.
+
+* Sample Configurations
+
+.. code-block::
+
+    conf-ti_k3-j721e-common-proc-board.dtb {
+            description = "Linux kernel, FDT blob";
+            fdt = "fdt-ti_k3-j721e-common-proc-board.dtb";
+            kernel = "kernel-1";
+            signature-1 {
+                    algo = "sha512,rsa4096";
+                    key-name-hint = "custMpk";
+                    sign-images = "kernel", "fdt";
+            };
+    };
+    # Optional configurations
+    conf-ti_k3-j721e-evm-virt-mac-client.dtbo {
+            description = "FDTO blob";
+            fdt = "fdt-ti_k3-j721e-evm-virt-mac-client.dtbo";
 
-2. Compile U-boot for the respective board
+            signature-1 {
+                    algo = "sha512,rsa4096";
+                    key-name-hint = "custMpk";
+                    sign-images = "fdt";
+            };
+    };
 
-.. include::  k3.rst
-    :start-after: .. k3_rst_include_start_build_steps_uboot
-    :end-before: .. k3_rst_include_end_build_steps_uboot
+Specify all images you need the signature to authenticate as a part of
+sign-images. The key-name-hint needs to be changed if you are using some
+other key other than the TI dummy key that we are using for this example.
+It should be the name of the file containing the keys.
 
 .. note::
 
-    The changes only affect a72 binaries so the example just builds that
+    Generating new set of keys:
+
+    .. prompt:: bash $
+
+        mkdir keys
+        openssl genpkey -algorithm RSA -out keys/dev.key \
+        -pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537
+        openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt
 
-3. Sign the fit image and embed the dtb in uboot
+Generating the fitImage
+^^^^^^^^^^^^^^^^^^^^^^^
 
-  Now once the build is done, you'll have a dtb for your board that you'll
-  be passing to mkimage for signing the fitImage and embedding the key in
-  the u-boot dtb.
+.. note::
 
-  .. prompt:: bash $
+    For signing a secondary platform like SK boards, you'll require
+    additional steps
 
-    mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
-    $UBOOT_PATH/build/a72/dts/dt.dtb
+    - Change the CONFIG_DEFAULT_DEVICE_TREE
 
-  For signing a secondary platform, pass the -K parameter to that DTB
+        For e.g
 
-  .. prompt:: bash $
+        .. code-block::
 
-    mkimage -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K
-    $UBOOT_PATH/build/a72/arch/arm/dts/k3-j721e-sk.dtb
+            diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
+            index a5c1df7e0054..6d0126d955ef 100644
+            --- a/configs/j721e_evm_a72_defconfig
+            +++ b/configs/j721e_evm_a72_defconfig
+            @@ -13,7 +13,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80480000
+             CONFIG_ENV_SIZE=0x20000
+             CONFIG_DM_GPIO=y
+             CONFIG_SPL_DM_SPI=y
+            -CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
+            +CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk"
+             CONFIG_SPL_TEXT_BASE=0x80080000
+             CONFIG_DM_RESET=y
+             CONFIG_SPL_MMC=y
 
-  .. note::
+    - Change the binman nodes to package u-boot.dtb for the correct set of platform
 
-    If changing `CONFIG_DEFAULT_DEVICE_TREE` to the secondary platform,
-    binman changes would also be required so that correct dtb gets packaged.
+        For e.g
 
-    .. code-block:: bash
+        .. code-block::
 
-      diff --git a/arch/arm/dts/k3-j721e-binman.dtsi b/arch/arm/dts/k3-j721e-binman.dtsi
-      index 673be646b1e3..752fa805fe8d 100644
-      --- a/arch/arm/dts/k3-j721e-binman.dtsi
-      +++ b/arch/arm/dts/k3-j721e-binman.dtsi
-      @@ -299,8 +299,8 @@
-       #define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb"
+            diff --git a/arch/arm/dts/k3-j721e-binman.dtsi b/arch/arm/dts/k3-j721e-binman.dtsi
+                  index 673be646b1e3..752fa805fe8d 100644
+                  --- a/arch/arm/dts/k3-j721e-binman.dtsi
+                  +++ b/arch/arm/dts/k3-j721e-binman.dtsi
+                  @@ -299,8 +299,8 @@
+                   #define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb"
 
-       #define UBOOT_NODTB "u-boot-nodtb.bin"
-      -#define J721E_EVM_DTB "u-boot.dtb"
-      -#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb"
-      +#define J721E_EVM_DTB "arch/arm/dts/k3-j721e-common-proc-board.dtb"
-      +#define J721E_SK_DTB "u-boot.dtb"
+                   #define UBOOT_NODTB "u-boot-nodtb.bin"
+                  -#define J721E_EVM_DTB "u-boot.dtb"
+                  -#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb"
+                  +#define J721E_EVM_DTB "arch/arm/dts/k3-j721e-common-proc-board.dtb"
+                  +#define J721E_SK_DTB "u-boot.dtb"
 
-5. Rebuilt u-boot
+This step will embed the public key in the u-boot.dtb file that was already
+built during the initial u-boot build.
 
-   This is required so that the modified dtb gets updated in u-boot.img
+.. prompt:: bash $
 
-.. include::  k3.rst
-    :start-after: .. k3_rst_include_start_build_steps_uboot
-    :end-before: .. k3_rst_include_end_build_steps_uboot
+    mkimage -r -f fitImage.its -k $UBOOT_PATH/board/ti/keys -K $UBOOT_PATH/build/$ARMV8/dts/dt.dtb fitImage
 
-6. (Optional) Enabled FIT_SIGNATURE_ENFORCED
+.. note::
 
-   By default u-boot will boot up the fit image without any authentication as
-   such if the public key is not embedded properly, to check if the public key
-   nodes are proper you can enable FIT_SIGNATURE_ENFORCED that would not rely
-   on the dtb for anything else then the signature node for checking the fit
-   image, rest other things will be enforced such as the property of
-   required-keys. This is not an extensive check so do manual checks also
+    If you have another set of keys then change the -k argument to point to
+    the folder where your keys are present, the build requires the presence
+    of both .key and .crt file.
+
+Build u-boot again
+^^^^^^^^^^^^^^^^^^
 
-   This is by default enabled for devices with TI_SECURE_DEVICE enabled.
+The updated u-boot.dtb needs to be packed in u-boot.img for authentication
+so rebuild U-boot ARMV8 without changing any parameters.
+Refer (:ref:`U-boot ARMV8 build <k3_rst_include_start_build_steps_uboot>`)
 
 .. note::
 
-   The devices now also have distroboot enabled so if the fit image doesn't
-   work then the fallback to normal distroboot will be there on hs devices,
-   this will need to be explicitly disabled by changing the boot_targets.
+   The devices now also have distroboot enabled so if the FIT image doesn't
+   work then the fallback to normal distroboot will be there on HS devices.
+   This will need to be explicitly disabled by changing the boot_targets to
+   disallow fallback during testing.
 
 Saving environment
 ------------------
diff --git a/doc/build/documentation.rst b/doc/build/documentation.rst
index 20b0fefa2d8..098c96a4c4f 100644
--- a/doc/build/documentation.rst
+++ b/doc/build/documentation.rst
@@ -37,7 +37,7 @@ The *htmldocs* target is used to build the HTML documentation. It uses the
     # Display the documentation in a graphical web browser
     x-www-browser doc/output/index.html
 
-The HTML documentation is published at https://u-boot.readthedocs.io. The build
+The HTML documentation is published at https://docs.u-boot.org. The build
 process for that site is controlled by the file *.readthedocs.yml*.
 
 Infodoc documentation
diff --git a/doc/chromium/files/chromebook_jerry.its b/doc/chromium/files/chromebook_jerry.its
index 7505a20535b..02e5e1340f3 100644
--- a/doc/chromium/files/chromebook_jerry.its
+++ b/doc/chromium/files/chromebook_jerry.its
@@ -15,7 +15,7 @@
 			load = <0>;
 			entry = <0>;
 			hash-2 {
-				algo = "sha1";
+				algo = "sha256";
 			};
 		};
 
@@ -26,7 +26,7 @@
 			arch = "arm";
 			compression = "none";
 			hash-1{
-				algo = "sha1";
+				algo = "sha256";
 			};
 		};
 	};
diff --git a/doc/chromium/files/nyan-big.its b/doc/chromium/files/nyan-big.its
index bd412915e95..60bdffbb829 100644
--- a/doc/chromium/files/nyan-big.its
+++ b/doc/chromium/files/nyan-big.its
@@ -15,7 +15,7 @@
 			load = <0>;
 			entry = <0>;
 			hash-2 {
-				algo = "sha1";
+				algo = "sha256";
 			};
 		};
 
@@ -26,7 +26,7 @@
 			arch = "arm";
 			compression = "none";
 			hash-1{
-				algo = "sha1";
+				algo = "sha256";
 			};
 		};
 	};
diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst
index 81643c7674b..28431039adc 100644
--- a/doc/develop/bloblist.rst
+++ b/doc/develop/bloblist.rst
@@ -14,6 +14,8 @@ structure defined by the code that owns it.
 For the design goals of bloblist, please see the comments at the top of the
 `bloblist.h` header file.
 
+Bloblist is an implementation with the `Firmware Handoff`_ protocol.
+
 Passing state through the boot process
 --------------------------------------
 
@@ -99,7 +101,7 @@ API documentation
 -----------------
 
 .. kernel-doc:: include/bloblist.h
-
+.. _`Firmware Handoff`: https://github.com/FirmwareHandoff/firmware_handoff
 
 Simon Glass
 [email protected]
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index cbb65c9b177..11c92d440f4 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -108,6 +108,9 @@ If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
 devicetree at runtime, for example if an earlier bootloader stage creates
 it and passes it to U-Boot.
 
+If CONFIG_BLOBLIST is defined, the devicetree may come from a bloblist passed
+from a previous stage, if present.
+
 If CONFIG_SANDBOX is defined, then it will be read from a file on
 startup. Use the -d flag to U-Boot to specify the file to read, -D for the
 default and -T for the test devicetree, used to run sandbox unit tests.
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index fb16ac743a0..6bc9d92285b 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -642,6 +642,40 @@ UEFI variables. Booting according to these variables is possible via::
 As of U-Boot v2020.10 UEFI variables cannot be set at runtime. The U-Boot
 command 'efidebug' can be used to set the variables.
 
+UEFI HTTP Boot
+~~~~~~~~~~~~~~
+
+HTTP Boot provides the capability for system deployment and configuration
+over the network. HTTP Boot can be activated by specifying::
+
+    CONFIG_EFI_HTTP_BOOT
+
+Enabling that will automatically select::
+
+    CONFIG_CMD_DNS
+    CONFIG_CMD_WGET
+    CONFIG_BLKMAP
+
+Set up the load option specifying the target URI::
+
+    efidebug boot add -u 1 netinst http://foo/bar
+
+When this load option is selected as boot selection, resolve the
+host ip address by dns, then download the file with wget.
+If the downloaded file extension is .iso or .img file, efibootmgr tries to
+mount the image and boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
+If the downloaded file is PE-COFF image, load the downloaded file and
+start it.
+
+The current implementation tries to resolve the IP address as a host name.
+If the uri is like "http://192.168.1.1/foobar",
+the dns process tries to resolve the host "192.168.1.1" and it will
+end up with "host not found".
+
+We need to preset the "httpserverip" environment variable to proceed the wget::
+
+    setenv httpserverip 192.168.1.1
+
 Executing the built in hello world application
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt b/doc/device-tree-bindings/leds/leds-lp5562.txt
new file mode 100644
index 00000000000..4e0c742959a
--- /dev/null
+++ b/doc/device-tree-bindings/leds/leds-lp5562.txt
@@ -0,0 +1,63 @@
+LEDs connected to TI LP5562 controller
+
+This driver works with a TI LP5562 4-channel LED controller.
+CONFIG_LED_BLINK is supported using the controller engines.  However
+there are only 3 engines available for the 4 channels.  This means
+that the blue and white channels share the same engine.  When both
+blue and white LEDs are set to blink, they will share the same blink
+rate.  Changing the blink rate of the blue LED will affect the white
+LED and vice-versa.  Manual on/off is handled independently for all 4
+channels.
+
+Required properties:
+  - compatible : should be "ti,lp5562".
+  - #address-cells : must be 1.
+  - #size-cells : must be 0.
+  - reg : LP5562 LED controller I2C address.
+
+Optional properties:
+  - enable-gpios : Enable GPIO
+  - clock-mode : u8, configures the clock mode:
+      - 0 # automode
+      - 1 # internal
+      - 2 # external
+
+Each LED is represented as a sub-node of the ti,lp5562 device.
+
+LED sub-node required properties:
+  - reg : Zero-based channel identifier:
+    - 0 red
+    - 1 green
+    - 2 blue
+    - 3 white
+
+LED sub-node optional properties:
+  - chan-name : name of LED
+  - max-cur : LED current at max brightness in 100uA steps (0x00 - 0xFF)
+    Default : 100 (10 mA)
+
+Example:
+        leds0: lp5562@30 {
+                compatible = "ti,lp5562";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                enable-gpios = <&gpio3 9 GPIO_ACTIVE_HIGH>;
+                reg = <0x30>;
+		clock-mode = /bits/8 <1>;
+
+                led@0 {
+                        reg = <0>;
+                        chan-name = "red";
+                        max-cur = /bits/ 8 <200>; /* 20mA */
+                };
+                led@1 {
+                        reg = <1>;
+                        chan-name = "green";
+                        max-cur = /bits/ 8 <200>; /* 20mA */
+                };
+                led@2 {
+                        reg = <2>;
+                        chan-name = "blue";
+                        max-cur = /bits/ 8 <200>; /* 20mA */
+                };
+        };
diff --git a/doc/device-tree-bindings/misc/esm-k3.txt b/doc/device-tree-bindings/misc/esm-k3.txt
deleted file mode 100644
index 01c8b6b294b..00000000000
--- a/doc/device-tree-bindings/misc/esm-k3.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Texas Instruments K3 ESM Binding
-======================
-
-ESM (Error Signaling Module) is an IP block on TI K3 devices that allows
-handling of safety events somewhat similar to what interrupt controller
-would do. The safety signals have their separate paths within the SoC,
-and they are handled by the ESM, which routes them to the proper
-destination, which can be system reset, interrupt controller, etc. In
-the simplest configuration the signals are just routed to reset the
-SoC.
-
-Required properties :
-- compatible	: "ti,j721e-esm"
-- ti,esm-pins	: integer array of esm events IDs to route to external event
-		  pin which can be used to reset the SoC. The array can
-		  have arbitrary amount of event IDs listed on it.
-
-Example
-=======
-
-	main_esm: esm@700000 {
-		compatible = "ti,j721e-esm";
-		reg = <0x0 0x700000 0x0 0x1000>;
-		ti,esm-pins = <344>, <345>;
-	};
diff --git a/doc/device-tree-bindings/misc/ti,j721e-esm.yaml b/doc/device-tree-bindings/misc/ti,j721e-esm.yaml
new file mode 100644
index 00000000000..0c9a8444844
--- /dev/null
+++ b/doc/device-tree-bindings/misc/ti,j721e-esm.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,j721e-esm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM
+
+maintainers:
+  - Neha Malcom Francis <[email protected]>
+
+description:
+  The ESM (Error Signaling Module) is an IP block on TI K3 devices
+  that allows handling of safety events somewhat similar to what interrupt
+  controller would do. The safety signals have their separate paths within
+  the SoC, and they are handled by the ESM, which routes them to the proper
+  destination, which can be system reset, interrupt controller, etc. In the
+  simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+  compatible:
+    const: ti,j721e-esm
+
+  reg:
+    maxItems: 1
+
+  ti,esm-pins:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      integer array of ESM interrupt pins to route to external event pin
+      which can be used to reset the SoC.
+    minItems: 1
+    maxItems: 255
+
+required:
+  - compatible
+  - reg
+  - ti,esm-pins
+
+additionalProperties: false
+
+examples:
+  - |
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        esm@700000 {
+            compatible = "ti,j721e-esm";
+            reg = <0x0 0x700000 0x0 0x1000>;
+            ti,esm-pins = <344>, <345>;
+        };
+    };
diff --git a/doc/device-tree-bindings/nand/sandbox,nand.txt b/doc/device-tree-bindings/nand/sandbox,nand.txt
new file mode 100644
index 00000000000..0a723d7c058
--- /dev/null
+++ b/doc/device-tree-bindings/nand/sandbox,nand.txt
@@ -0,0 +1,57 @@
+Sandbox NAND
+============
+
+The sandbox NAND controller emulates a NAND controller and attached devices.
+
+Required properties:
+- compatible: "sandbox,nand"
+- #address-cells: Must be 1
+- #size-cells: Must be 0
+
+Any number of child nodes may be present, each representing a NAND device:
+
+Required Properties:
+- reg: The chip-select(s) to use. Only single-die devices are supported for now.
+- sandbox,id: An array of bytes to be reported by the READID (0x90) command
+- sandbox,erasesize: The block size (erase size) of the device, in bytes. Must
+                     be a power-of-two multiple of the page size.
+- sandbox,oobsize: The size of the OOB area per page, in bytes.
+- sandbox,pagesize: The page size (write size) of the device, in bytes. Must be
+                    a power of two.
+- sandbox,pages: The total number of pages in the device.
+- sandbox,err-count: Number of bit errors to inject per step.
+- sandbox,err-step-size: Size of the step to use when injecting errors, in
+                         bytes. Must evenly divide the page size.
+
+Optional properties:
+- sandbox,onfi: The complete ONFI parameter page, including the CRC. Should be
+                exactly 256 bytes.
+- Any common NAND chip properties as documented by Linux's
+  Documentation/devicetree/bindings/mtd/raw-nand-chip.yaml
+
+To match U-Boot's error correction capabilities, errors are only injected into
+the data area and the ECC codes. Other data in the OOB area is never corrupted.
+Generally, sandbox,err-step-size should be the same as the ECC step size, and
+sandbox,err-count should be less than the number of correctable bit errors (the
+ECC strength).
+
+Example
+-------
+
+nand-controller {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "sandbox,nand";
+
+	nand@0 {
+		reg = <0>;
+		nand-ecc-mode = "soft";
+		sandbox,id = [00 e3];
+		sandbox,erasesize = <(8 * 1024)>;
+		sandbox,oobsize = <16>;
+		sandbox,pagesize = <512>;
+		sandbox,pages = <0x2000>;
+		sandbox,err-count = <1>;
+		sandbox,err-step-size = <512>;
+	};
+};
diff --git a/doc/usage/cmd/bootflow.rst b/doc/usage/cmd/bootflow.rst
index 2198ff60493..27e1330ad8a 100644
--- a/doc/usage/cmd/bootflow.rst
+++ b/doc/usage/cmd/bootflow.rst
@@ -52,6 +52,8 @@ Flags are:
     matters, since by then the system boots in the OS and U-Boot is no-longer
     running. `bootflow scan -b` is a quick way to boot the first available OS.
     A valid bootflow is one that made it all the way to the `loaded` state.
+    Note that if `-m` is provided as well, booting is delayed until the user
+    selects a bootflow.
 
 -e
     Used with -l to also show errors for each bootflow. The shows detailed error
@@ -71,6 +73,9 @@ Flags are:
     priority or label is tried, to see if more bootdevs can be discovered, but
     this flag disables that process.
 
+-m
+    Show a menu of available bootflows for the user to select. When used with
+    -b it then boots the one that was selected, if any.
 
 The optional argument specifies a particular bootdev to scan. This can either be
 the name of a bootdev or its sequence number (both shown with `bootdev list`).
diff --git a/doc/usage/cmd/cli.rst b/doc/usage/cmd/cli.rst
new file mode 100644
index 00000000000..a0cf5958fb9
--- /dev/null
+++ b/doc/usage/cmd/cli.rst
@@ -0,0 +1,74 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+cli command
+===========
+
+Synopis
+-------
+
+::
+
+    cli get
+    cli set cli_flavor
+
+Description
+-----------
+
+The cli command permits getting and changing the current parser at runtime.
+
+cli get
+~~~~~~~
+
+It shows the current value of the parser used by the CLI.
+
+cli set
+~~~~~~~
+
+It permits setting the value of the parser used by the CLI.
+
+Possible values are old and modern.
+Note that, to use a specific parser its code should have been compiled, that
+is to say you need to enable the corresponding CONFIG_HUSH*.
+Otherwise, an error message is printed.
+
+Examples
+--------
+
+Get the current parser::
+
+    => cli get
+    old
+
+Change the current parser::
+
+    => cli get
+    old
+    => cli set modern
+    => cli get
+    modern
+    => cli set old
+    => cli get
+    old
+
+Trying to set the current parser to an unknown value::
+
+    => cli set foo
+    Bad value for parser name: foo
+    cli - cli
+
+    Usage:
+    cli get - print current cli
+    set - set the current cli, possible values are: old, modern
+
+Trying to set the current parser to a correct value but its code was not
+compiled::
+
+    => cli get
+    modern
+    => cli set old
+    Want to set current parser to old, but its code was not compiled!
+
+Return value
+------------
+
+The return value $? indicates whether the command succeeded.
diff --git a/doc/usage/cmd/imxtract.rst b/doc/usage/cmd/imxtract.rst
index eb64b1cefab..16be60b4aab 100644
--- a/doc/usage/cmd/imxtract.rst
+++ b/doc/usage/cmd/imxtract.rst
@@ -45,14 +45,14 @@ Examples
 
 With verify=no incorrect hashes, signatures, or check sums don't stop the
 extraction. But correct hashes are still indicated in the output
-(here: md5, sha1).
+(here: sha256, sha512).
 
 .. code-block:: console
 
     => setenv verify no
     => imxtract $loadaddr kernel-1 $kernel_addr_r
     ## Copying 'kernel-1' subimage from FIT image at 40200000 ...
-    md5+ sha1+    Loading part 0 ... OK
+    sha256+ sha512+    Loading part 0 ... OK
     =>
 
 With verify=yes incorrect hashes, signatures, or check sums stop the extraction.
@@ -62,7 +62,7 @@ With verify=yes incorrect hashes, signatures, or check sums stop the extraction.
     => setenv verify yes
     => imxtract $loadaddr kernel-1 $kernel_addr_r
     ## Copying 'kernel-1' subimage from FIT image at 40200000 ...
-    md5 error!
+    sha256 error!
     Bad hash value for 'hash-1' hash node in 'kernel-1' image node
     Bad Data Hash
     =>
diff --git a/doc/usage/cmd/scmi.rst b/doc/usage/cmd/scmi.rst
new file mode 100644
index 00000000000..9ea7e0e41da
--- /dev/null
+++ b/doc/usage/cmd/scmi.rst
@@ -0,0 +1,126 @@
+.. SPDX-License-Identifier: GPL-2.0+:
+
+scmi command
+============
+
+Synopsis
+--------
+
+::
+
+    scmi info
+    scmi perm_dev <agent id> <device id> <flags>
+    scmi perm_proto <agent id> <device id> <protocol id> <flags>
+    scmi reset <agent id> <flags>
+
+Description
+-----------
+
+Arm System Control and Management Interface (SCMI hereafter) is a set of
+standardised interfaces to manage system resources, like clocks, power
+domains, pin controls, reset and so on, in a system-wide manner.
+
+An entity which provides those services is called a SCMI firmware (or
+SCMI server if you like) may be placed/implemented by EL3 software or
+by a dedicated system control processor (SCP) or else.
+
+A user of SCMI interfaces, including U-Boot, is called a SCMI agent and
+may issues commands, which are defined in each protocol for specific system
+resources, to SCMI server via a communication channel, called a transport.
+Those interfaces are independent from the server's implementation thanks to
+a transport layer.
+
+For more details, see the `SCMI specification`_.
+
+While most of system resources managed under SCMI protocols are implemented
+and handled as standard U-Boot devices, for example clk_scmi, scmi command
+provides additional management functionality against SCMI server.
+
+scmi info
+~~~~~~~~~
+    Show base information about SCMI server and supported protocols
+
+scmi perm_dev
+~~~~~~~~~~~~~
+    Allow or deny access permission to the device
+
+scmi perm_proto
+~~~~~~~~~~~~~~~
+    Allow or deny access to the protocol on the device
+
+scmi reset
+~~~~~~~~~~
+    Reset the already-configured permissions against the device
+
+Parameters are used as follows:
+
+<agent id>
+    SCMI Agent ID, hex value
+
+<device id>
+    SCMI Device ID, hex value
+
+    Please note that what a device means is not defined
+    in the specification.
+
+<protocol id>
+    SCMI Protocol ID, hex value
+
+    It must not be 0x10 (base protocol)
+
+<flags>
+    Flags to control the action, hex value
+
+    0 to deny, 1 to allow. The other values are reserved and allowed
+    values may depend on the implemented version of SCMI server in
+    the future. See SCMI specification for more details.
+
+Example
+-------
+
+Obtain basic information about SCMI server:
+
+::
+
+    => scmi info
+    SCMI device: scmi
+      protocol version: 0x20000
+      # of agents: 3
+          0: platform
+        > 1: OSPM
+          2: PSCI
+      # of protocols: 4
+          Power domain management
+          Performance domain management
+          Clock management
+          Sensor management
+      vendor: Linaro
+      sub vendor: PMWG
+      impl version: 0x20b0000
+
+Ask for access permission to device#0:
+
+::
+
+    => scmi perm_dev 1 0 1
+
+Reset configurations with all access permission settings retained:
+
+::
+
+    => scmi reset 1 0
+
+Configuration
+-------------
+
+The scmi command is only available if CONFIG_CMD_SCMI=y.
+Default n because this command is mainly for debug purpose.
+
+Return value
+------------
+
+The return value ($?) is set to 0 if the operation succeeded,
+1 if the operation failed or -1 if the operation failed due to
+a syntax error.
+
+.. _`SCMI specification`: https://developer.arm.com/documentation/den0056/e/?lang=en
diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst
index a102be187bd..cd6bb141910 100644
--- a/doc/usage/fit/beaglebone_vboot.rst
+++ b/doc/usage/fit/beaglebone_vboot.rst
@@ -145,7 +145,7 @@ Put this into a file in that directory called sign.its::
                 load = <0x80008000>;
                 entry = <0x80008000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
             fdt-1 {
@@ -155,7 +155,7 @@ Put this into a file in that directory called sign.its::
                 arch = "arm";
                 compression = "none";
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
@@ -165,7 +165,7 @@ Put this into a file in that directory called sign.its::
                 kernel = "kernel";
                 fdt = "fdt-1";
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     key-name-hint = "dev";
                     sign-images = "fdt", "kernel";
                 };
@@ -227,8 +227,8 @@ You should see something like this::
       OS:           Linux
       Load Address: 0x80008000
       Entry Point:  0x80008000
-      Hash algo:    sha1
-      Hash value:   c94364646427e10f423837e559898ef02c97b988
+      Hash algo:    sha256
+      Hash value:   51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1
      Image 1 (fdt-1)
       Description:  beaglebone-black
       Created:      Sun Jun  1 12:50:30 2014
@@ -236,8 +236,8 @@ You should see something like this::
       Compression:  uncompressed
       Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
       Architecture: ARM
-      Hash algo:    sha1
-      Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+      Hash algo:    sha256
+      Hash value:   807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd
      Default Configuration: 'conf-1'
      Configuration 0 (conf-1)
       Description:  unavailable
@@ -255,11 +255,11 @@ You can also run fit_check_sign to check it::
 
 which results in::
 
-    Verifying Hash Integrity ... sha1,rsa2048:dev+
+    Verifying Hash Integrity ... sha256,rsa2048:dev+
     ## Loading kernel from FIT Image at 7fc6ee469000 ...
        Using 'conf-1' configuration
        Verifying Hash Integrity ...
-    sha1,rsa2048:dev+
+    sha256,rsa2048:dev+
     OK
 
        Trying 'kernel' kernel subimage
@@ -272,10 +272,10 @@ which results in::
          OS:           Linux
          Load Address: 0x80008000
          Entry Point:  0x80008000
-         Hash algo:    sha1
-         Hash value:   c94364646427e10f423837e559898ef02c97b988
+         Hash algo:    sha256
+         Hash value:   51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1
        Verifying Hash Integrity ...
-    sha1+
+    sha256+
     OK
 
     Unimplemented compression type 4
@@ -288,10 +288,10 @@ which results in::
          Compression:  uncompressed
          Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
          Architecture: ARM
-         Hash algo:    sha1
-         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+         Hash algo:    sha256
+         Hash value:   807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd
        Verifying Hash Integrity ...
-    sha1+
+    sha256+
     OK
 
        Loading Flat Device Tree ... OK
@@ -303,14 +303,14 @@ which results in::
     Signature check OK
 
 
-At the top, you see "sha1,rsa2048:dev+". This means that it checked an RSA key
-of size 2048 bits using SHA1 as the hash algorithm. The key name checked was
+At the top, you see "sha256,rsa2048:dev+". This means that it checked an RSA key
+of size 2048 bits using SHA256 as the hash algorithm. The key name checked was
 'dev' and the '+' means that it verified. If it showed '-' that would be bad.
 
 Once the configuration is verified it is then possible to rely on the hashes
 in each image referenced by that configuration. So fit_check_sign goes on to
 load each of the images. We have a kernel and an FDT but no ramkdisk. In each
-case fit_check_sign checks the hash and prints sha1+ meaning that the SHA1
+case fit_check_sign checks the hash and prints sha256+ meaning that the SHA256
 hash verified. This means that none of the images has been tampered with.
 
 There is a test in test/vboot which uses U-Boot's sandbox build to verify that
@@ -328,11 +328,11 @@ This tells us that the kernel starts at byte offset 168 (decimal) in image.fit
 and extends for about 7MB. Try changing a byte at 0x2000 (say) and run
 fit_check_sign again. You should see something like::
 
-    Verifying Hash Integrity ... sha1,rsa2048:dev+
+    Verifying Hash Integrity ... sha256,rsa2048:dev+
     ## Loading kernel from FIT Image at 7f5a39571000 ...
        Using 'conf-1' configuration
        Verifying Hash Integrity ...
-    sha1,rsa2048:dev+
+    sha256,rsa2048:dev+
     OK
 
        Trying 'kernel' kernel subimage
@@ -345,10 +345,10 @@ fit_check_sign again. You should see something like::
          OS:           Linux
          Load Address: 0x80008000
          Entry Point:  0x80008000
-         Hash algo:    sha1
-         Hash value:   c94364646427e10f423837e559898ef02c97b988
+         Hash algo:    sha256
+         Hash value:   51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1
        Verifying Hash Integrity ...
-    sha1 error
+    sha256 error
     Bad hash value for 'hash-1' hash node in 'kernel' image node
     Bad Data Hash
 
@@ -361,10 +361,10 @@ fit_check_sign again. You should see something like::
          Compression:  uncompressed
          Data Size:    31547 Bytes = 30.81 kB = 0.03 MB
          Architecture: ARM
-         Hash algo:    sha1
-         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
+         Hash algo:    sha256
+         Hash value:   807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd
        Verifying Hash Integrity ...
-    sha1+
+    sha256+
     OK
 
        Loading Flat Device Tree ... OK
@@ -419,13 +419,13 @@ need to change the hash to match. Let's simulate that by changing a byte of
 the hash::
 
     fdtget -tx image.fit /images/kernel/hash-1 value
-    c9436464 6427e10f 423837e5 59898ef0 2c97b988
-    fdtput -tx image.fit /images/kernel/hash-1 value c9436464 6427e10f 423837e5 59898ef0 2c97b981
+    51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c1
+    fdtput -tx image.fit /images/kernel/hash-1 value 51b2adf9 c1016ed4 6f424d85 dcc6c34c 46a20b9b ee7227e0 6a6b6320 ca5d35c8
 
 Now check it again::
 
     $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
-    Verifying Hash Integrity ... sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+    Verifying Hash Integrity ... sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
     rsa_verify_with_keynode: RSA failed to verify: -13
     -
     Failed to verify required signature 'key-dev'
@@ -446,7 +446,7 @@ running the mkimage link again. Then::
     fdtput -p image.fit /configurations/conf-1/signature-1 value fred
     $UOUT/tools/fit_check_sign -f image.fit -k am335x-boneblack-pubkey.dtb
     Verifying Hash Integrity ... -
-    sha1,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
+    sha256,rsa2048:devrsa_verify_with_keynode: RSA failed to verify: -13
     rsa_verify_with_keynode: RSA failed to verify: -13
     -
     Failed to verify required signature 'key-dev'
@@ -528,7 +528,7 @@ You should then see something like this::
     U-Boot# bootm 82000000
     ## Loading kernel from FIT Image at 82000000 ...
        Using 'conf-1' configuration
-       Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
+       Verifying Hash Integrity ... sha256,rsa2048:dev+ OK
        Trying 'kernel' kernel subimage
          Description:  unavailable
          Created:      2014-06-01  19:32:54 UTC
@@ -540,9 +540,9 @@ You should then see something like this::
          OS:           Linux
          Load Address: 0x80008000
          Entry Point:  0x80008000
-         Hash algo:    sha1
-         Hash value:   c94364646427e10f423837e559898ef02c97b988
-       Verifying Hash Integrity ... sha1+ OK
+         Hash algo:    sha256
+         Hash value:   51b2adf9c1016ed46f424d85dcc6c34c46a20b9bee7227e06a6b6320ca5d35c1
+       Verifying Hash Integrity ... sha256+ OK
     ## Loading fdt from FIT Image at 82000000 ...
        Using 'conf-1' configuration
        Trying 'fdt-1' fdt subimage
@@ -553,9 +553,9 @@ You should then see something like this::
          Data Start:   0x8276e2ec
          Data Size:    31547 Bytes = 30.8 KiB
          Architecture: ARM
-         Hash algo:    sha1
-         Hash value:   cb09202f889d824f23b8e4404b781be5ad38a68d
-       Verifying Hash Integrity ... sha1+ OK
+         Hash algo:    sha256
+         Hash value:   807d5842a04132261ba092373bd40c78991bc7ce173d1175cd976ec37858e7cd
+       Verifying Hash Integrity ... sha256+ OK
        Booting using the fdt blob at 0x8276e2ec
        Uncompressing Kernel Image ... OK
        Loading Device Tree to 8fff5000, end 8ffffb3a ... OK
diff --git a/doc/usage/fit/howto.rst b/doc/usage/fit/howto.rst
index def12a70f7b..b5097d4460b 100644
--- a/doc/usage/fit/howto.rst
+++ b/doc/usage/fit/howto.rst
@@ -8,7 +8,7 @@ Overview
 
 The new uImage format allows more flexibility in handling images of various
 types (kernel, ramdisk, etc.), it also enhances integrity protection of images
-with sha1 and md5 checksums.
+with cryptographic checksums.
 
 Two auxiliary tools are needed on the development host system in order to
 create an uImage in the new format: mkimage and dtc, although only one
@@ -99,7 +99,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
                 load = <0x8 0x8000000>;
                 entry = <0x8 0x8000000>;
                 hash {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
             atf {
@@ -112,7 +112,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
                 load = <0xfffea000>;
                 entry = <0xfffea000>;
                 hash {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
             fdt_1 {
@@ -123,7 +123,7 @@ started by ATF where SPL is loading U-Boot (as loadables) and ATF (as firmware).
                 compression = "none";
                 load = <0x100000>;
                 hash {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
         };
@@ -190,8 +190,8 @@ its contents:
       Entry Point:    0x00000000
       Hash algo:    crc32
       Hash value:    2ae2bb40
-      Hash algo:    sha1
-      Hash value:    3c200f34e2c226ddc789240cca0c59fc54a67cf4
+      Hash algo:    sha256
+      Hash value:    c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f
      Default Configuration: 'config-1'
      Configuration 0 (config-1)
       Description:    Boot Linux kernel
@@ -236,8 +236,8 @@ specific to the new image format).
          Entry Point:  0x00000000
          Hash algo:    crc32
          Hash value:   2ae2bb40
-         Hash algo:    sha1
-         Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+         Hash algo:    sha256
+         Hash value:   c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f
         Default Configuration: 'config-1'
         Configuration 0 (config-1)
          Description:  Boot Linux kernel
@@ -258,8 +258,8 @@ specific to the new image format).
          Entry Point:  0x00000000
          Hash algo:    crc32
          Hash value:   2ae2bb40
-         Hash algo:    sha1
-         Hash value:   3c200f34e2c226ddc789240cca0c59fc54a67cf4
+         Hash algo:    sha256
+         Hash value:   c22f6bb5a3f96942507a37e7d6a9333ebdc7da57971bc4c082113fe082fdc40f
        Verifying Hash Integrity ... crc32+ sha1+ OK
        Uncompressing Kernel Image ... OK
     Memory BAT mapping: BAT2=256Mb, BAT3=0Mb, residual: 0Mb
@@ -302,8 +302,8 @@ modified to take the files from some other location if needed):
       Entry Point:    0x00000000
       Hash algo:    crc32
       Hash value:    2c0cc807
-      Hash algo:    sha1
-      Hash value:    264b59935470e42c418744f83935d44cdf59a3bb
+      Hash algo:    sha256
+      Hash value:    a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c
      Image 1 (fdt-1)
       Description:    Flattened Device Tree blob
       Type:        Flat Device Tree
@@ -312,8 +312,8 @@ modified to take the files from some other location if needed):
       Architecture: PowerPC
       Hash algo:    crc32
       Hash value:    0d655d71
-      Hash algo:    sha1
-      Hash value:    25ab4e15cd4b8a5144610394560d9c318ce52def
+      Hash algo:    sha256
+      Hash value:    e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214
      Default Configuration: 'conf-1'
      Configuration 0 (conf-1)
       Description:    Boot Linux kernel with FDT blob
@@ -353,8 +353,8 @@ inspected and booted:
          Entry Point:  0x00000000
          Hash algo:    crc32
          Hash value:   2c0cc807
-         Hash algo:    sha1
-         Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+         Hash algo:    sha256
+         Hash value:   a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c
         Image 1 (fdt-1)
          Description:  Flattened Device Tree blob
          Type:       Flat Device Tree
@@ -364,8 +364,8 @@ inspected and booted:
          Architecture: PowerPC
          Hash algo:    crc32
          Hash value:   0d655d71
-         Hash algo:    sha1
-         Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+         Hash algo:    sha256
+         Hash value:   e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214
         Default Configuration: 'conf-1'
         Configuration 0 (conf-1)
          Description:  Boot Linux kernel with FDT blob
@@ -387,7 +387,7 @@ inspected and booted:
          Hash algo:    crc32
          Hash value:   2c0cc807
          Hash algo:    sha1
-         Hash value:   264b59935470e42c418744f83935d44cdf59a3bb
+         Hash value:   a3e9e18b793873827d27c97edfbca67c404a1972d9f36cf48e73ff85d69a422c
        Verifying Hash Integrity ... crc32+ sha1+ OK
        Uncompressing Kernel Image ... OK
     ## Flattened Device Tree from FIT Image at 00900000
@@ -402,7 +402,7 @@ inspected and booted:
          Hash algo:    crc32
          Hash value:   0d655d71
          Hash algo:    sha1
-         Hash value:   25ab4e15cd4b8a5144610394560d9c318ce52def
+         Hash value:   e9b9a40c5e2e12213ac819e7ccad7271ef43eb5edf9b421f0fa0b4b51bfdb214
        Verifying Hash Integrity ... crc32+ sha1+ OK
        Booting using the fdt blob at 0xa0abdc
        Loading Device Tree to 007fc000, end 007fffff ... OK
diff --git a/doc/usage/fit/kernel.rst b/doc/usage/fit/kernel.rst
index 012a81efead..e56017985b2 100644
--- a/doc/usage/fit/kernel.rst
+++ b/doc/usage/fit/kernel.rst
@@ -25,7 +25,7 @@ Single kernel
                     algo = "crc32";
                 };
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
@@ -59,7 +59,7 @@ For x86 a setup node is also required: see x86-fit-boot::
                 load = <0x01000000>;
                 entry = <0x00000000>;
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
 
@@ -73,7 +73,7 @@ For x86 a setup node is also required: see x86-fit-boot::
                 load = <0x00090000>;
                 entry = <0x00090000>;
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/kernel_fdt.rst b/doc/usage/fit/kernel_fdt.rst
index 8eee13af780..9cc26fb7831 100644
--- a/doc/usage/fit/kernel_fdt.rst
+++ b/doc/usage/fit/kernel_fdt.rst
@@ -25,7 +25,7 @@ Single kernel and FDT blob
 			algo = "crc32";
 		};
 		hash-2 {
-			algo = "sha1";
+			algo = "sha256";
 		};
 		};
 		fdt-1 {
@@ -38,7 +38,7 @@ Single kernel and FDT blob
 			algo = "crc32";
 		};
 		hash-2 {
-			algo = "sha1";
+			algo = "sha256";
 		};
 		};
 	};
diff --git a/doc/usage/fit/kernel_fdts_compressed.rst b/doc/usage/fit/kernel_fdts_compressed.rst
index 0b169c7c27c..b57871da58b 100644
--- a/doc/usage/fit/kernel_fdts_compressed.rst
+++ b/doc/usage/fit/kernel_fdts_compressed.rst
@@ -28,7 +28,7 @@ string to match directly.
                     algo = "crc32";
                 };
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
             fdt@1 {
@@ -41,7 +41,7 @@ string to match directly.
                     algo = "crc32";
                 };
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
             fdt@2 {
@@ -54,7 +54,7 @@ string to match directly.
                     algo = "crc32";
                 };
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/multi-with-fpga.rst b/doc/usage/fit/multi-with-fpga.rst
index 28d7d5d2626..4c7f1bebd5a 100644
--- a/doc/usage/fit/multi-with-fpga.rst
+++ b/doc/usage/fit/multi-with-fpga.rst
@@ -20,7 +20,7 @@ This example makes use of the 'loadables' field::
                 compression = "none";
                 load = <0x10000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -33,7 +33,7 @@ This example makes use of the 'loadables' field::
                 load = <0x30000000>;
                 compatible = "u-boot,fpga-legacy"
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -47,7 +47,7 @@ This example makes use of the 'loadables' field::
                 load = <0x8000>;
                 entry = <0x8000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/multi-with-loadables.rst b/doc/usage/fit/multi-with-loadables.rst
index a0241df96ca..7849cb544f1 100644
--- a/doc/usage/fit/multi-with-loadables.rst
+++ b/doc/usage/fit/multi-with-loadables.rst
@@ -22,7 +22,7 @@ This example makes use of the 'loadables' field::
                 load = <0xa0000000>;
                 entry = <0xa0000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -34,7 +34,7 @@ This example makes use of the 'loadables' field::
                 compression = "none";
                 load = <0xb0000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -46,7 +46,7 @@ This example makes use of the 'loadables' field::
                 compression = "none";
                 load = <0xb0400000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -60,7 +60,7 @@ This example makes use of the 'loadables' field::
                 load = <0xa0000000>;
                 entry = <0xa0000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/multi.rst b/doc/usage/fit/multi.rst
index 2e6ae58c409..e68752b2ad0 100644
--- a/doc/usage/fit/multi.rst
+++ b/doc/usage/fit/multi.rst
@@ -22,10 +22,10 @@ Multiple kernels, ramdisks and FDT blobs
                 load = <00000000>;
                 entry = <00000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
                 hash-2 {
-                    algo = "sha1";
+                    algo = "sha512";
                 };
             };
 
@@ -39,7 +39,7 @@ Multiple kernels, ramdisks and FDT blobs
                 load = <00000000>;
                 entry = <00000000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
 
@@ -53,7 +53,7 @@ Multiple kernels, ramdisks and FDT blobs
                 load = <00000000>;
                 entry = <00000000>;
                 hash-1 {
-                    algo = "md5";
+                    algo = "sha256";
                 };
             };
 
@@ -67,7 +67,7 @@ Multiple kernels, ramdisks and FDT blobs
                 load = <00000000>;
                 entry = <00000000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
 
@@ -104,7 +104,7 @@ Multiple kernels, ramdisks and FDT blobs
                 compression = "none";
                 load = <00700000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
 
diff --git a/doc/usage/fit/sign-configs.rst b/doc/usage/fit/sign-configs.rst
index 6a3df8f2c5b..6d98d44430c 100644
--- a/doc/usage/fit/sign-configs.rst
+++ b/doc/usage/fit/sign-configs.rst
@@ -22,7 +22,7 @@ Signed configurations
                 entry = <0x8>;
                 kernel-version = <1>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
             fdt-1 {
@@ -33,7 +33,7 @@ Signed configurations
                 compression = "none";
                 fdt-version = <1>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
@@ -43,7 +43,7 @@ Signed configurations
                 kernel = "kernel";
                 fdt = "fdt-1";
                 signature {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     key-name-hint = "dev";
                     sign-images = "fdt", "kernel";
                 };
diff --git a/doc/usage/fit/sign-images.rst b/doc/usage/fit/sign-images.rst
index 7d54d702c97..ca7d10fab83 100644
--- a/doc/usage/fit/sign-images.rst
+++ b/doc/usage/fit/sign-images.rst
@@ -22,7 +22,7 @@ Signed Images
                 entry = <0x8>;
                 kernel-version = <1>;
                 signature {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     key-name-hint = "dev";
                 };
             };
@@ -34,7 +34,7 @@ Signed Images
                 compression = "none";
                 fdt-version = <1>;
                 signature {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     key-name-hint = "dev";
                 };
             };
diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst
index 0804bffd1ed..03a71b5192d 100644
--- a/doc/usage/fit/signature.rst
+++ b/doc/usage/fit/signature.rst
@@ -93,7 +93,7 @@ Public keys should be stored as sub-nodes in a /signature node. Required
 properties are:
 
 algo
-    Algorithm name (e.g. "sha1,rsa2048" or "sha256,ecdsa256")
+    Algorithm name (e.g. "sha256,rsa2048" or "sha512,ecdsa256")
 
 Optional properties are:
 
@@ -219,28 +219,28 @@ As an example, consider this FIT::
             kernel-1 {
                 data = <data for kernel1>
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...kernel signature 1...>
                 };
             };
             kernel-2 {
                 data = <data for kernel2>
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...kernel signature 2...>
                 };
             };
             fdt-1 {
                 data = <data for fdt1>;
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...fdt signature 1...>
                 };
             };
             fdt-2 {
                 data = <data for fdt2>;
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...fdt signature 2...>
                 };
             };
@@ -291,28 +291,28 @@ So the above example is adjusted to look like this::
             kernel-1 {
                 data = <data for kernel1>
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                     value = <...kernel hash 1...>
                 };
             };
             kernel-2 {
                 data = <data for kernel2>
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                     value = <...kernel hash 2...>
                 };
             };
             fdt-1 {
                 data = <data for fdt1>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                     value = <...fdt hash 1...>
                 };
             };
             fdt-2 {
                 data = <data for fdt2>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                     value = <...fdt hash 2...>
                 };
             };
@@ -323,7 +323,7 @@ So the above example is adjusted to look like this::
                 kernel = "kernel-1";
                 fdt = "fdt-1";
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...conf 1 signature...>;
                 };
             };
@@ -331,7 +331,7 @@ So the above example is adjusted to look like this::
                 kernel = "kernel-2";
                 fdt = "fdt-2";
                 signature-1 {
-                    algo = "sha1,rsa2048";
+                    algo = "sha256,rsa2048";
                     value = <...conf 1 signature...>;
                 };
             };
@@ -671,7 +671,7 @@ Create the fitImage::
 Sign the fitImage with the hardware key::
 
     $ ./tools/mkimage -F -k \
-    "model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29" \
+    "pkcs11:model=PKCS%2315%20emulated;manufacturer=ZeitControl;serial=000xxxxxxxxx;token=OpenPGP%20card%20%28User%20PIN%20%28sig%29%29" \
     -K u-boot.dtb -N pkcs11 -r fitImage
 
 
diff --git a/doc/usage/fit/update3.rst b/doc/usage/fit/update3.rst
index 4ff3950c01e..24235801470 100644
--- a/doc/usage/fit/update3.rst
+++ b/doc/usage/fit/update3.rst
@@ -19,7 +19,7 @@ Automatic software update: multiple files
                 type = "firmware";
                 load = <FF700000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
             update-2 {
@@ -29,7 +29,7 @@ Automatic software update: multiple files
                 type = "firmware";
                 load = <FF8E0000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
 
@@ -40,7 +40,7 @@ Automatic software update: multiple files
                 type = "firmware";
                 load = <FFAC0000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/update_uboot.rst b/doc/usage/fit/update_uboot.rst
index a9288ee6367..811d008d13d 100644
--- a/doc/usage/fit/update_uboot.rst
+++ b/doc/usage/fit/update_uboot.rst
@@ -21,7 +21,7 @@ Make sure the flashing addresses ('load' prop) is correct for your board!
                 type = "firmware";
                 load = <0xFFFC0000>;
                 hash-1 {
-                    algo = "sha1";
+                    algo = "sha256";
                 };
             };
         };
diff --git a/doc/usage/fit/x86-fit-boot.rst b/doc/usage/fit/x86-fit-boot.rst
index 93b73bb9019..9e3e32204d5 100644
--- a/doc/usage/fit/x86-fit-boot.rst
+++ b/doc/usage/fit/x86-fit-boot.rst
@@ -207,16 +207,16 @@ You can take a look at the resulting fit file if you like::
       OS:           Linux
       Load Address: 0x01000000
       Entry Point:  0x00000000
-      Hash algo:    sha1
-      Hash value:   446b5163ebfe0fb6ee20cbb7a8501b263cd92392
+      Hash algo:    sha256
+      Hash value:   4bbf49981ade163ed089f8525236fedfe44508e9b02a21a48294a96a1518107b
      Image 1 (setup)
       Description:  Linux setup.bin
       Created:      Tue Oct  7 10:57:24 2014
       Type:         x86 setup.bin
       Compression:  uncompressed
       Data Size:    12912 Bytes = 12.61 kB = 0.01 MB
-      Hash algo:    sha1
-      Hash value:   a1f2099cf47ff9816236cd534c77af86e713faad
+      Hash algo:    sha256
+      Hash value:   6aa50c2e0392cb119cdf0971dce8339f100608ed3757c8200b0e39e889e432d2
      Default Configuration: 'config-1'
      Configuration 0 (config-1)
       Description:  Boot Linux kernel
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index d8e23fcacff..c171c029b80 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -43,6 +43,7 @@ Shell commands
    cmd/cat
    cmd/cbsysinfo
    cmd/cedit
+   cmd/cli
    cmd/cls
    cmd/cmp
    cmd/coninfo
@@ -94,6 +95,7 @@ Shell commands
    cmd/rng
    cmd/saves
    cmd/sbi
+   cmd/scmi
    cmd/scp03
    cmd/seama
    cmd/setexpr