diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/board/qualcomm/debugging.rst | 2 | ||||
| -rw-r--r-- | doc/board/qualcomm/phones.rst | 2 | ||||
| -rw-r--r-- | doc/board/qualcomm/rb3gen2.rst | 2 | ||||
| -rw-r--r-- | doc/board/ti/j784s4_evm.rst | 9 | ||||
| -rw-r--r-- | doc/develop/release_cycle.rst | 6 | ||||
| -rw-r--r-- | doc/develop/uefi/u-boot_on_efi.rst | 18 | ||||
| -rw-r--r-- | doc/usage/fit/signature.rst | 8 |
7 files changed, 27 insertions, 20 deletions
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/release_cycle.rst b/doc/develop/release_cycle.rst index f2ffcf3d331..7aa36166a5d 100644 --- a/doc/develop/release_cycle.rst +++ b/doc/develop/release_cycle.rst @@ -55,7 +55,7 @@ Current Status * U-Boot v2025.07 was released on Monday, 07 July 2025. -* The Merge Window for the next release (|next_ver|) is **open** until the -rc1 +* The Merge Window for the next release (|next_ver|) is **closed** with the -rc1 release on Monday, 28 July 2025. * The next branch is now **closed** until the -rc2 release on Monday, 11 August @@ -69,9 +69,9 @@ Future Releases .. The following commented out dates are for when release candidates are planned to be tagged. -.. For the next scheduled release, release candidates were made on:: +For the next scheduled release, release candidates were made on:: -.. * U-Boot |next_ver|-rc1 was released on Mon 28 July 2025. +* U-Boot |next_ver|-rc1 was released on Mon 28 July 2025. .. * U-Boot |next_ver|-rc2 was released on Mon 11 August 2025. 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 |