6 files changed, 171 insertions, 25 deletions
diff --git a/doc/board/nxp/imx93_frdm.rst b/doc/board/nxp/imx93_frdm.rst
new file mode 100644
index 00000000000..a1f526fd4cc
--- /dev/null
+++ b/doc/board/nxp/imx93_frdm.rst
@@ -0,0 +1,75 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+imx93_frdm
+==========
+
+U-Boot for the NXP i.MX93 FRDM board
+
+Quick Start
+-----------
+
+- Get and Build the ARM Trusted firmware
+- Get the DDR firmware
+- Get ahab-container.img
+- Build U-Boot
+- Boot from the SD card
+
+Get and Build the ARM Trusted firmware
+--------------------------------------
+
+Note: srctree is U-Boot source directory
+Get ATF from: https://github.com/nxp-imx/imx-atf/
+branch: lf_v2.8
+
+.. code-block:: bash
+
+   $ unset LDFLAGS
+   $ make PLAT=imx93 bl31
+   $ cp build/imx93/release/bl31.bin $(srctree)
+
+Get the DDR firmware
+--------------------
+
+.. code-block:: bash
+
+   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.21.bin
+   $ chmod +x firmware-imx-8.21.bin
+   $ ./firmware-imx-8.21.bin
+   $ cp firmware-imx-8.21/firmware/ddr/synopsys/lpddr4*.bin $(srctree)
+
+Get ahab-container.img
+----------------------
+
+.. code-block:: bash
+
+   $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin
+   $ chmod +x firmware-sentinel-0.11.bin
+   $ ./firmware-sentinel-0.11.bin
+   $ cp firmware-sentinel-0.11/mx93a1-ahab-container.img $(srctree)
+
+Build U-Boot
+------------
+
+.. code-block:: bash
+
+   $ export CROSS_COMPILE=aarch64-poky-linux-
+   $ make imx93_frdm_defconfig
+   $ make
+
+Copy the flash.bin binary to the MicroSD card at offset 32KB:
+
+.. code-block:: bash
+
+   $ dd if=flash.bin of=/dev/sd[x] bs=1k seek=32; sync
+
+Boot from the SD card
+---------------------
+
+- Configure SW1 boot switches to SD boot mode:
+  0011 SW1[3:0] - ("USDHC2 4-bit SD3.0" Boot Mode)
+- Insert the SD card in the SD slot (P13) of the board.
+- Connect a USB Type-C cable into the P16 Debug USB Port and connect
+  using a terminal emulator at 115200 bps, 8n1. The console will show up
+  at /dev/ttyACM0.
+- Power on the board by connecting a USB Type-C cable into the P1
+  Power USB Port.
diff --git a/doc/board/nxp/index.rst b/doc/board/nxp/index.rst
index e7ec725cc04..aa7d857346d 100644
--- a/doc/board/nxp/index.rst
+++ b/doc/board/nxp/index.rst
@@ -15,6 +15,7 @@ NXP Semiconductors
    imx91_11x11_evk
    imx93_9x9_qsb
    imx93_11x11_evk
+   imx93_frdm
    imx95_evk
    imxrt1020-evk
    imxrt1050-evk
diff --git a/doc/board/samsung/e850-96.rst b/doc/board/samsung/e850-96.rst
index 0a7b6fc0c9d..b435fa8b353 100644
--- a/doc/board/samsung/e850-96.rst
+++ b/doc/board/samsung/e850-96.rst
@@ -43,17 +43,19 @@ Legend:
   BL31 in terms of ARM boot flow
 * ``LDFW``: Loadable Firmware
 
-Build Procedure
+Unbricking Note
 ---------------
 
-.. warning::
-  At the moment USB is not enabled in U-Boot for this board. Although eMMC is
-  enabled, you won't be able to flash images over USB (fastboot). So flashing
-  U-Boot binary **WILL** effectively brick your board. The ``dltool`` [8]_ can
-  be used then to perform USB boot and flash LittleKernel bootloader binary [7]_
-  to unbrick and revive the board. Flashing U-Boot binary might be helpful for
-  developers or anybody who want to check current state of U-Boot enablement on
-  E850-96 (which is mostly serial console, eMMC and related blocks).
+In case the board is bricked for some reason, the ``dltool`` [8]_ can be used to
+unbrick and revive it. This tool performs USB boot, and uploads the LittleKernel
+bootloader over USB, which is then being executed on the board. The loaded
+bootloader further enters fastboot mode, so that the user can flash the
+functional bootloader binary (U-Boot or LittleKernel [7]_) to eMMC using
+``fastboot`` tool. Please read the ``dltool`` README file for more details about
+the procedure.
+
+Build Procedure
+---------------
 
 Build U-Boot binary from source code (using AArch64 baremetal GCC toolchain):
 
