Merge tag 'v2024.07-rc5' into next

Prepare v2024.07-rc5

14 files changed, 153 insertions, 46 deletions

diff --git a/doc/board/phytec/phycore-am62x.rst b/doc/board/phytec/phycore-am62x.rst
index a615d01474e..ce7ec5545a6 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -159,4 +159,4 @@ Further Information
 -------------------
 
 Please see :doc:`../ti/am62x_sk` chapter for further AM62 SoC related documentation
-and https://docs.phytec.com/phycore-am62x for vendor documentation.
+and https://docs.phytec.com/projects/yocto-phycore-am62x/en/latest/ for vendor documentation.
diff --git a/doc/board/phytec/phycore-am64x.rst b/doc/board/phytec/phycore-am64x.rst
index 189da179534..2b9cd32c508 100644
--- a/doc/board/phytec/phycore-am64x.rst
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -9,7 +9,7 @@ SoM (System on Module) featuring TI's AM64x SoC. It can be used in combination
 with different carrier boards. This module can come with different sizes and
 models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM64x family.
 
-A development Kit, called `phyBOARD-Lyra <https://www.phytec.com/product/phyboard-am64x>`_
+A development Kit, called `phyBOARD-Electra <https://www.phytec.com/product/phyboard-am64x>`_
 is used as a carrier board reference design around the AM64x SoM.
 
 Quickstart
@@ -156,4 +156,4 @@ Further Information
 -------------------
 
 Please see :doc:`../ti/am64x_evm` chapter for further AM64 SoC related documentation
-and https://docs.phytec.com/phycore-am64x for vendor documentation.
+and https://docs.phytec.com/projects/yocto-phycore-am64x/en/latest/ for vendor documentation.
diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index 76375473185..67b066a07d3 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -204,6 +204,11 @@ online
 Build Procedure
 ---------------
 
+.. note ::
+
+   Make sure you have installed all necessary host package dependencies
+   before proceeding. See :ref:`build/gcc:Building with GCC`.
+
 Depending on the specifics of your device, you will need three or more
 binaries to boot your SoC.
 
@@ -388,6 +393,30 @@ 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
 
+Capsules
+--------
+
+Most K3 boards have support for UEFI capsule update via capsule-on-disk
+functionality. Check the ``CONFIG_EFI_CAPSULE_ON_DISK`` config option for
+the board under question to verify. If configured, capsules for each of the
+binaries above are automatically generated as part of the binary's build.
+They are named `<binary>-capsule.bin`. For example, the capsule for
+`u-boot.img` would be called `uboot-capsule.bin`.
+
+See :ref:`uefi_capsule_update_ref` for more information on U-Boot's support
+for capsule update and how they are applied.
+
+Each board defines the capsules generated, including where those capsules
+are applied. See the ``update_info`` definition for a board, typically
+found at `board/ti/<board>/evm.c`. For example, `board/ti/am62x/evm.c`.
+Usually, if the board has OSPI flash, the capsules will be applied there,
+else the boot partition of the eMMC device.
+
+Once applied, the board will have U-Boot binaries in on-board non-volatile
+storage. To start booting from that storage, set the bootmode pins
+accordingly. Future updates can be performed by using the capsules
+generated from the corresponding U-Boot builds.
+
 FIT signature signing
 ---------------------
 
diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index 4cc1457d4ea..ca4fb0b5b10 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -113,9 +113,12 @@ SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=<vendor>/<name>` when
 prompted by Kconfig.
 
 However, if `dts/upstream/` hasn't yet received devicetree source file for your
-newly added board support then you can add corresponding devicetree source file
-as `arch/<arch>/dts/<name>.dts`. To select that add `# CONFIG_OF_UPSTREAM is not
-set` and set `DEFAULT_DEVICE_TREE=<name>` when prompted by Kconfig.
+newly added board support then one option is that you can add the corresponding
+devicetree source file as `arch/<arch>/dts/<name>.dts`. To select that add `#
+CONFIG_OF_UPSTREAM is not set` and set `DEFAULT_DEVICE_TREE=<name>` when
+prompted by Kconfig. Another option is that you can use use the "pick" option of
+`dts/update-dts-subtree.sh` mentioned above to bring in the commits that you
+need.
 
 This should include your CPU or SoC's devicetree file. On top of that any U-Boot
 specific tweaks (see: :ref:`dttweaks`) can be made for your board.
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 92477d05dd8..0542b3fc124 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -34,7 +34,7 @@ It is followed by a *Stabilization Period*.
 The end of a Release Cycle is marked by the release of a new U-Boot version.
 
 Merge Window
-------------
+^^^^^^^^^^^^
 
 The Merge Window is the period when new patches get submitted (and hopefully
 accepted) for inclusion into U-Boot mainline. This period lasts for 21 days (3
@@ -44,7 +44,7 @@ This is the only time when new code (like support for new processors or new
 boards, or other new features or reorganization of code) is accepted.
 
 Twilight Time
--------------
+^^^^^^^^^^^^^
 
 Usually patches do not get accepted as they are - the peer review that takes
 place will usually require changes and resubmissions of the patches before they
@@ -65,13 +65,13 @@ the Merge Window does not preclude patches that were already posted from being
 merged for the upcoming release.
 
 Stabilization Period
---------------------
+^^^^^^^^^^^^^^^^^^^^
 
 During the Stabilization Period only patches containing bug fixes get
 applied.
 
 Corner Cases
-------------
+^^^^^^^^^^^^
 
 Sometimes it is not clear if a patch contains a bug fix or not.
 For example, changes that remove dead code, unused macros etc. or
@@ -108,6 +108,19 @@ Differences to the Linux Development Process
   In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
   the) patches that were submitted during the merge window have been applied.
 
+Resyncing of the device tree subtree
+------------------------------------
+
+As explained in :doc:`devicetree/control` some platforms make use of device tree
+files which come from a git subtree that mirrors the Linux Kernel sources
+itself. For our purposes, we only track releases and not release candidates for
+merging in our tree. These merges follow the normal merge window rules.
+
+In the case of specific changes, such as bug fixes or new platform support,
+these can be "cherry-picked" and are subject to the normal merge rules. For
+example, a bug fix can come in later in the window but a full re-sync only
+happens within the merge window itself.
+
 .. _custodians:
 
 Custodians
diff --git a/doc/develop/release_cycle.rst b/doc/develop/release_cycle.rst
index c9fb07f59e1..b392346eea8 100644
--- a/doc/develop/release_cycle.rst
+++ b/doc/develop/release_cycle.rst
@@ -75,7 +75,7 @@ For the next scheduled release, release candidates were made on::
 
 * U-Boot v2024.07-rc4 was released on Mon 03 June 2024.
 
-.. * U-Boot v2024.07-rc5 was released on Mon 17 June 2024.
+* U-Boot v2024.07-rc5 was released on Mon 24 June 2024.
 
 Please note that the following dates are planned only and may be deviated from
 as needed.
diff --git a/doc/develop/testing.rst b/doc/develop/testing.rst
index 5afeb42f696..9114d11ad26 100644
--- a/doc/develop/testing.rst
+++ b/doc/develop/testing.rst
@@ -69,7 +69,7 @@ build::
 
    ./test/py/test.py --bd sandbox_spl --build -k test_spl
 
-See test/py/README.md for more information about the pytest suite.
+See :doc:`py_testing` for more information about the pytest suite.
 
 See :doc:`tests_sandbox` for how to run tests directly (not through pytest).
 
@@ -123,7 +123,7 @@ or is covered sparingly. So here are some suggestions:
   is much easier to add onto a test - writing a new large test can seem
   daunting to most contributors.
 
-See doc:`tests_writing` for how to write tests.
+See :doc:`tests_writing` for how to write tests.
 
 
 Future work
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 36ac75278fa..88596f312c0 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -72,7 +72,7 @@ bootm command. This feature is available if U-Boot is configured with::
 
     CONFIG_BOOTM_EFI=y
 
-A sample configuration is provided as file doc/uImage.FIT/uefi.its.
+A sample configuration is provided in :doc:`../../usage/fit/uefi`.
 
 Below you find the output of an example session starting GRUB::
 
@@ -96,7 +96,7 @@ Below you find the output of an example session starting GRUB::
     ## Transferring control to EFI (at address 404000d0) ...
     Welcome to GRUB!
 
-See doc/uImage.FIT/howto.txt for an introduction to FIT images.
+See :doc:`../../usage/fit/howto` for an introduction to FIT images.
 
 Configuring UEFI secure boot
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index 426f41e1a02..54eb70aa92c 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -9,7 +9,7 @@ Jinja2==3.1.4
 MarkupSafe==2.1.3
 packaging==23.2
 Pygments==2.17.2
-requests==2.31.0
+requests==2.32.2
 six==1.16.0
 snowballstemmer==2.2.0
 Sphinx==7.2.6
diff --git a/doc/usage/cmd/bootmeth.rst b/doc/usage/cmd/bootmeth.rst
index 2903977ee54..bac9fdf85cd 100644
--- a/doc/usage/cmd/bootmeth.rst
+++ b/doc/usage/cmd/bootmeth.rst
@@ -48,7 +48,7 @@ The format looks like this:
 =====  ===  ==================  =================================
 Order  Seq  Name                Description
 =====  ===  ==================  =================================
-    0    0  extlinunx           Extlinux boot from a block device
+    0    0  extlinux            Extlinux boot from a block device
     1    1  efi                 EFI boot from an .efi file
     2    2  pxe                 PXE boot from a network device
     3    3  sandbox             Sandbox boot for testing
diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst
index 03a71b5192d..b868dcbf9fd 100644
--- a/doc/usage/fit/signature.rst
+++ b/doc/usage/fit/signature.rst
@@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private
 key is kept secret and the public key is stored in a non-volatile place,
 any image can be verified in this way.
 
-See verified-boot.txt for more general information on verified boot.
+See :doc:`verified-boot` for more general information on verified boot.
 
 
 Concepts
diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst
index b2b1e42bd73..7727ab77c54 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -192,13 +192,13 @@ type
     invalid               Invalid Image
     aisimage              Davinci AIS image
     atmelimage            ATMEL ROM-Boot Image
-    copro                 Coprocessor Image}
+    copro                 Coprocessor Image
     fdt_legacy            legacy Image with Flat Device Tree
     filesystem            Filesystem Image
     firmware              Firmware
-    firmware_ivt          Firmware with HABv4 IVT }
+    firmware_ivt          Firmware with HABv4 IVT
     flat_dt               Flat Device Tree
-    fpga                  FPGA Image }
+    fpga                  FPGA Device Image (bitstream file, vendor specific)
     gpimage               TI Keystone SPL Image
     imx8image             NXP i.MX8 Boot Image
     imx8mimage            NXP i.MX8M Boot Image
@@ -207,31 +207,31 @@ type
     kernel_noload         Kernel Image (no loading done)
     kwbimage              Kirkwood Boot Image
     lpc32xximage          LPC32XX Boot Image
-    mtk_image             MediaTek BootROM loadable Image }
+    mtk_image             MediaTek BootROM loadable Image
     multi                 Multi-File Image
     mxsimage              Freescale MXS Boot Image
     omapimage             TI OMAP SPL With GP CH
     pblimage              Freescale PBL Boot Image
     pmmc                  TI Power Management Micro-Controller Firmware
     ramdisk               RAMDisk Image
-    rkimage               Rockchip Boot Image }
-    rksd                  Rockchip SD Boot Image }
-    rkspi                 Rockchip SPI Boot Image }
+    rkimage               Rockchip Boot Image
+    rksd                  Rockchip SD Boot Image
+    rkspi                 Rockchip SPI Boot Image
     script                Script
     socfpgaimage          Altera SoCFPGA CV/AV preloader
     socfpgaimage_v1       Altera SoCFPGA A10 preloader
-    spkgimage             Renesas SPKG Image }
+    spkgimage             Renesas SPKG Image
     standalone            Standalone Program
-    stm32image            STMicroelectronics STM32 Image }
-    sunxi_egon            Allwinner eGON Boot Image }
-    sunxi_toc0            Allwinner TOC0 Boot Image }
+    stm32image            STMicroelectronics STM32 Image
+    sunxi_egon            Allwinner eGON Boot Image
+    sunxi_toc0            Allwinner TOC0 Boot Image
     tee                   Trusted Execution Environment Image
     ublimage              Davinci UBL image
     vybridimage           Vybrid Boot Image
     x86_setup             x86 setup.bin
-    zynqimage             Xilinx Zynq Boot Image }
-    zynqmpbif             Xilinx ZynqMP Boot Image (bif) }
-    zynqmpimage           Xilinx ZynqMP Boot Image }
+    zynqimage             Xilinx Zynq Boot Image
+    zynqmpbif             Xilinx ZynqMP Boot Image (bif)
+    zynqmpimage           Xilinx ZynqMP Boot Image
     ====================  ==================
 
 compression
diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst
index 9691904a9d8..05c439e9ac6 100644
--- a/doc/usage/measured_boot.rst
+++ b/doc/usage/measured_boot.rst
@@ -7,19 +7,46 @@ U-Boot can perform a measured boot, the process of hashing various components
 of the boot process, extending the results in the TPM and logging the
 component's measurement in memory for the operating system to consume.
 
+The functionality is available when booting via the EFI subsystem or 'bootm'
+command.
+
+UEFI measured boot
+------------------
+
+The EFI subsystem implements the `EFI TCG protocol
+<https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/>`_
+and the `TCG PC Client Specific Platform Firmware Profile Specification
+<https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>`_
+which defines the binaries to be measured and the corresponding PCRs to be used.
+
+Requirements
+~~~~~~~~~~~~
+
+* A hardware TPM 2.0 supported by an enabled U-Boot driver
+* CONFIG_EFI_TCG2_PROTOCOL=y
+* CONFIG_EFI_TCG2_PROTOCOL_EVENTLOG_SIZE=y
+* optional CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB=y will measure the loaded DTB
+  in PCR 1
+
+Legacy measured boot
+--------------------
+
+The commands booti, bootm, and bootz can be used for measured boot
+using the legacy entry point of the Linux kernel.
+
 By default, U-Boot will measure the operating system (linux) image, the
 initrd image, and the "bootargs" environment variable. By enabling
-CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image.
+CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image in PCR1.
 
 The operating system typically would verify that the hashes found in the
 TPM PCRs match the contents of the event log. This can further be checked
 against the hash results of previous boots.
 
 Requirements
-------------
+~~~~~~~~~~~~
 
-* A hardware TPM 2.0 supported by the U-Boot drivers
-* CONFIG_TPM=y
+* A hardware TPM 2.0 supported by an enabled U-Boot driver
+* CONFIG_TPMv2=y
 * CONFIG_MEASURED_BOOT=y
 * Device-tree configuration of the TPM device to specify the memory area
   for event logging. The TPM device node must either contain a phandle to
diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst
index 2aa3b9ccc59..df27b78342f 100644
--- a/doc/usage/netconsole.rst
+++ b/doc/usage/netconsole.rst
@@ -3,10 +3,10 @@ Network console
 
 In U-Boot, we implemented the networked console via the standard
 "devices" mechanism, which means that you can switch between the
-serial and network input/output devices by adjusting the 'stdin' and
-'stdout' environment variables. To switch to the networked console,
-set either of these variables to "nc". Input and output can be
-switched independently.
+serial and network input/output devices by adjusting the 'stdin',
+'stdout', and 'stderr' environment variables. To switch to the
+networked console, set either of these variables to "nc". Input and
+output can be switched independently.
 
 The default buffer size can be overridden by setting
 CFG_NETCONSOLE_BUFFER_SIZE.
@@ -18,14 +18,18 @@ broadcast address and port 6666 are used. If it is set to an IP
 address of 0 (or 0.0.0.0) then no messages are sent to the network.
 The source / listening port can be configured separately by setting
 the 'ncinport' environment variable and the destination port can be
-configured by setting the 'ncoutport' environment variable.
+configured by setting the 'ncoutport' environment variable. Note that
+you need to set up the network interface (e.g. using DHCP) before it
+can be used for network console.
 
-For example, if your server IP is 192.168.1.1, you could use::
+For example, if your server IP is 192.168.1.1, you could use:
 
-	=> setenv nc 'setenv stdout nc;setenv stdin nc'
-	=> setenv ncip 192.168.1.1
-	=> saveenv
-	=> run nc
+.. prompt:: bash =>
+
+    env set nc 'env set stdout nc; env set stderr nc; env set stdin nc'
+    env set ncip '192.168.1.1'
+    env save
+    run nc
 
 On the host side, please use this script to access the console
 
@@ -107,3 +111,34 @@ as follows:
 
 Note that unlike the U-Boot implementation the Linux netconsole is
 unidirectional, i. e. you have console output only in Linux.
+
+Setup via environment
+---------------------
+
+If persistent environment is enabled in your U-Boot configuration, you
+can configure the network console using the environment. For example:
+
+.. prompt:: bash =>
+
+    env set autoload no
+    env set hostname "u-boot"
+    env set bootdelay 5
+    env set nc 'dhcp; env set stdout nc; env set stderr nc; env set stdin nc'
+    env set ncip '192.168.1.1'
+    env set preboot "${preboot}; run nc;"
+    env save
+    reset
+
+``autoload no`` tells the ``dhcp`` command to configure the network
+interface without trying to load an image. ``hostname "u-boot"`` sets
+the hostname to be sent in DHCP requests, so they are easy to
+recognize in the DHCP server log. The command in ``nc`` calls ``dhcp``
+to make sure the network interface is set up before enabling
+netconsole.
+
+Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole
+before trying to find any boot options, so you can interact with it if
+desired.
+
+``env save`` stores the settings persistently, and ``reset`` then
+triggers a fresh start that will use the changed settings.