8 files changed, 100 insertions, 17 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/qualcomm/debugging.rst b/doc/board/qualcomm/debugging.rst
index 1c35d1909d1..c3289c9e4e3 100644
--- a/doc/board/qualcomm/debugging.rst
+++ b/doc/board/qualcomm/debugging.rst
@@ -1,5 +1,5 @@
 .. SPDX-License-Identifier: GPL-2.0+
-.. sectionauthor:: Caleb Connolly <caleb.connolly@linaro.org>
+.. sectionauthor:: Casey Connolly <casey.connolly@linaro.org>
 
 Qualcomm debugging
 ==================
diff --git a/doc/board/qualcomm/phones.rst b/doc/board/qualcomm/phones.rst
index 1d27196cf54..8afc7587731 100644
--- a/doc/board/qualcomm/phones.rst
+++ b/doc/board/qualcomm/phones.rst
@@ -1,5 +1,5 @@
 .. SPDX-License-Identifier: GPL-2.0+
-.. sectionauthor:: Caleb Connolly <caleb.connolly@linaro.org>
+.. sectionauthor:: Casey Connolly <casey.connolly@linaro.org>
 
 ======================================
 Booting U-Boot on Qualcomm smartphones
diff --git a/doc/board/qualcomm/rb3gen2.rst b/doc/board/qualcomm/rb3gen2.rst
index 4240606224f..518d01c4c3a 100644
--- a/doc/board/qualcomm/rb3gen2.rst
+++ b/doc/board/qualcomm/rb3gen2.rst
@@ -1,5 +1,5 @@
 .. SPDX-License-Identifier: GPL-2.0+
-.. sectionauthor:: Caleb Connolly <caleb.connolly@linaro.org>
+.. sectionauthor:: Casey Connolly <casey.connolly@linaro.org>
 
 Qualcomm Robotics RB3 Gen 2
 ===========================
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