@@ -64,8 +66,9 @@ Build U-Boot binary from source code (using AArch64 baremetal GCC toolchain):
   make e850-96_defconfig
   make
 
-Boot E850-96 board into fastboot mode as described in board software doc [9]_,
-and flash U-Boot binary into ``bootloader`` eMMC partition:
+The original E850-96 board is shipped with LittleKernel-based bootloader flashed
+in eMMC. To replace it with U-Boot, boot into fastboot mode (as described in
+the board software documentation [9]_), and flash U-Boot binary:
 
 .. prompt:: bash $
 
@@ -74,6 +77,66 @@ and flash U-Boot binary into ``bootloader`` eMMC partition:
 
 U-Boot will boot up to the shell.
 
+Flashing
+--------
+
+User area of eMMC contains GPT partition table (either Linux or Android). Boot
+Partition A (``mmc0boot0``) contains all firmware/bootloaders. Boot Partition
+B (``mmc0boot1``) contains U-Boot environment.
+
+First make sure to format eMMC accordingly. Prepare the initial environment:
+
+.. prompt:: bash =>
+
+  env default -f -a
+  env save
+
+For Linux, just format eMMC using default ``$partitions`` definitions:
+
+.. prompt:: bash =>
+
+  gpt write mmc 0 $partitions
+
+For Android, use ``$partitions_android`` instead:
+
+.. prompt:: bash =>
+
+  setenv partitions_linux $partitions
+  setenv partitions $partitions_android
+  env save
+  gpt write mmc 0 $partitions
+
+In case of Linux, there are two partitions available: ``esp`` (EFI System
+Partition) and ``rootfs``. It is recommended to use fastboot to flash images to
+those partitions. Enter fastboot mode on your device:
+
+.. prompt:: bash =>
+
+  fastboot usb 0
+
+And then flash the images:
+
+.. prompt:: bash $
+
+  fastboot flash esp esp.img
+  fastboot flash rootfs rootfs.img
+
+To update the firmware, it's easier to use DFU. Enter DFU mode on the board:
+
+.. prompt:: bash =>
+
+  dfu 0 mmc 0
+
+To update U-Boot:
+
+.. prompt:: bash $
+
+  dfu-util -D u-boot.bin -a bootloader
+
+It's also possible to use fastboot to flash the whole ``mmc0boot0`` HW
+partition, but it's not so straightforward, as one have to prepare the image for
+the whole ``boot0`` partition containing all firmware binaries first.
+
 References
 ----------
 
diff --git a/doc/board/ti/j784s4_evm.rst b/doc/board/ti/j784s4_evm.rst
index 349fb394d74..22442874110 100644
--- a/doc/board/ti/j784s4_evm.rst
+++ b/doc/board/ti/j784s4_evm.rst
@@ -90,6 +90,15 @@ Set the variables corresponding to this platform:
    export OPTEE_PLATFORM=k3-j784s4
    export OPTEE_EXTRA_ARGS="CFG_CONSOLE_UART=0x8"
 
+.. note::
+
+   For AM69-SK, use the following U_BOOT_CFG instead:
+
+   .. prompt:: bash
+
+      export UBOOT_CFG_CORTEXR=am69_sk_r5_defconfig
+      export UBOOT_CFG_CORTEXA=am69_sk_a72_defconfig
+
 .. j784s4_evm_rst_include_start_build_steps
 
 1. Trusted Firmware-A
diff --git a/doc/develop/uefi/u-boot_on_efi.rst b/doc/develop/uefi/u-boot_on_efi.rst
index 245b4af1fa3..177e887ebd9 100644
--- a/doc/develop/uefi/u-boot_on_efi.rst
+++ b/doc/develop/uefi/u-boot_on_efi.rst
@@ -45,15 +45,15 @@ First choose a board that has EFI support and obtain an EFI implementation
 for that board. It will be either 32-bit or 64-bit. Alternatively, you can
 opt for using QEMU [1] and the OVMF [2], as detailed below.
 
-To build U-Boot as an EFI application, enable CONFIG_EFI and CONFIG_EFI_APP.
-The efi-x86_app32 and efi-x86_app64 configs are set up for this. Just build
-U-Boot as normal, e.g.::
+To build U-Boot as an EFI application, enable CONFIG_EFI_CLIENT and
+CONFIG_EFI_APP. The efi-x86_app32 and efi-x86_app64 configs are set up for
+this. Just build U-Boot as normal, e.g.::
 
    make efi-x86_app32_defconfig
    make
 
 To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), enable
-CONFIG_EFI, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or
+CONFIG_EFI_CLIENT, CONFIG_EFI_STUB, and select either CONFIG_EFI_STUB_32BIT or
 CONFIG_EFI_STUB_64BIT. The efi-x86_payload configs (efi-x86_payload32_defconfig
 and efi-x86_payload32_defconfig) are set up for this. Then build U-Boot as
 normal, e.g.::
@@ -113,7 +113,7 @@ implemented completely differently.
 EFI Application
 ~~~~~~~~~~~~~~~
 For the application the whole of U-Boot is built as a shared library. The
-efi_main() function is in lib/efi/efi_app.c. It sets up some basic EFI
+efi_main() function is in lib/efi_client/efi_app.c. It sets up some basic EFI
 functions with efi_init(), sets up U-Boot global_data, allocates memory for
 U-Boot's malloc(), etc. and enters the normal init sequence (board_init_f()
 and board_init_r()).
@@ -121,7 +121,7 @@ and board_init_r()).
 Since U-Boot limits its memory access to the allocated regions very little
 special code is needed. The CONFIG_EFI_APP option controls a few things
 that need to change so 'git grep CONFIG_EFI_APP' may be instructive.
-The CONFIG_EFI option controls more general EFI adjustments.
+The CONFIG_EFI_CLIENT option controls more general EFI adjustments.
 
 The only available driver is the serial driver. This calls back into EFI
 'boot services' to send and receive characters. Although it is implemented
@@ -149,7 +149,7 @@ image (including device tree) into a small EFI stub application responsible
 for booting it. The stub application is built as a normal EFI application
 except that it has a lot of data attached to it.
 
-The stub application is implemented in lib/efi/efi_stub.c. The efi_main()
+The stub application is implemented in lib/efi_client/efi_stub.c. The efi_main()
 function is called by EFI. It is responsible for copying U-Boot from its
 original location into memory, disabling EFI boot services and starting
 U-Boot. U-Boot then starts as normal, relocates, starts all drivers, etc.
@@ -192,7 +192,7 @@ careful to build the correct one so that your UEFI firmware can start it. Most
 UEFI images are 64-bit at present.
 
 The payload stub can be build as either 32- or 64-bits. Only a small amount
-of code is built this way (see the extra- line in lib/efi/Makefile).
+of code is built this way (see the extra- line in lib/efi_client/Makefile).
 Everything else is built as a normal U-Boot, so is always 32-bit on x86 at
 present.
 
@@ -353,7 +353,7 @@ This work could be extended in a number of ways:
 
 Where is the code?
 ------------------
-lib/efi
+lib/efi_client
 	payload stub, application, support code. Mostly arch-neutral
 
 arch/x86/cpu/efi
diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst
index b868dcbf9fd..e5b5a8432e9 100644
--- a/doc/usage/fit/signature.rst
+++ b/doc/usage/fit/signature.rst
@@ -433,16 +433,14 @@ CONFIG_LEGACY_IMAGE_FORMAT
 Testing
 -------
 
-An easy way to test signing and verification is to use the test script
-provided in test/vboot/vboot_test.sh. This uses sandbox (a special version
+An easy way to test signing and verification is to use the vboot tests
+provided in the pytest suite. This uses sandbox (a special version
 of U-Boot which runs under Linux) to show the operation of a 'bootm'
 command loading and verifying images.
 
 A sample run is show below::
 
-    $ make O=sandbox sandbox_config
-    $ make O=sandbox
-    $ O=sandbox ./test/vboot/vboot_test.sh
+    $ ./test/py/test.py --bd sandbox --build -k vboot
 
 
 Simple Verified Boot Test