From 21fd2a93cecf72ece30f23ccfd9df86e48ed6daf Mon Sep 17 00:00:00 2001 From: Jamie McCrae Date: Tue, 10 Dec 2024 10:50:02 +0000 Subject: [PATCH] doc: Remove documentation for child/parent image Removes documentation for this now removed feature Signed-off-by: Jamie McCrae --- doc/_utils/redirects.py | 10 - doc/_zoomin/ncs.tags.yml | 1 - .../mcuboot_nsib/bootloader.rst | 5 +- .../mcuboot_nsib/bootloader_adding.rst | 410 ------------------ .../mcuboot_nsib/bootloader_config.rst | 30 +- .../bootloader_dfu_image_versions.rst | 4 +- .../bootloader_downgrade_protection.rst | 4 +- .../mcuboot_nsib/bootloader_mcuboot_nsib.rst | 1 - .../mcuboot_nsib/bootloader_partitioning.rst | 1 - .../bootloader_signature_keys.rst | 5 +- doc/nrf/app_dev/companion_components.rst | 2 +- .../config_and_build_system.rst | 30 -- doc/nrf/app_dev/config_and_build/index.rst | 1 - .../app_dev/config_and_build/multi_image.rst | 407 ----------------- .../device_guides/nrf52/fota_update.rst | 8 +- .../device_guides/nrf53/building_nrf53.rst | 132 +++++- .../device_guides/nrf53/features_nrf53.rst | 8 +- doc/nrf/app_dev/device_guides/nrf53/index.rst | 1 - .../nrf53/multi_image_nrf5340.rst | 64 --- .../simultaneous_multi_image_dfu_nrf5340.rst | 3 +- .../nrf54h/ug_nrf54h20_configuration.rst | 1 - .../device_guides/nrf91/nrf91_features.rst | 3 +- .../thingy53/building_thingy53.rst | 2 +- doc/nrf/app_dev/device_guides/wifi_coex.rst | 1 - doc/nrf/includes/hci_ipc_overlay.txt | 4 - doc/nrf/libraries/dfu/pcd.rst | 3 +- .../matter/end_product/bootloader.rst | 4 +- .../migration/migration_guide_2.7.rst | 19 +- .../migration/migration_sysbuild.rst | 4 +- ...on_guide_2.4.99-cs3_to_2.7_application.rst | 2 +- ...on_guide_2.6.99-cs2_to_2.7_application.rst | 2 +- .../releases/release-notes-1.0.0.rst | 2 +- .../releases/release-notes-1.2.0.rst | 2 +- .../releases/release-notes-1.3.0.rst | 4 +- .../releases/release-notes-1.4.0.rst | 2 +- .../releases/release-notes-1.6.0.rst | 6 +- .../releases/release-notes-1.7.0.rst | 2 +- .../releases/release-notes-2.7.0.rst | 4 +- doc/nrf/security/tfm.rst | 3 +- doc/nrf/shortcuts.txt | 2 - .../optimizing/power_general.rst | 2 +- samples/bluetooth/central_hr_coded/README.rst | 2 - .../fast_pair/input_device/README.rst | 2 - .../iso_combined_bis_and_cis/README.rst | 3 - .../peripheral_hids_keyboard/README.rst | 2 - .../peripheral_hids_mouse/README.rst | 2 - .../bluetooth/peripheral_hr_coded/README.rst | 2 - samples/bluetooth/peripheral_mds/README.rst | 2 - .../peripheral_power_profiling/README.rst | 2 - samples/bluetooth/throughput/README.rst | 2 - samples/bootloader/README.rst | 9 +- 51 files changed, 188 insertions(+), 1041 deletions(-) delete mode 100644 doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding.rst delete mode 100644 doc/nrf/app_dev/config_and_build/multi_image.rst delete mode 100644 doc/nrf/app_dev/device_guides/nrf53/multi_image_nrf5340.rst delete mode 100644 doc/nrf/includes/hci_ipc_overlay.txt diff --git a/doc/_utils/redirects.py b/doc/_utils/redirects.py index 2c6a321af43d..906d28eed150 100644 --- a/doc/_utils/redirects.py +++ b/doc/_utils/redirects.py @@ -91,9 +91,6 @@ ("config_and_build/companion_components", "app_dev/companion_components"), # Using companion components ("config_and_build/output_build_files", "app_dev/config_and_build/output_build_files"), # Output build files (image files) ("config_and_build/configuring_app/output_build_files", "app_dev/config_and_build/output_build_files"), - ("ug_multi_image", "app_dev/config_and_build/multi_image"), # Multi-image build using child and parent images - ("app_dev/multi_image/index", "app_dev/config_and_build/multi_image"), - ("config_and_build/multi_image", "app_dev/config_and_build/multi_image"), ("ug_fw_update", "app_dev/bootloaders_dfu/index"), # Firmware updates (removed after 2.5.0) ("app_dev/bootloaders_and_dfu/fw_update", "app_dev/bootloaders_dfu/index"), ("config_and_build/bootloaders_and_dfu/fw_update", "app_dev/bootloaders_dfu/index"), @@ -104,7 +101,6 @@ ("config_and_build/bootloaders_and_dfu/index", "app_dev/bootloaders_dfu/index"), ("config_and_build/bootloaders_dfu/index", "app_dev/bootloaders_dfu/index"), ("config_and_build/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib"), # MCUboot and NSIB (landing) - ("ug_bootloader_testing", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib"), # Testing the bootloader chain (removed after 2.7.0) ("app_dev/bootloaders_and_dfu/bootloader_testing", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib"), ("config_and_build/bootloaders_and_dfu/bootloader_testing", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib"), ("config_and_build/bootloaders/bootloader_testing", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib"), @@ -112,11 +108,6 @@ ("config_and_build/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_quick_start"), ("config_and_build/bootloaders/bootloader_adding_sysbuild", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild"), # Enabling a bootloader chain using sysbuild ("config_and_build/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding_sysbuild"), - ("ug_bootloader_adding", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding"), # "Enabling a bootloader chain using child and parent images (deprecated)" - ("app_dev/bootloaders_and_dfu/bootloader_adding", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding"), - ("config_and_build/bootloaders_and_dfu/bootloader_adding", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding"), - ("config_and_build/bootloaders/bootloader_adding", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding"), - ("config_and_build/bootloaders_dfu/mcuboot_nsib/bootloader_adding", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding"), ("ug_bootloader", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader"), # Secure bootloader chain ("app_dev/bootloaders_and_dfu/bootloader", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader"), ("config_and_build/bootloaders_and_dfu/bootloader", "app_dev/bootloaders_dfu/mcuboot_nsib/bootloader"), @@ -222,7 +213,6 @@ ("device_guides/nrf53/features_nrf53", "app_dev/device_guides/nrf53/features_nrf53"), # Features of nRF53 Series ("device_guides/nrf53/building_nrf53", "app_dev/device_guides/nrf53/building_nrf53"), # Building and programming with nRF53 Series ("device_guides/nrf53/fota_update_nrf5340", "app_dev/device_guides/nrf53/fota_update_nrf5340"), # FOTA updates with nRF5340 DK - ("device_guides/nrf53/multi_image_nrf5340", "app_dev/device_guides/nrf53/multi_image_nrf5340"), # Multi-image builds on the nRF5340 DK using child and parent images ("device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340", "app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340"), # Simultaneous multi-image DFU with nRF5340 DK ("device_guides/nrf53/serial_recovery", "app_dev/device_guides/nrf53/serial_recovery"), # MCUboot’s serial recovery of the networking core image ("device_guides/nrf53/logging_nrf5340", "app_dev/device_guides/nrf53/logging_nrf5340"), # Getting logging output with nRF5340 DK diff --git a/doc/_zoomin/ncs.tags.yml b/doc/_zoomin/ncs.tags.yml index a3e934b56f04..8c23bb8ecc88 100644 --- a/doc/_zoomin/ncs.tags.yml +++ b/doc/_zoomin/ncs.tags.yml @@ -214,7 +214,6 @@ mapping_topics: - nrf/app_dev/device_guides/nrf53/building_nrf53.html: ["nrf5340", "development-kits", "nrf-connect-vsc"] - nrf/app_dev/device_guides/nrf53/fota_update_nrf5340.html: ["nrf5340", "development-kits"] - - nrf/app_dev/device_guides/nrf53/multi_image_nrf5340.html: ["nrf5340", "development-kits"] - nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.html: ["nrf5340", "development-kits"] - /nrf/app_dev/device_guides/nrf53/serial_recovery.html: ["nrf5340", "development-kits"] diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst index b0b017732953..0fd01fb4ce57 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader.rst @@ -67,8 +67,7 @@ The |NCS| currently supports two implementations: .. figure:: ../images/bootloader_memory_layout.svg :alt: Memory layout -By default, building an application with any bootloader configuration creates a :ref:`multi-image build `, where the :ref:`partition_manager` manages its memory partitions. -In this case, bootloaders are built as child images. +By default, building an application with any bootloader configuration used :ref:`sysbuild` to build multiple image, where the :ref:`partition_manager` manages its memory partitions. When building an application with :ref:`Cortex-M Security Extensions (CMSE) enabled `, then :ref:`Trusted Firmware-M (TF-M) ` is built with the image automatically. From the bootloader perspective, the TF-M is part of the booted application image. @@ -96,7 +95,7 @@ More specifically, the immutable bootloader always performs the following steps The next stage in the boot chain can either be an application or another bootloader. Firmware images have a version number, and the bootloader will select the slot with the latest firmware. - For more information about creating a second-stage bootloader, see :ref:`ug_bootloader_adding_upgradable`. + For more information about creating a second-stage bootloader, see :ref:`ug_bootloader_adding_sysbuild_upgradable`. #. Verification of the next stage in the boot chain. diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding.rst deleted file mode 100644 index 7d0f1dbc480d..000000000000 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_adding.rst +++ /dev/null @@ -1,410 +0,0 @@ -.. _ug_bootloader_adding: - -Enabling a bootloader chain using child and parent images (deprecated) -###################################################################### - -.. note:: - This feature is now deprecated. - See :ref:`ug_bootloader_adding_sysbuild`. - -.. contents:: - :local: - :depth: 2 - -You can add a bootloader chain to an application in the following ways: - -* Permanently: - - * Using Kconfig fragments. - * Using :file:`prj.conf` Kconfig project configuration files. - -* Temporarily (for a single build): - - * Using :ref:`one-time CMake arguments `. - * Using :ref:`zephyr:menuconfig`. - - -While you can use temporary configurations for quickly experimenting with different configurations from build to build, the recommended method is to implement your bootloader chain with permanent configurations. - -Both Kconfig fragments and Kconfig project configuration files use the same Kconfig syntax for configurations. -You can add bootloader chains to nearly any sample in |NCS| or Zephyr for rapid testing and experimentation. - -Choose the bootloader type depending on your application needs. -For detailed information about the bootloader support in the |NCS| and the general architecture, see :ref:`ug_bootloader`. - -.. _ug_bootloader_adding_immutable: - -Adding an immutable bootloader -****************************** - -The following sections describe how to add either |NSIB| or MCUboot as an immutable bootloader. - -.. _ug_bootloader_adding_immutable_b0: - -Adding |NSIB| as an immutable bootloader -======================================== - -To build |NSIB| with a Zephyr or |NCS| sample, enable the :kconfig:option:`CONFIG_SECURE_BOOT` in the application's :file:`prj.conf` file, in an associated Kconfig fragment, or using the command line: - -.. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- -DCONFIG_SECURE_BOOT=y - -|how_to_configure| - -Like other child images, :ref:`image-specific configurations ` can be assigned at build time to further customize the bootloader's functionality. - -To ensure that the immutable bootloader occupies as little flash memory as possible, you can also apply the :file:`prj_minimal.conf` configuration: - -.. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -Db0_CONF_FILE=prj_minimal.conf - -See :ref:`ug_bootloader_config` for more information about using Kconfig fragments. - -Configuring |NSIB| as an immutable bootloader ---------------------------------------------- - -The following sections describe different configuration options available for |NSIB| as an immutable bootloader. - -.. _ug_bootloader_adding_immutable_keys: - -Adding a custom signature key file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To add a signature key file to this bootloader, set the :kconfig:option:`CONFIG_SB_SIGNING_KEY_FILE` option in the application's :file:`prj.conf` file, in an associated Kconfig fragment, or using the command line: - -.. tabs:: - - .. group-tab:: Kconfig / prj.conf - - .. code-block:: console - - CONFIG_SB_SIGNING_KEY_FILE="priv.pem" - - .. group-tab:: Command line - - .. code-block:: console - - -DCONFIG_SB_SIGNING_KEY_FILE=\"priv.pem\" - - Escaped quotations avoid malformed-string warnings from Kconfig. - -This option only accepts the private key of an ECDSA key pair, as build system scripts automatically extract the public key at build time. - -The file argument must be a string and is specified in one of the following ways: - -* The relative path to the file from the application configuration directory (if this is not set, then it will be the same as the application source directory). - - * If the :file:`prj.conf` file is external to the directory, the key's location is determined relative to the application directory, not to the configuration file. - -* The absolute path to the file. - -For example, if a directory named :file:`_keys` located in :file:`/home/user/ncs` contains signing keys, you can provide the path in the following ways: - -.. tabs:: - - .. group-tab:: Kconfig / prj.conf - - .. code-block:: console - - CONFIG_SB_SIGNING_KEY_FILE="../../_keys/priv.pem" - - Or - - .. code-block:: console - - CONFIG_SB_SIGNING_KEY_FILE="/home/user/ncs/_keys/priv.pem" - - .. group-tab:: Command line - - .. code-block:: console - - -DCONFIG_SB_SIGNING_KEY_FILE=\"../../_keys/priv.pem\" - - Or - - .. code-block:: console - - -DCONFIG_SB_SIGNING_KEY_FILE=\"/home/user/ncs/_keys/priv.pem\" - - Or, if you set an environment variable named :envvar:`NCS` to :file:`/home/user/ncs`: - - .. code-block:: console - - -DCONFIG_SB_SIGNING_KEY_FILE=\"$NCS/_keys/priv.pem\" - -.. note:: - - The public key string must be an absolute path to the location of the public key file. - Environment variables (like :envvar:`$HOME`, :envvar:`$PWD`, or :envvar:`$USER`) and the ``~`` character on Unix systems are not expanded when setting an absolute path from a :file:`prj.conf` file or Kconfig fragment, but are expanded correctly in key file paths from the command line that are not given as strings. - -You can find specific configuration options for keys with this bootloader in :file:`nrf/subsys/bootloader/Kconfig`. - -See :ref:`ug_fw_update_keys` for information on how to generate custom keys for a project. - -Additionally, the |NSIB| supports the following methods for signing images with private keys: - -* :ref:`ug_fw_update_keys_openssl` - Uses the :kconfig:option:`CONFIG_SB_SIGNING_OPENSSL` Kconfig option. -* :ref:`Using a custom command ` - Uses the :kconfig:option:`CONFIG_SB_SIGNING_CUSTOM` Kconfig option. - -The OpenSSL method is handled internally by the build system, whereas using custom commands requires more configuration steps. - -Checking the public key -^^^^^^^^^^^^^^^^^^^^^^^ - -You can check that the bootloader image is correctly compiled with the custom signing key by comparing its auto-generated public key against a manual public key dump using OpenSSL. -You can do this with ``diff``, running the following command from a terminal: - -.. code-block:: console - - diff build/zephyr/nrf/subsys/bootloader/generated/public.pem <(openssl ec -in priv.pem -pubout) - -If there is no file diff output, then the private key has been successfully included in the bootloader image. - -.. _ug_bootloader_adding_immutable_b0_custom_signing: - -Custom signing commands -~~~~~~~~~~~~~~~~~~~~~~~ - -If you want complete control over the key handling of a project, you can use a custom signing command with |NSIB|. -Using a custom signing command removes the need to use of a private key from the build system. -This is useful when the private keys are stored, managed, or otherwise processed through a *hardware security module* (`HSM`_) or an in-house tool. - -To use a custom signing command with this bootloader, set the following options in the application's :file:`prj.conf` file, in an associated Kconfig fragment, or using the command line: - -.. tabs:: - - .. group-tab:: Kconfig / prj.conf - - .. code-block:: console - - CONFIG_SECURE_BOOT=y - CONFIG_SB_SIGNING_CUSTOM=y - CONFIG_SB_SIGNING_PUBLIC_KEY="/path/to/pub.pem" - CONFIG_SB_SIGNING_COMMAND="my_command" - - .. group-tab:: Command line - - .. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -DCONFIG_SB_SIGNING_CUSTOM=y \ - -DCONFIG_SB_SIGNING_PUBLIC_KEY=\"/path/to/pub.pem\" \ - -DCONFIG_SB_SIGNING_COMMAND=\"my_command\" - - Escaped quotations avoid malformed-string warnings from Kconfig. - -.. note:: - - The public key string must be an absolute path to the location of the public key file, as mentioned previously in :ref:`ug_bootloader_adding_immutable_keys`. - -See :kconfig:option:`CONFIG_SB_SIGNING_COMMAND` for specifics about what a usable signing command must do. -The command string can include its own arguments like a typical terminal command, including arguments specific to the build system: - -.. parsed-literal:: - :class: highlight - - my_command *[options]* ** ** - -See the description of :kconfig:option:`CONFIG_SB_SIGNING_COMMAND` for which arguments can be sent to the build system in this way. - -.. note:: - - Whitespace, hyphens, and other non-alphanumeric characters must be escaped appropriately when setting the string from the command line. - If the custom signing command uses its own options or arguments, it is recommended to define the string in a :file:`prj.conf` file or Kconfig fragment to avoid tracking backslashes. - Like public key paths, environment variables are not expanded when using them in a command string set from one of these files. - -.. _ug_bootloader_adding_immutable_mcuboot: - -Adding MCUboot as an immutable bootloader -========================================= - -To build :doc:`MCUboot ` with a Zephyr or |NCS| sample, enable the :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT` in the application's :file:`prj.conf` file, an associated Kconfig fragment, or using the command line: - -.. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- -DCONFIG_BOOTLOADER_MCUBOOT=y - -|how_to_configure| -Like other child images, you can assign :ref:`image-specific configurations ` at build time to further customize the bootloader's functionality. - -Configuring MCUboot as an immutable bootloader ----------------------------------------------- - -The following sections describe different configuration options available for MCUboot as an immutable bootloader. - -.. _ug_bootloader_adding_immutable_mcuboot_keys: - -Adding a custom signature key file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To pass the signature key file into the MCUboot image, set its :kconfig:option:`CONFIG_BOOT_SIGNATURE_KEY_FILE` option to the selected private key file. -You can set the option in :file:`bootloader/mcuboot/boot/zephyr/prj.conf`, an associated Kconfig fragment, or using the command line: - -.. tabs:: - - .. group-tab:: Kconfig / prj.conf - - .. code-block:: console - - CONFIG_BOOT_SIGNATURE_KEY_FILE="priv.pem" - - .. group-tab:: Command line - - .. code-block:: console - - -Dmcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE=\"priv.pem\" - - Escaped quotations avoid malformed-string warnings from Kconfig. - -The path of the key works as :ref:`described above ` for |NSIB|, except the application directory for relative pathing is considered to be :file:`bootloader/mcuboot`. - -See :ref:`ug_fw_update_keys` for information on how to generate custom keys for a project. - -We recommend you also set the associated configuration for a key type to ensure MCUboot compiles the public key into its image correctly. - -.. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_BOOTLOADER_MCUBOOT=y \ - -Dmcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE=\"../../priv-ecdsa256.pem\" \ - -Dmcuboot_CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y - -You can find specific configuration options for keys with this bootloader in :file:`bootloader/mcuboot/boot/zephyr/Kconfig`. - -Checking the public key -^^^^^^^^^^^^^^^^^^^^^^^ - -You can extract the public key locally and compare it against MCUboot's auto-generated file to verify that it is using the custom key: - -.. code-block:: console - - diff build/mcuboot/zephyr/autogen-pubkey.c <(python3 bootloader/mcuboot/scripts/imgtool.py getpub -k priv.pem) - -If there is no file diff output, then the private key was successfully included with the bootloader image. - -.. _ug_bootloader_adding_upgradable: - -Adding an upgradable bootloader -******************************* - -MCUboot is the only upgradable bootloader currently available for the |NCS|. -The following section describes how to add it to your secure bootloader chain. - -.. _ug_bootloader_adding_upgradable_mcuboot: - -Adding MCUboot as an upgradable bootloader -========================================== - -To use MCUboot as an upgradable bootloader to your application, complete the following steps: - -1. :ref:`Add nRF Secure Immutable Bootloader as the immutable bootloader `. -#. Add MCUboot to the boot chain by including the :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT` Kconfig option with either the build command or in the application's :file:`prj.conf` file: - - .. code-block:: - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -DCONFIG_BOOTLOADER_MCUBOOT=y - - |how_to_configure| - -#. Optionally, you can configure MCUboot to use the cryptographic functionality exposed by the immutable bootloader and reduce the flash memory usage for MCUboot to less than 16 kB. - To enable this configuration, apply both the :file:`prj_minimal.conf` Kconfig project file and the :file:`external_crypto.conf` Kconfig fragment for the MCUboot image: - - .. code-block:: - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_BOOTLOADER_MCUBOOT=y \ - -DCONFIG_SECURE_BOOT=y \ - -Dmcuboot_CONF_FILE=prj_minimal.conf \ - -Dmcuboot_EXTRA_CONF_FILE=external_crypto.conf - - See :ref:`ug_bootloader_config` for more information about using Kconfig fragments with bootloaders. - -The build process generates several :ref:`app_build_output_files`, including :ref:`app_build_mcuboot_output`. - -Configuring MCUboot as an upgradable bootloader ------------------------------------------------ - -The following sections describe different configuration options available for MCUboot as an upgradable bootloader. - -Adding a custom signature key file -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The process to use specific signature keys with MCUboot used as the upgradable bootloader is the same as when it is used :ref:`as the immutable one `. - -.. note:: - - Since each bootloader is built with its own signature key, using a different private key with an upgradable bootloader will not cause problems with the secure boot chain. - You can also use the same private key for both the immutable and upgradable bootloaders, as long as the key type is supported by both of them. - -.. _ug_bootloader_adding_presigned_variants: - -Generating pre-signed variants -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Enable the :kconfig:option:`CONFIG_BUILD_S1_VARIANT` Kconfig option when building the upgradable bootloader to automatically generate :ref:`pre-signed variants ` of the image for both slots: - -.. code-block:: - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -DCONFIG_BOOTLOADER_MCUBOOT=y \ - -DCONFIG_BUILD_S1_VARIANT=y - -This is a necessary step for creating application update images for use with :ref:`ug_fw_update`. - -The S1 variant is built as a separate child image called ``s1_image``. -For this reason, any modifications to the configuration of the S1 variant must be done to the ``s1_image`` child image. -By default, this child image is an exact duplicate of the original image, with the exception of its placement in memory. -You only have to modify the version set in the :kconfig:option:`CONFIG_FW_INFO_FIRMWARE_VERSION` Kconfig option. -To make ``s1_image`` bootable with |NSIB|, the value of :kconfig:option:`CONFIG_FW_INFO_FIRMWARE_VERSION` for ``s1_image`` must be bigger than the one for original image. - -.. _ug_bootloader_testing: - -Testing the bootloader chain -**************************** - -To test either of the bootloaders and the secure bootloader chain, build and program them with any sample as described in :ref:`Adding a bootloader chain `. - -By default, both |NSIB| and MCUboot print information to their serial output on boot. -This output includes information about the validation of images in its slots, as well as firmware-specific information if using :kconfig:option:`CONFIG_FW_INFO` with the |NSIB|. -To see this output: - -1. |connect_terminal| -#. Reset the development kit. -#. Observe that each bootloader in the chain prints its information upon boot (some values may vary by build): - -.. tabs:: - - .. tab:: |NSIB| - - .. code-block:: - - Attempting to boot slot 0. - Attempting to boot from address 0x9000. - Verifying signature against key 0. - Hash: 0xc0...71 - Firmware signature verified. - Firmware version 1 - Setting monotonic counter (version: 1, slot: 0) - - .. tab:: MCUboot - - .. code-block:: - - [00:00:00.359,039] mcuboot: Starting bootloader - [00:00:00.365,295] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 - [00:00:00.375,671] mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 - [00:00:00.386,169] mcuboot: Boot source: none - [00:00:00.391,815] mcuboot: Swap type: none - [00:00:00.420,166] mcuboot: Bootloader chainload address offset: 0xc000 - [00:00:00.428,039] mcuboot: Jumping to the first image slot - -When compiled with minimal configurations that disable logging output, such as ``prj_minimal.conf``, you can disable the bootloader information output altogether or per-bootloader. -Refer to the source code directories of each bootloader to see what minimal configuration options are already available, or add them through a custom Kconfig fragment if desired. diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_config.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_config.rst index 6abd407b0fb0..cc3a5da268cc 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_config.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_config.rst @@ -20,37 +20,31 @@ However, there are other ways to customize your application using Kconfig option Using custom project configurations *********************************** -You can use custom project configuration options for the associated image, specifying them at build time using :ref:`ug_multi_image_variables`, either temporarily until you clean the build pristinely or permanently. +You can use custom project configuration options for the associated image, specifying them at build time, temporarily until you clean the build pristinely. For example, you can temporarily assign custom project configurations for both the bootloaders and a sample application as follows: .. code-block:: console west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -Db0_CONF_FILE=prj_immutable.conf \ - -Dmcuboot_CONF_FILE=prj_upgradable.conf \ - -DCONF_FILE=prj_app.conf - -In the example above, :file:`prj_app.conf` includes :kconfig:option:`CONFIG_SECURE_BOOT` and :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT` to enable the immutable and upgradable bootloaders by default. -The configuration applied during the command execution is taken into account until you clean the build pristinely. - -Alternatively, you can follow :ref:`ug_multi_image_permanent_changes` and store configuration options for child images in separate files in the application source directory. -For example, in the |NCS| applications and samples that use different :ref:`build types for configuration `, the :file:`child_image` folder in the application source directory is often used to apply :ref:`permanent configuration changes `. + -Db0_FILE_SUFFIX=immutable \ + -Dmcuboot_FILE_SUFFIX=upgradable \ + -Dapp_FILE_SUFFIX=app You can use custom project configuration files in combination with temporary configuration options associated with a single build, set using either the command line or Kconfig fragments. Assigning Kconfig fragments *************************** -You can use Kconfig fragments specific to bootloaders to set temporary configuration options for the associated image, specifying them at build time using :ref:`ug_multi_image_variables`. +You can use Kconfig fragments specific to bootloaders to set temporary configuration options for the associated image, specifying them at build time. -For example, you can assign the :file:`my-custom-fragment.conf` fragment to the |NSIB|, which uses the child name of ``b0``, as follows: +For example, you can assign the :file:`my-custom-fragment.conf` fragment to the |NSIB|, which uses the image name of ``b0``, as follows: .. code-block:: console west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -DCONFIG_BOOTLOADER_MCUBOOT=y \ + -DSB_CONFIG_SECURE_BOOT_APPCORE=y \ + -DSB_CONFIG_BOOTLOADER_MCUBOOT=y \ -Db0_EXTRA_CONF_FILE=my-custom-fragment.conf In the same way, you can replace ``b0`` with ``mcuboot`` to apply the :file:`my-custom-fragment.conf` fragment to the MCUboot image: @@ -58,13 +52,13 @@ In the same way, you can replace ``b0`` with ``mcuboot`` to apply the :file:`my- .. code-block:: console west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -DCONFIG_SECURE_BOOT=y \ - -DCONFIG_BOOTLOADER_MCUBOOT=y \ + -DSB_CONFIG_SECURE_BOOT_APPCORE=y \ + -DSB_CONFIG_BOOTLOADER_MCUBOOT=y \ -Dmcuboot_EXTRA_CONF_FILE=my-custom-fragment.conf -You can use this method to apply Kconfig fragments to any child image in the build, as well as to set any Kconfig option that can be set from the command line. +You can use this method to apply Kconfig fragments to any image in the build, as well as to set any Kconfig option that can be set from the command line. -See :ref:`ug_multi_image_variables` for more information about customizing images using this method. +See :ref:`sysbuild` for more information about customizing images using this method. Customizing partitions ********************** diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_dfu_image_versions.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_dfu_image_versions.rst index eb7f1d408f6c..ded8d4a777fc 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_dfu_image_versions.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_dfu_image_versions.rst @@ -30,14 +30,14 @@ This option can refer to two different things: * If NSIB directly boots your application image, the Kconfig option denotes the application image version. * If NSIB boots a secondary-stage bootloader, the Kconfig option denotes the version of the secondary-stage bootloader. In such case, the application is booted by the secondary-state bootloader and the application image version is configured using the versioning scheme of the secondary-stage bootloader. - For example, if you opted for :ref:`ug_bootloader_adding_upgradable_mcuboot`, the application image versioning configuration is described in :ref:`ug_fw_update_image_versions_mcuboot`. + For example, if you opted for :ref:`ug_bootloader_adding_sysbuild_upgradable_mcuboot`, the application image versioning configuration is described in :ref:`ug_fw_update_image_versions_mcuboot`. .. _ug_fw_update_image_versions_mcuboot: Configuring image version with MCUboot ************************************** -To assign a semantic version number to your application when you have opted for booting application directly by the MCUboot bootloader (that is, if you have opted for either :ref:`ug_bootloader_adding_immutable_mcuboot` or :ref:`ug_bootloader_adding_upgradable_mcuboot`), it is recommended to use the :file:`VERSION` file that contains the version information for the application image. +To assign a semantic version number to your application when you have opted for booting application directly by the MCUboot bootloader (that is, if you have opted for either :ref:`ug_bootloader_adding_sysbuild_immutable_mcuboot` or :ref:`ug_bootloader_adding_sysbuild_upgradable_mcuboot`), it is recommended to use the :file:`VERSION` file that contains the version information for the application image. Using a :file:`VERSION` file allows you to independently configure the version value for each build instance of the application. See Zephyr's :ref:`zephyr:app-version-details` page for more information. diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.rst index 433221050d06..8e8c0a1d5429 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_downgrade_protection.rst @@ -91,8 +91,8 @@ Downgrade protection using |NSIB| To enable anti-rollback protection with monotonic counter for |NSIB|, set the following configurations in the ``b0`` image: :kconfig:option:`CONFIG_SB_MONOTONIC_COUNTER` and :kconfig:option:`CONFIG_SB_NUM_VER_COUNTER_SLOTS` -Special handling is needed when updating the S1 variant of an image when :ref:`ug_bootloader_adding_upgradable`. -See :ref:`ug_bootloader_adding_presigned_variants` for details. +Special handling is needed when updating the S1 variant of an image when :ref:`ug_bootloader_adding_sysbuild_upgradable`. +See :ref:`ug_bootloader_adding_sysbuild_presigned_variants` for details. See :ref:`zephyr:sysbuild_kconfig_namespacing` in the Zephyr documentation for information on how to set options for built images in sysbuild. .. bootloader_monotonic_counter_nsib_end diff --git a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib.rst b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib.rst index f9604bcb06e9..8000652695fb 100644 --- a/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib.rst +++ b/doc/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_mcuboot_nsib.rst @@ -19,7 +19,6 @@ Following that, you can :ref:`add an immutable bootloader`. +#. Program the application to the target development kit and check its console output. With the first firmware version, ``priv_a.pem`` and ``pub_a.pem`` are used for signing and validating the image. .. code-block:: console diff --git a/doc/nrf/app_dev/companion_components.rst b/doc/nrf/app_dev/companion_components.rst index 09de6703cb5f..7b5fdd7057ae 100644 --- a/doc/nrf/app_dev/companion_components.rst +++ b/doc/nrf/app_dev/companion_components.rst @@ -48,7 +48,7 @@ The following table lists the available companion components: - Bootloader tailored for the :ref:`two-stage bootloader `. - :ref:`Bootloader requirements ` - :file:`samples/bootloader` - - :ref:`ug_bootloader_adding_immutable_b0` + - :ref:`ug_bootloader_adding_sysbuild_immutable_b0` * - :ref:`SUIT flash companion ` - Companion image that allows the Secure Domain Firmware to access the external memory during the :ref:`Software Updates for Internet of Things (SUIT) ` firmware upgrade. - :ref:`Sample requirements ` diff --git a/doc/nrf/app_dev/config_and_build/config_and_build_system.rst b/doc/nrf/app_dev/config_and_build/config_and_build_system.rst index 49f17073175a..15abb30c7a42 100644 --- a/doc/nrf/app_dev/config_and_build/config_and_build_system.rst +++ b/doc/nrf/app_dev/config_and_build/config_and_build_system.rst @@ -149,18 +149,6 @@ If enabled, the memory layout can be controlled in the following ways: After CMake has run, a :file:`partitions.yml` file with the memory layout will have been created in the :file:`build` directory. This process also creates a set of header files that provides defines, which can be used to refer to memory layout elements. -Child images ------------- - -.. important:: - |sysbuild_related_deprecation_note| - -The |NCS| build system allows the application project to become a root for the sub-applications known in the |NCS| as child images. -Examples of child images are bootloader images, network core images, or security-related images. -Each child image is a separate application. - -For more information, see :ref:`ug_multi_image`. - .. _app_build_file_suffixes: Custom configurations @@ -293,11 +281,6 @@ Moreover, this |NCS| setting does not apply to the following areas: Custom build types ================== -.. important:: - |file_suffix_related_deprecation_note| - It is still required for some applications that use build types with :ref:`multiple images `. - Check the application and sample documentation pages for which variable to use. - A build type is a feature that defines the way in which the configuration files are to be handled. For example, selecting a build type lets you generate different build configurations for *release* and *debug* versions of the application. @@ -318,8 +301,6 @@ The following software components can be made dependent on the build type: * The Partition Manager's :ref:`static configuration `. When the build type has been inferred, the file :file:`pm_static_.yml` will have precedence over :file:`pm_static.yml`. -* The :ref:`child image Kconfig configuration `. - Certain child image configuration files located in the :file:`child_image/` directory can be defined per build type. The devicetree configuration is not affected by the build type. @@ -327,17 +308,6 @@ For more information about how to invoke build types, see :ref:`cmake_options`. .. _app_build_additions_multi_image: -Multi-image builds -================== - -.. important:: - |sysbuild_related_deprecation_note| - -The |NCS| build system extends Zephyr's with support for multi-image builds. -You can find out more about these in the :ref:`ug_multi_image` section. - -The |NCS| allows you to :ref:`build types ` instead of using a single :file:`prj.conf` file. - Boilerplate CMake file ====================== diff --git a/doc/nrf/app_dev/config_and_build/index.rst b/doc/nrf/app_dev/config_and_build/index.rst index f9dff575034f..9cb0f2eef328 100644 --- a/doc/nrf/app_dev/config_and_build/index.rst +++ b/doc/nrf/app_dev/config_and_build/index.rst @@ -42,6 +42,5 @@ Make sure to consider :ref:`app_bootloaders` and :ref:`app_dfu` already at this hardware/index kconfig/index sysbuild/index - multi_image building output_build_files diff --git a/doc/nrf/app_dev/config_and_build/multi_image.rst b/doc/nrf/app_dev/config_and_build/multi_image.rst deleted file mode 100644 index bca2861a7437..000000000000 --- a/doc/nrf/app_dev/config_and_build/multi_image.rst +++ /dev/null @@ -1,407 +0,0 @@ -.. _ug_multi_image: - -Multi-image builds using child and parent images -################################################ - -.. contents:: - :local: - :depth: 2 - -.. caution:: - |sysbuild_related_deprecation_note| - -The firmware programmed to a device can be composed of either one application or several separate images. -In the latter case, the *parent* :term:`image file` requires one or more other images (the *child images*) to be present. -The child image then *chain-loads*, or *boots*, the parent image, which could also be a child image to another parent image, and boots that one. - -The most common use cases for builds composed of multiple images are applications that require a bootloader to be present or applications for multi-core CPUs. - -Using multiple images has the following advantages: - -* You can run the linker multiple times and partition the final firmware into several regions. - This partitioning is often useful for bootloaders. -* Since there is a symbol table for each image, the same symbol names can exist multiple times in the final firmware. - This is useful for bootloader images, which can require their own copy of a library that the application uses, but in a different version or configuration. -* In multi-core builds, the :term:`build configuration` of a child image in a separate core can be made known to the parent image. - -For the list of image files output by the build system for the multi-image builds, refer to :ref:`app_build_output_files` page. - -.. _ug_multi_image_when_to_use_images: - -When to use multiple images -*************************** - -In the |NCS|, multiple images are required in the following scenarios: - -First-stage and second-stage bootloaders - The first-stage bootloader establishes a root of trust by verifying the next step in the boot sequence. - This first-stage bootloader is immutable, which means it cannot be updated or deleted. - If a second-stage bootloader is present, then the first-stage bootloader is responsible for booting and updating the second-stage bootloader, which in turn is responsible for booting and updating the application. - As such, the first-stage bootloader, the second-stage bootloader, and the application must be located in different images. - In this scenario, the application is the parent image and the bootloaders are two separate child images. - - See :ref:`ug_bootloader` and :ref:`ug_bootloader_adding` for more information. - -nRF5340 development kit support - The nRF5340 development kit (DK) contains two separate processors: a network core and an application core. - When programming an application for the nRF5340 DK, the application must be divided into at least two images, one for each core. - - See :ref:`ug_nrf5340` for more information. - -nRF5340 Audio development kit support - The nRF5340 Audio development kit (DK) is based on the nRF5340 development kit and also contains two separate processors. - When programming an application for the nRF5340 Audio DK, the application core image is built from a combination of different configuration files. - The network core image is programmed with an application-specific precompiled Bluetooth Low Energy Controller binary file that contains the LE Audio Controller Subsystem for nRF53. - - See the documentation for :ref:`nrf53_audio_app` for more information. - -.. _ug_multi_image_default_config: - -Default configuration -********************* - -The |NCS| samples are set up to build all related images as one solution, starting from the parent image. -This is referred to as a *multi-image build*. - -When building the parent image, you can configure how the child image should be handled: - -* Build the child image from the source and include it with the parent image. - This is the default setting. -* Use a prebuilt HEX file of the child image and include it with the parent image. -* Ignore the child image. - -When building the child image from the source or using a prebuilt HEX file, the build system merges the HEX files of both the parent and child image, so that they can be programmed in one single step. -This means that you can enable and integrate an additional image just by using the default configuration. - -To change the default configuration and configure how a child image is handled, locate the ``BUILD_STRATEGY`` Kconfig options for the child image in the parent image configuration. -For example, to use a prebuilt HEX file of the MCUboot instead of building it, select :kconfig:option:`CONFIG_MCUBOOT_BUILD_STRATEGY_USE_HEX_FILE` instead of the default :kconfig:option:`CONFIG_MCUBOOT_BUILD_STRATEGY_FROM_SOURCE`, and specify the HEX file in :kconfig:option:`CONFIG_MCUBOOT_HEX_FILE`. -To ignore an MCUboot child image, select :kconfig:option:`CONFIG_MCUBOOT_BUILD_STRATEGY_SKIP_BUILD` instead of :kconfig:option:`CONFIG_MCUBOOT_BUILD_STRATEGY_FROM_SOURCE`. - -.. _ug_multi_image_defining: - -Defining and enabling a child image -*********************************** - -You can enable existing child images in the |NCS| by enabling the respective modules in the parent image and selecting the desired build strategy. - -To turn an application that you have implemented into a child image that can be included in a parent image, you must update the build scripts to enable the child image and add the required configuration options. -You should also know how image-specific variables are disambiguated and what targets of the child images are available. - -.. _ug_multi_image_build_scripts: - -Updating the build scripts -========================== - -To make it possible to enable a child image from a parent image, you must include the child image in the build script. -If you need to perform this operation out-of-tree (that is, without modifying |NCS| code), or from the top-level CMakeLists.txt in your sample, see :ref:`ug_multi_image_add_child_image_oot`. - -To do so, place the code from the following example in the CMake tree that is conditional on a configuration option. -In the |NCS|, the code is included in the :file:`CMakeLists.txt` file for the samples, and in the MCUboot repository. - -.. code-block:: cmake - - if (CONFIG_SECURE_BOOT) - add_child_image( - NAME b0 - SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/bootloader - ) - endif() - - if (CONFIG_BOOTLOADER_MCUBOOT) - add_child_image( - NAME mcuboot - SOURCE_DIR ${MCUBOOT_DIR}/boot/zephyr - ) - endif() - -In this code, ``add_child_image`` registers the child image with the given name and file path and executes the build scripts of the child image. -Note that both the child image's application build scripts and the core build scripts are executed. -The core build scripts might use a different configuration and possibly different devicetree settings. - -If you have to execute a child image on a different core, you must specify the namespace for the child image as *domain* when adding the child image. -See the following example: - -.. code-block:: cmake - - add_child_image( - NAME hci_ipc - SOURCE_DIR ${ZEPHYR_BASE}/samples/bluetooth/hci_ipc - DOMAIN CPUNET - ) - -A *domain* is well-defined if there is the ``CONFIG_DOMAIN_${DOMAIN}_BOARD`` configuration option in Kconfig. - -.. _ug_multi_image_add_child_image_oot: - -Adding a child image using Zephyr modules -========================================= - -Any call to ``add_child_image`` must be done *after* :file:`nrf/cmake/extensions.cmake` is invoked, but *before* :file:`multi_image.cmake` is invoked. -In some scenarios, this is not possible without modifying the |NCS| build code, for example, from top-level sample files and project :file:`CMakeLists.txt` files. - -To avoid this issue, use the *Modules* mechanism provided by the Zephyr build system. -The following example shows how to add the required module from a top-level sample :file:`CMakeLists.txt`. - -.. code-block:: cmake - - cmake_minimum_required(VERSION 3.20.0) - - set(ZEPHYR_EXTRA_MODULES ${CMAKE_CURRENT_LIST_DIR}) - - find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE}) - project(app) - - target_sources(app PRIVATE src/main.c) - -A :file:`zephyr/module.yml` file is needed at the base of the added module. -The following example specifies only the path to the :file:`CMakeLists.txt` of the new module. -See :ref:`modules` for more details. - -.. code-block:: - - build: - cmake: aci - -The :file:`CMakeLists.txt` located in the directory pointed to by :file:`zephyr/module.yml` will be invoked when ``add_child_image`` can be invoked. - -.. code-block:: cmake - - add_child_image( - NAME remote - SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/../remote - DOMAIN remote - BOARD ${CONFIG_APP_REMOTE_BOARD} - ) - -Adding configuration options -============================ - -When enabling a child image, you must select the build strategy to define how the image should be included. -The following three options are available: - -* ``_BUILD_STRATEGY_FROM_SOURCE`` - Build the child image from source along with the parent image. -* ``_BUILD_STRATEGY_USE_HEX_FILE`` - Merge the specified HEX file of the child image with the parent image, using ``_HEX_FILE`` to specify the HEX file. -* ``_BUILD_STRATEGY_SKIP_BUILD`` - Ignore the child image when building and build only the parent image. - -.. note:: - - Child images that are built with the build strategy ``_BUILD_STRATEGY_SKIP_BUILD`` or ``_BUILD_STRATEGY_USE_HEX_FILE`` must define a :ref:`static partition `. - -Add these configuration options to the Kconfig file of your child image, replacing ```` with the uppercase name of your child image that is specified in ``add_child_image``. -To do this, include the :file:`Kconfig.template.build_strategy` template as follows: - -.. code-block:: Kconfig - - module=MCUBOOT - source "${ZEPHYR_NRF_MODULE_DIR}/subsys/partition_manager/Kconfig.template.build_strategy" - -.. _ug_multi_image_variables: - -Image-specific variables -======================== - -The child and parent images are executed in different CMake processes and thus have different namespaces. - -Variables in the parent image are not propagated to the child image, with the following exceptions: - -* Any variable named ``_VARIABLEONE`` in a parent image is propagated to the child image named ```` as ``VARIABLEONE``. - See `Temporary variables in child images`_ for more information. -* CMake build settings, such as ``BOARD_DIR``, build type, toolchain info, partition manager info, and similar are always passed to child images. - See `Permanent configuration changes to child images`_ for more information. - -Using these two exceptions, you can set variables in child images from either parent images or the command line, and you can also set variables globally across all images. - -.. _ug_multi_image_variables_fragments: - -Temporary variables in child images ------------------------------------ - -It is possible to provide variables to the child images. -These variables will be valid until you :ref:`clean the build directory pristinely `. - -For example, to change the ``VARIABLEONE`` variable for the ``childimageone`` child image and the parent image, specify the CMake command as follows: - - .. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_\ *VARIABLEONE*\=value -D\ *VARIABLEONE*\=value - -You can extend the CMake command used to create the child images by adding flags to the CMake variable ``EXTRA_MULTI_IMAGE_CMAKE_ARGS``. -For example, add ``--trace-expand`` to that variable to output more debug information. - -With west, you can pass these configuration variables into CMake by using the ``--`` separator: - - .. code-block:: console - - west build -b nrf52840dk/nrf52840 zephyr/samples/hello_world -- \ - -Dmcuboot_CONF_FILE=prj_a.conf \ - -DCONF_FILE=app_prj.conf - -Child image Kconfig modification -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is possible to provide Kconfig configuration for child images, either as individual settings or using Kconfig fragments. -Each child image is referenced using its image name. - -These temporary settings will be valid until you :ref:`clean the build directory pristinely `. - -The following example sets the configuration option ``CONFIG_VARIABLEONE=val`` in the child image ``childimageone``: - - .. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_\ *CONFIG_VARIABLEONE=val*\ [...] - -You can add a Kconfig fragment to the child image default configuration in a similar way. -The following example adds an extra Kconfig fragment ``extrafragment.conf`` to ``childimageone``: - - .. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_EXTRA_CONF_FILE=\ *extrafragment.conf*\ [...] - -It is also possible to provide a custom configuration file as a replacement for the default Kconfig file for the child image. -The following example uses the custom configuration file ``myfile.conf`` when building ``childimageone``: - - .. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_CONF_FILE=\ *myfile.conf*\ [...] - -If your application includes multiple child images, then you can combine all the above as follows: - -* Setting ``CONFIG_VARIABLEONE=val`` in the main application. -* Adding a Kconfig fragment ``extrafragment.conf`` to the ``childimageone`` child image, using ``-Dchildimageone_EXTRA_CONF_FILE=extrafragment.conf``. -* Using ``myfile.conf`` as configuration for the ``quz`` child image, using ``-Dquz_CONF_FILE=myfile.conf``. - - .. parsed-literal:: - :class: highlight - - cmake -DCONFIG_VARIABLEONE=val -D\ *childimageone*\_EXTRA_CONF_FILE=\ *extrafragment.conf*\ -Dquz_CONF_FILE=\ *myfile.conf*\ [...] - -See :ref:`ug_bootloader` for more details. - -.. note:: - - The build system grabs the Kconfig fragment or configuration file specified in a CMake argument relative to that image's application directory. - For example, the build system uses ``nrf/samples/bootloader/my-fragment.conf`` when building with the ``-Db0_EXTRA_CONF_FILE=my-fragment.conf`` option, whereas ``-DEXTRA_CONF_FILE=my-fragment.conf`` grabs the fragment from the main application's directory, such as ``zephyr/samples/hello_world/my-fragment.conf``. - -You can also merge multiple fragments into the overall configuration for an image by giving a list of Kconfig fragments as a string, separated using ``;``. -The following example shows how to combine ``abc.conf``, Kconfig fragment of the ``childimageone`` child image, with the ``extrafragment.conf`` fragment: - - .. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_EXTRA_CONF_FILE='\ *extrafragment.conf*\;\ *abc.conf*\' - -When the build system finds the fragment, it outputs their merge during the CMake build output as follows: - -.. parsed-literal:: - :class: highlight - - ... - Merged configuration '\ *extrafragment.conf*\' - Merged configuration '\ *abc.conf*\' - ... - -Child image devicetree modification -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -You can provide devicetree overlays for a child image using ``*.overlay`` files. - -The following example sets the devicetree overlay ``extra.overlay`` to ``childimageone``: - -.. parsed-literal:: - :class: highlight - - cmake -D\ *childimageone*\_DTC_OVERLAY_FILE='\ *extra.overlay*\' - -The build system does also automatically apply any devicetree overlay located in the ``child_image`` folder and named as follows (where ``ACI_NAME`` is the name of the child image): - -* ``child_image/.overlay`` -* ``child_image//.overlay`` -* ``child_image//_.overlay`` -* ``child_image//boards/.overlay`` -* ``child_image//boards/_.overlay`` - -.. note:: - - The build system grabs the devicetree overlay files specified in a CMake argument relative to that image's application directory. - For example, the build system uses ``nrf/samples/bootloader/my-dts.overlay`` when building with the ``-Db0_DTC_OVERLAY_FILE=my-dts.overlay`` option, whereas ``-DDTC_OVERLAY_FILE=my-dts.overlay`` grabs the fragment from the main application's directory, such as ``zephyr/samples/hello_world/my-dts.overlay``. - -.. _ug_multi_image_permanent_changes: - -Permanent configuration changes to child images ------------------------------------------------ - -You can make a project automatically pass Kconfig configuration files, fragments, and devicetree overlays to child images by placing them under a predefined path. -For example, in the |NCS| applications and samples that use different :ref:`build types `, the :file:`child_image` folder in the application source directory is often used to apply :ref:`permanent configuration changes `. - -The listing below describes how to leverage this functionality, where ``ACI_NAME`` is the name of the child image to which the configuration will be applied. - -When you are using :ref:`app_build_additions_build_types` and the configuration name has been inferred, the child image Kconfig overlay file is searched at :file:`child_image/_.conf`. -Alternatively, the child image Kconfig configuration file can be introduced as :file:`child_image//prj.conf` and follow the same pattern as the parent Kconfig. -For example, :file:`child_image/mcuboot/prj_release.conf` can be used to define the ``release`` build type for the ``mcuboot`` child image. - -Child image targets -=================== - -You can indirectly invoke a selection of child image targets from the parent image. -Currently, the child targets that can be invoked from the parent targets are ``menuconfig``, ``guiconfig``, and any targets listed in ``EXTRA_KCONFIG_TARGETS``. - -To disambiguate targets, use the same prefix convention used for variables. -For example, to run menuconfig, invoke the ``menuconfig`` target to configure the parent image and ``mcuboot_menuconfig`` to configure the MCUboot child image. - -You can also invoke any child target directly from its build directory. -Child build directories are located at the root of the parent's build directory. - -Controlling the build process -============================= - -The child image is built using CMake's build command ``cmake --build``. -This mechanism allows additional control of the build process through CMake. - -CMake options -------------- - -The following CMake options are propagated from the CMake command of the parent image to the CMake command of the child image: - -* ``CMAKE_BUILD_TYPE`` -* ``CMAKE_VERBOSE_MAKEFILE`` - -You can add other CMake options to a specific child image in the same way as you can set :ref:`Image-specific variables `. -For example, add ``-Dmcuboot_CMAKE_VERBOSE_MAKEFILE`` to the parent's CMake command to build the ``mcuboot`` child image with verbose output. - -To enable additional debug information for the multi-image build command, set the CMake option ``MULTI_IMAGE_DEBUG_MAKEFILE`` to the desired debug mode. -For example, add ``-DMULTI_IMAGE_DEBUG_MAKEFILE=explain`` to log the reasons why a command was executed. - -See :ref:`cmake_options` for instructions on how to specify these CMake options for the build. - -CMake environment variables ---------------------------- - -Unlike CMake options, CMake environment variables allow you to control the build process without re-invoking CMake. - -You can use the CMake environment variables `VERBOSE`_ and `CMAKE_BUILD_PARALLEL_LEVEL`_ to control the verbosity and the number of parallel jobs for a build: - -When using the command line or |VSC| terminal window, you must set them before invoking west. -They apply to both the parent and child images. -For example, to build with verbose output and one parallel job, use the following command, where *board_target* is the target for the development kit for which you are building: - -.. parsed-literal:: - :class: highlight - - west build -b *board_target* -- -DCMAKE_VERBOSE_MAKEFILE=1 -DCMAKE_BUILD_PARALLEL_LEVEL=1 - -Memory placement -**************** - -In a multi-image build, all images must be placed in memory so that they do not overlap. -The flash memory start address for each image must be specified by, for example, :kconfig:option:`CONFIG_FLASH_LOAD_OFFSET`. - -Hardcoding the image locations like this works fine for simple use cases like a bootloader that prepares a device, where there are no further requirements on where in memory each image must be placed. -However, more advanced use cases require a memory layout where images are located in a specific order relative to one another. - -The |NCS| provides a Python tool that allows you to specify this kind of relative placement or even a static placement based on start addresses and sizes for the different images. - -See :ref:`partition_manager` for more information about how to set up your partitions and configure your build system. diff --git a/doc/nrf/app_dev/device_guides/nrf52/fota_update.rst b/doc/nrf/app_dev/device_guides/nrf52/fota_update.rst index c838dbb9ca51..ca83cde5200e 100644 --- a/doc/nrf/app_dev/device_guides/nrf52/fota_update.rst +++ b/doc/nrf/app_dev/device_guides/nrf52/fota_update.rst @@ -14,7 +14,7 @@ You can also use FOTA updates to replace the application. See the :ref:`app_dfu` page for general Device Firmware Update (DFU) information, such as supported methods for sending and receiving updates on the device. .. note:: - For the possibility of introducing an upgradable bootloader, refer to :ref:`ug_bootloader_adding`. + For the possibility of introducing an upgradable bootloader, refer to :ref:`ug_bootloader_adding_sysbuild`. .. fota_upgrades_intro_end @@ -52,7 +52,7 @@ To enable support for FOTA updates, do the following: .. fota_upgrades_over_ble_mandatory_mcuboot_start * Use MCUboot as the upgradable bootloader (``SB_CONFIG_BOOTLOADER_MCUBOOT`` must be enabled). - For more information, go to the :ref:`ug_bootloader_adding` page. + For more information, go to the :ref:`ug_bootloader_adding_sysbuild` page. .. fota_upgrades_over_ble_mandatory_mcuboot_end @@ -184,7 +184,7 @@ FOTA update sample The :zephyr:code-sample:`smp-svr` demonstrates how to set up your project to support FOTA updates. -The sample documentation is from the Zephyr project and is incompatible with the :ref:`ug_multi_image`. +The sample documentation is from the Zephyr project. When working in the |NCS| environment, ignore the part of the sample documentation that describes the building and programming steps. In |NCS|, you can build and program the :zephyr:code-sample:`smp-svr` as any other sample using the following commands: @@ -195,7 +195,7 @@ In |NCS|, you can build and program the :zephyr:code-sample:`smp-svr` as any oth .. parsed-literal:: :class: highlight - west build -b *board_target* -- -DEXTRA_CONF_FILE=overlay-bt.conf -DSB_CONFG_NETCORE_HCI_IPC=y + west build -b *board_target* -- -DEXTRA_CONF_FILE=overlay-bt.conf -DSB_CONFIG_NETCORE_HCI_IPC=y west flash .. group-tab:: nRF52 SoCs diff --git a/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst b/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst index c5ef47fd9119..e58b00febca1 100644 --- a/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst +++ b/doc/nrf/app_dev/device_guides/nrf53/building_nrf53.rst @@ -31,7 +31,7 @@ You can build and program separate images or combined images using the |nRFVSC|. .. group-tab:: Multi-image build - If you are working with Bluetooth LE, Thread, Zigbee, or Matter samples, the network core sample is built as a child image when you build the application core image (see :ref:`ug_nrf5340_multi_image` above). + If you are working with Bluetooth LE, Thread, Zigbee, or Matter samples, the network core sample is built as a image when you build the application core image. Complete the following steps to build and program a multi-image build to the nRF5340 application core and network core: @@ -147,3 +147,133 @@ To program the nRF5340 DK from the command line, use either west (which uses nrf .. note:: The ``--verify`` command confirms that the writing operation has succeeded. + +.. _thingy53_building_pgming: + +Building and programming with Thingy:53 +*************************************** + +You can program the Nordic Thingy:53 by using the images obtained by building the code in the |NCS| environment. + +To set up your system to be able to build a firmware image, follow the :ref:`installation` guide for the |NCS|. + +.. _thingy53_build_pgm_targets: + +Board targets +============= + +The board targets of interest for Thingy:53 in the |NCS| are listed in the following table: + ++--------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ +|Component | Board target | ++================================+==================================================================================================================================+ +| nRF5340 SoC - Application core |``thingy53/nrf5340/cpuapp`` for :ref:`Cortex-M Security Extensions (CMSE) disabled ` | +| | | +| |``thingy53/nrf5340/cpuapp/ns`` for :ref:`CMSE enabled ` | ++--------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ +| nRF5340 SoC - Network core |``thingy53/nrf5340/cpunet`` | ++--------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ + +When you choose ``thingy53/nrf5340/cpuapp`` or ``thingy53/nrf5340/cpuapp/ns`` as the board target when building a sample or application, you will generate firmware for both the application core and network core: + +* The application core firmware consists of MCUboot bootloader and an application image. +* The network core firmware consists of network core bootloader (B0n) and application firmware of the network core. + +The build process generates firmware in two formats: + +* Intel Hex file (:file:`merged.hex` and :file:`merged_CPUNET.hex`) - Used with an external debug probe. + These file contains bootloaders and applications for each core. +* Binary files (:file:`zephyr.signed.bin`), containing signed application firmwares for the application and network core, respectively. + For convenience, the binary files are bundled in :file:`dfu_application.zip`, together with a manifest that describes them. + You can use the binary files or the combined zip archive to update application firmware for both cores, with either MCUboot serial recovery or OTA DFU using Bluetooth LE. + +For more information about files generated as output of the build process, see :ref:`app_build_output_files`. + +See the following sections for details regarding building and programming the firmware for Thingy:53 in various environments. +See :ref:`thingy53_app_update` for more detailed information about updating firmware on Thingy:53. + +.. _thingy53_build_pgm_targets_wifi: + +Building Wi-Fi applications on Thingy:53 +---------------------------------------- + +.. building_wi_fi_applications_on_thingy_53_start + +You can use the Nordic Thingy:53 with the nRF7002 Expansion Board (EB) for Wi-Fi development. +Connect the nRF7002 EB to the **P9** connector on Thingy:53. + +To build for the nRF7002 EB with Thingy:53, use the ``thingy53/nrf5340/cpuapp`` board target with the CMake ``SHIELD`` variable set to ``nrf7002eb``. +For example, you can use the following command when building on the command line: + +.. code-block:: + + west build -b thingy53/nrf5340/cpuapp -- -DSHIELD=nrf7002eb + +.. building_wi_fi_applications_on_thingy_53_end + +For the compatible Wi-Fi samples in the |NCS|, see the :ref:`wifi_samples` section. + +.. _thingy53_build_pgm_vscode: + +Building and programming using |VSC| +==================================== + +Complete the following steps to build and program using the |nRFVSC|: + +.. |sample_path_vsc| replace:: :file:`nrf/samples/bluetooth/peripheral_lbs` + +.. |vsc_sample_board_target_line| replace:: select ``thingy53/nrf5340/cpuapp`` as the board target + +.. include:: /includes/vsc_build_and_run.txt + +3. Program the sample or application: + + a. Connect the Nordic Thingy:53 to the debug out port on a 10-pin external debug probe, for example nRF5340 DK, using a 10-pin JTAG cable. + #. Connect the external debug probe to the PC using a USB cable. + #. Make sure that the Thingy:53 and the external debug probe are powered on. + #. Click :guilabel:`Flash` in the :guilabel:`Actions View`. + +.. _thingy53_build_pgm_command_line: + +Building and programming on the command line +============================================ + +You must :ref:`build_environment_cli` before you start building an |NCS| project on the command line. + +To build and program the source code from the command line, complete the following steps: + +1. |open_terminal_window_with_environment| +#. Go to the specific directory for the sample or application. + + For example, the directory path is :file:`ncs/nrf/applications/machine_learning` when building the source code for the :ref:`nrf_machine_learning_app` application. + +#. Make sure that you have the required version of the |NCS| repository by pulling the ``sdk-nrf`` repository on GitHub as described in :ref:`dm-wf-get-ncs` and :ref:`dm-wf-update-ncs` sections. +#. Get the rest of the dependencies using west: + + .. code-block:: console + + west update + +#. Build the sample or application code as follows: + + .. parsed-literal:: + :class: highlight + + west build -b *board_target* -d *destination_directory_name* + + The board target should be ``thingy53/nrf5340/cpuapp`` or ``thingy53/nrf5340/cpuapp/ns`` when building samples for the application core. + The proper child image for ``thingy53/nrf5340/cpunet`` will be built automatically. + See :ref:`thingy53_build_pgm_targets` for details. + +#. Program the sample or application: + + a. Connect the Nordic Thingy:53 to the debug out port on a 10-pin external debug probe, for example nRF5340 DK, using a 10-pin JTAG cable. + #. Connect the external debug probe to the PC using a USB cable. + #. Make sure that the Nordic Thingy:53 and the external debug probe are powered on. + #. Use the following command to program the sample or application to the device: + + .. code-block:: console + + west flash + + The device resets and runs the programmed sample or application. diff --git a/doc/nrf/app_dev/device_guides/nrf53/features_nrf53.rst b/doc/nrf/app_dev/device_guides/nrf53/features_nrf53.rst index 2a866192a52c..392c16a907e4 100644 --- a/doc/nrf/app_dev/device_guides/nrf53/features_nrf53.rst +++ b/doc/nrf/app_dev/device_guides/nrf53/features_nrf53.rst @@ -150,7 +150,6 @@ You can use either the SoftDevice Controller or the Zephyr Bluetooth LE Controll See :ref:`ug_ble_controller` for more information. For the application core, the |NCS| provides a series of :ref:`Bluetooth Low Energy samples `, in addition to the :zephyr:code-sample-category:`bluetooth` samples. -|multi_image| .. note:: Most of the provided Bluetooth LE samples should run on the nRF5340 DK, but not all have been thoroughly tested. @@ -198,7 +197,6 @@ This Zephyr sample is designed specifically to enable the nRF IEEE 802.15.4 radi The sample implements the RPMsg transport using the `OpenAMP`_ library to communicate with the nRF IEEE 802.15.4 radio driver serialization host that runs on a separate core (in this case, the nRF5340 application core). For the application core, the |NCS| provides a series of samples for the :ref:`Thread `, :ref:`Zigbee `, and :ref:`Matter ` protocols. -|multi_image| Multiprotocol support ===================== @@ -231,7 +229,6 @@ For the network core, the |NCS| provides the :ref:`ipc_radio`. The :ref:`ipc_radio` enables both the Bluetooth LE Controller and the nRF IEEE 802.15.4 radio driver and simultaneously exposes the functionality of both stacks to the application. For the application core, the |NCS| provides a series of samples for the :ref:`Thread ` and :ref:`Zigbee ` protocols. -|multi_image| See the :ref:`ug_multiprotocol_support` user guide for instructions on how to enable multiprotocol support for Thread or Zigbee in combination with Bluetooth. @@ -254,13 +251,12 @@ Direct use of the radio peripheral Samples that directly use the radio peripheral can run on the network core of the nRF5340. They do not require any functionality from the application core. -However, on nRF5340, the application core is responsible for starting the network core and connecting its GPIO pins (see :kconfig:option:`CONFIG_SOC_NRF53_CPUNET_ENABLE` and the code in :file:`zephyr/boards/nordic/nrf5340dk/nrf5340_cpunet_reset.c`). +However, on nRF5340, the application core is responsible for starting the network core and connecting its GPIO pins (see :kconfig:option:`CONFIG_SOC_NRF53_CPUNET_ENABLE` and the code in :file:`zephyr/soc/nordic/nrf53/nrf53_cpunet_mgmt.c`). Therefore, you must always program the application core, even if the firmware is supposed to run only on the network core. You can use the :ref:`nrf5340_empty_app_core` sample for this purpose. -Configure the network core application to automatically include this sample as a child image. +Configure the network core application to automatically include this sample as the application core image. This is the default configuration for the listed network core samples. -For more information, see :kconfig:option:`CONFIG_NCS_SAMPLE_EMPTY_APP_CORE_CHILD_IMAGE` and :ref:`ug_nrf5340_multi_image`. No radio communication diff --git a/doc/nrf/app_dev/device_guides/nrf53/index.rst b/doc/nrf/app_dev/device_guides/nrf53/index.rst index a4d32e31a2ba..f01514b1cbb7 100644 --- a/doc/nrf/app_dev/device_guides/nrf53/index.rst +++ b/doc/nrf/app_dev/device_guides/nrf53/index.rst @@ -48,7 +48,6 @@ Refer to their documentation for more information. features_nrf53 building_nrf53 fota_update_nrf5340 - multi_image_nrf5340 simultaneous_multi_image_dfu_nrf5340 serial_recovery logging_nrf5340 diff --git a/doc/nrf/app_dev/device_guides/nrf53/multi_image_nrf5340.rst b/doc/nrf/app_dev/device_guides/nrf53/multi_image_nrf5340.rst deleted file mode 100644 index 7c82b3bfba87..000000000000 --- a/doc/nrf/app_dev/device_guides/nrf53/multi_image_nrf5340.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. _ug_nrf5340_multi_image: - -Multi-image builds on the nRF5340 DK using child and parent images -################################################################## - -.. contents:: - :local: - :depth: 2 - -.. note:: - |sysbuild_related_deprecation_note| - -If a sample consists of several images (in this case, different images for the application core and for the network core), you can build these images separately or combined as a :ref:`multi-image build `, depending on the sample configuration. - -In a multi-image build, the image for the application core is usually the parent image, and the image for the network core is treated as a child image in a separate domain. -For this to work, the network core image must be explicitly added as a child image to one of the application core images. -See :ref:`ug_multi_image_defining` for details. - -.. note:: - When using the :ref:`nrf5340_empty_app_core` sample, the image hierarchy is inverted. - In this case, the network core image is the parent image and the application core image is the child image. - -Default build configuration -*************************** - -By default, the two images are built together for all Bluetooth LE, Thread, Zigbee, and Matter samples in the |NCS|. -Samples that are designed to run only on the network core include the :ref:`nrf5340_empty_app_core` sample as a child image. -For other samples, the images are built separately. - -The :term:`build configuration` depends on the following Kconfig options that must be set in the configuration of the parent image: - -* :kconfig:option:`CONFIG_BT_HCI_IPC` - set to ``y`` in all Bluetooth LE samples for the application core -* :kconfig:option:`CONFIG_NRF_802154_SER_HOST` - set to ``y`` in all Thread, Zigbee, and Matter samples for the application core -* :kconfig:option:`CONFIG_NCS_SAMPLE_EMPTY_APP_CORE_CHILD_IMAGE` - set to ``y`` in all network core samples that require the :ref:`nrf5340_empty_app_core` sample - -The combination of these options determines which (if any) sample is included in the build of the parent image: - -.. list-table:: - :header-rows: 1 - - * - Enabled options - - Child image sample for the network core - - Child image sample for the application core - * - :kconfig:option:`CONFIG_BT_HCI_IPC` - - :zephyr:code-sample:`bluetooth_hci_ipc` - - --- - * - :kconfig:option:`CONFIG_NRF_802154_SER_HOST` - - :zephyr:code-sample:`nrf_ieee802154_rpmsg` - - --- - * - :kconfig:option:`CONFIG_NCS_SAMPLE_EMPTY_APP_CORE_CHILD_IMAGE` - - --- - - :ref:`nrf5340_empty_app_core` - -Configuration of the child image -******************************** - -When a network sample is built automatically as a child image in a multi-image build, you can define the relevant Kconfig options (if required) in a :file:`.conf` file. -Name the file :file:`network_sample*\ .conf`, where *network_sample* is the name of the child image (for example, :file:`hci_ipc.conf`). -Place the file in a :file:`child_image` subfolder of the application sample directory. -See :ref:`ug_multi_image_variables` for more information. - -This way of defining the Kconfig options allows to align the configurations of both images. - -For example, see the :ref:`ble_throughput` child image configuration in :file:`nrf/samples/bluetooth/throughput/child_image/hci_ipc.conf`. diff --git a/doc/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.rst b/doc/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.rst index 60ca09359bcd..948f9d32d452 100644 --- a/doc/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.rst +++ b/doc/nrf/app_dev/device_guides/nrf53/simultaneous_multi_image_dfu_nrf5340.rst @@ -12,8 +12,7 @@ To enable the simultaneous update of multiple images in the MCUboot, set the fol * :kconfig:option:`CONFIG_PCD_APP` - Enable commands exchange with the network core. * :kconfig:option:`CONFIG_UPDATEABLE_IMAGE_NUMBER` - Enable support for multiple update partitions by setting this option to ``2``. -As described in :ref:`multi-image build guide `, make sure to add the child image prefix to the name of Kconfig options that are used when building MCUboot as a child image (for example, ``child_image_CONFIG_PCD_APP``). -If not changed, then the default child image prefix for MCUboot is ``mcuboot_`` (for example, ``mcuboot_CONFIG_PCD_APP``). +As described in :ref:`sysbuild`, make sure to add the image prefix to the name of Kconfig options that are used when building MCUboot: ``mcuboot_CONFIG_PCD_APP``. .. note:: diff --git a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_configuration.rst b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_configuration.rst index 0fbfaea6750a..d9d6d0687a3a 100644 --- a/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_configuration.rst +++ b/doc/nrf/app_dev/device_guides/nrf54h/ug_nrf54h20_configuration.rst @@ -73,4 +73,3 @@ Additionally, the build process generates the following user information configu You must flash all the HEX files into the device. For more information on building images for the nRF54H20 DK, see :ref:`ug_nrf54h20_gs`. -For additional information on multi-image builds see :ref:`ug_multi_image`. diff --git a/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst b/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst index bc1e9d5571c5..9d8b6114298e 100644 --- a/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst +++ b/doc/nrf/app_dev/device_guides/nrf91/nrf91_features.rst @@ -80,8 +80,7 @@ Therefore, you must build it for any of the following board targets, depending o * ``thingy91x/nrf9151/ns`` The application image might require other images to be present. -Some samples include the :ref:`bootloader` sample (:kconfig:option:`CONFIG_SECURE_BOOT`) and :doc:`mcuboot:index-ncs` (:kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`). -Depending on the configuration, all these images can be built at the same time in a :ref:`multi-image build `. +Some samples include the :ref:`bootloader` sample (``SB_CONFIG_SECURE_BOOT_APPCORE``) and :doc:`mcuboot:index-ncs` (``SB_CONFIG_BOOTLOADER_MCUBOOT``). .. _lte_modem: diff --git a/doc/nrf/app_dev/device_guides/thingy53/building_thingy53.rst b/doc/nrf/app_dev/device_guides/thingy53/building_thingy53.rst index f860411da205..ecb66e91b3a8 100644 --- a/doc/nrf/app_dev/device_guides/thingy53/building_thingy53.rst +++ b/doc/nrf/app_dev/device_guides/thingy53/building_thingy53.rst @@ -28,7 +28,7 @@ The board targets of interest for Thingy:53 in the |NCS| are listed in the follo | nRF5340 SoC - Network core |``thingy53/nrf5340/cpunet`` | +--------------------------------+----------------------------------------------------------------------------------------------------------------------------------+ -The |NCS| uses :ref:`ug_multi_image` for Thingy:53 by default. +The |NCS| uses :ref:`sysbuild` by default. When you choose ``thingy53/nrf5340/cpuapp`` or ``thingy53/nrf5340/cpuapp/ns`` as the board target when building a sample or application, you will generate firmware for both the application core and network core: * The application core firmware consists of MCUboot bootloader and an application image. diff --git a/doc/nrf/app_dev/device_guides/wifi_coex.rst b/doc/nrf/app_dev/device_guides/wifi_coex.rst index 060149ff54d6..72e7fc689855 100644 --- a/doc/nrf/app_dev/device_guides/wifi_coex.rst +++ b/doc/nrf/app_dev/device_guides/wifi_coex.rst @@ -57,7 +57,6 @@ The following are the common requirements to use the coexistence feature: .. note:: When using the nRF5340, apply steps 1 and 2 only to the network core. - See :ref:`ug_multi_image`. .. note:: Do not enable Wi-Fi coexistence on the nRF5340 SoC in conjunction with Coded Phy and FEM, as this can lead to undefined behavior. diff --git a/doc/nrf/includes/hci_ipc_overlay.txt b/doc/nrf/includes/hci_ipc_overlay.txt deleted file mode 100644 index 27730f8f9e78..000000000000 --- a/doc/nrf/includes/hci_ipc_overlay.txt +++ /dev/null @@ -1,4 +0,0 @@ -.. note:: - - If you use nRF5340 DK, the additional configuration of the network core will be taken from the :file:`child_image` directory. - For more details, see :ref:`ug_multi_image_variables`. diff --git a/doc/nrf/libraries/dfu/pcd.rst b/doc/nrf/libraries/dfu/pcd.rst index a79146c60313..e8b685c2fb1e 100644 --- a/doc/nrf/libraries/dfu/pcd.rst +++ b/doc/nrf/libraries/dfu/pcd.rst @@ -28,10 +28,9 @@ This is done to avoid compromised code from being able to perform updates of the The network core uses the PCD library to look for instructions on where to find the updates. Once an update instruction is found, this library is used to transfer the firmware update image. -On the application core, this library is used :ref:`MCUboot `. +On the application core, this library is used :ref:`MCUboot `. On the network core, the library is used by the :ref:`nc_bootloader` sample. - API documentation ***************** diff --git a/doc/nrf/protocols/matter/end_product/bootloader.rst b/doc/nrf/protocols/matter/end_product/bootloader.rst index aa9fb399b96f..dffff154f98c 100644 --- a/doc/nrf/protocols/matter/end_product/bootloader.rst +++ b/doc/nrf/protocols/matter/end_product/bootloader.rst @@ -15,7 +15,7 @@ This page contains guidelines for configuring the MCUboot bootloader in Matter p Adding MCUboot to application ***************************** -Read :ref:`ug_bootloader_adding_immutable_mcuboot` to learn how to add MCUboot to an |NCS| application. +Read :ref:`ug_bootloader_adding_sysbuild_immutable_mcuboot` to learn how to add MCUboot to an |NCS| application. Some Matter samples include :term:`Device Firmware Update (DFU)` support out of the box, as listed in the :ref:`sample feature matrix table `. MCUboot minimal configuration @@ -123,7 +123,7 @@ If the signature check fails, MCUboot rejects the image and either: As the key pair is publicly known, it provides no protection against the image forgery. For this reason, when making a real product, it is of the greatest importance to replace it with a unique key pair, known only to the device maker. - Read :ref:`ug_bootloader_adding_immutable_mcuboot_keys` to learn how to configure MCUboot to use a custom key pair. + Read :ref:`ug_bootloader_adding_sysbuild_immutable_mcuboot_keys` to learn how to configure MCUboot to use a custom key pair. Downgrade protection ******************** diff --git a/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst b/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst index 55c845771e92..6fa5349f90cb 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_guide_2.7.rst @@ -173,23 +173,12 @@ Samples and applications Applications using build types ------------------------------ -.. toggle:: - - For applications using build types: - - * The :makevar:`CONF_FILE` used for :ref:`app_build_additions_build_types` is now deprecated and is being replaced with the :makevar:`FILE_SUFFIX` variable, inherited from Zephyr. - You can read more about it in :ref:`app_build_file_suffixes`, :ref:`cmake_options`, and the :ref:`related Zephyr documentation `. - - If your application uses build types, it is recommended to update the :file:`sample.yaml` to use the new variable instead of :makevar:`CONF_FILE`. - - For applications using child images: - - * With the inheritance of Zephyr's :ref:`sysbuild in the |NCS| `, the :ref:`ug_multi_image` are deprecated. +For applications using build types: - If your application uses parent and child images, it is recommended to migrate your application to sysbuild before the multi-image builds are removed in one of the upcoming |NCS| releases. - See `Migrating from multi-image builds to sysbuild`_. + * The :makevar:`CONF_FILE` used for :ref:`app_build_additions_build_types` is now deprecated and is being replaced with the :makevar:`FILE_SUFFIX` variable, inherited from Zephyr. + You can read more about it in :ref:`app_build_file_suffixes`, :ref:`cmake_options`, and the :ref:`related Zephyr documentation `. - See the :ref:`documentation in Zephyr ` for more information about sysbuild. + If your application uses build types, it is recommended to update the :file:`sample.yaml` to use the new variable instead of :makevar:`CONF_FILE`. Matter ------ diff --git a/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst b/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst index 45c2ab02cbfb..ee80aaf1409c 100644 --- a/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst +++ b/doc/nrf/releases_and_maturity/migration/migration_sysbuild.rst @@ -8,7 +8,7 @@ Migrating from multi-image builds to sysbuild :depth: 2 :ref:`sysbuild` is a build system used in zephyr to configure, build, and flash multiple images as part of a single project. -It replaces the :ref:`child/parent system for multi-image builds ` in |NCS|. +It replaces the child/parent system for multi-image builds in |NCS|. As the previous system has been deprecated, you must update your existing multi-image build projects to support being built using sysbuild. The following are the differences in how project configuration is performed in sysbuild compared to child/parent image configuration: @@ -563,7 +563,7 @@ The expected output files are the following: Image overlay configuration *************************** -In child/parent image configurations, an application could include additional configuration files in the ``child_image`` folder that would be applied to these images (see :ref:`ug_multi_image_permanent_changes`). +In child/parent image configurations, an application could include additional configuration files in the ``child_image`` folder that would be applied to these images. This feature has been adapted in sysbuild; see :ref:`sysbuild_application_configuration` for an overview. You must update child/parent image configuration to use it with sysbuild, as the way these files can be used differs: diff --git a/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.4.99-cs3_to_2.7_application.rst b/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.4.99-cs3_to_2.7_application.rst index cc113143b22d..484446bce9f2 100644 --- a/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.4.99-cs3_to_2.7_application.rst +++ b/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.4.99-cs3_to_2.7_application.rst @@ -649,7 +649,7 @@ Applications using build types For applications using child images: - * With the inheritance of Zephyr's :ref:`sysbuild in the |NCS| `, the :ref:`ug_multi_image` are deprecated. + * With the inheritance of Zephyr's :ref:`sysbuild in the |NCS| `, the multi-image builds are deprecated. If your application uses parent and child images, it is recommended to migrate your application to sysbuild before the multi-image builds are removed in one of the upcoming |NCS| releases. See :ref:`child_parent_to_sysbuild_migration`. See the :ref:`documentation in Zephyr ` for more information about sysbuild. diff --git a/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.6.99-cs2_to_2.7_application.rst b/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.6.99-cs2_to_2.7_application.rst index 47a0a16f545b..52e414820b59 100644 --- a/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.6.99-cs2_to_2.7_application.rst +++ b/doc/nrf/releases_and_maturity/migration/nRF54H20_migration_2.7/migration_guide_2.6.99-cs2_to_2.7_application.rst @@ -568,7 +568,7 @@ Applications using build types For applications using child images: - * With the inheritance of Zephyr's :ref:`sysbuild in the |NCS| `, the :ref:`ug_multi_image` are deprecated. + * With the inheritance of Zephyr's :ref:`sysbuild in the |NCS| `, the multi-image builds are deprecated. If your application uses parent and child images, it is recommended to migrate your application to sysbuild before the multi-image builds are removed in one of the upcoming |NCS| releases. See :ref:`child_parent_to_sysbuild_migration`. See the :ref:`documentation in Zephyr ` for more information about sysbuild. diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.0.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.0.0.rst index d3ae859ec431..745e1cc06c8a 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.0.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.0.0.rst @@ -249,7 +249,7 @@ Documentation * Added or updated the following documentation: * nRF BLE Controller (experimental) - * :ref:`ug_multi_image` + * Multi-image build * :ref:`partition_manager` * :ref:`nrf_desktop` * :ref:`shell_bt_nus_readme` diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.2.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.2.0.rst index 3c888e51427c..772bf24b0397 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.2.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.2.0.rst @@ -513,7 +513,7 @@ Documentation * :ref:`ug_nrf5340` - added * :ref:`ug_thingy91` - added * :ref:`ug_ble_controller` - added - * :ref:`ug_multi_image` - updated with content that was removed from the Zephyr fork + * Multi-image builds - updated with content that was removed from the Zephyr fork * nrfxlib: diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.3.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.3.0.rst index c42947056d7a..da5812843385 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.3.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.3.0.rst @@ -401,7 +401,7 @@ MCUboot Build system ============ -* Added support for :ref:`ug_multi_image` for multi-core projects. +* Added support for multi-image builds for multi-core projects. * Facilitated defining non-secure boards out of tree. Any board that matches ``*_ns`` or ``*ns`` is now considered non-secure, and its child images board is set to the secure variant. * Added support for defining external flash in the :ref:`partition_manager`. @@ -433,7 +433,7 @@ In addition to documentation related to the changes listed above, the following * :ref:`ug_nrf52` - added * :ref:`ug_thingy91` - added :ref:`thingy91_serialports` * :ref:`ug_nfc` - added -* :ref:`ug_bootloader` - added :ref:`ug_bootloader_adding` +* :ref:`ug_bootloader` - added upgradeable bootloader * Cloud client - updated * :ref:`crypto_test` - added * :ref:`libraries` - improved the structure of the library documentation diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.4.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.4.0.rst index dc16976fee6a..a7c6042dbfd5 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.4.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.4.0.rst @@ -483,7 +483,7 @@ Build system * Added a warning if no static partition manager configuration is provided when one image (or more) is not built from source in a multi-image build. * Enabled choosing a build strategy for Zephyr's :zephyr:code-sample:`bluetooth_hci_ipc` sample when it is built as a child image. - See :ref:`ug_multi_image` for details. + See multi-image builds for details. * Improved multi-core builds by disassociating domain names from board names. * Bugfixes: diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.6.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.6.0.rst index 4b2881629437..b6c7c690f7a8 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.6.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.6.0.rst @@ -569,8 +569,8 @@ In addition to documentation related to the changes listed above, the following * Added the following bootloader user guides: - * :ref:`ug_bootloader_adding` - * :ref:`ug_bootloader_testing` + * Upgradeable bootloader + * Bootloader output testing * :ref:`ug_bootloader_external_flash` * :ref:`ug_bootloader_config` * :ref:`ug_fw_update` @@ -580,7 +580,7 @@ In addition to documentation related to the changes listed above, the following * :ref:`ug_bootloader` - Updated architecture information for clarifying first- and second-stage bootloader design. * "Immutable bootloader" references have been changed to "|NSIB|". -* :ref:`ug_multi_image` - Added more information regarding child image usage, configuration options, and image-specific variables. +* Multi-image builds - Added more information regarding child image usage, configuration options, and image-specific variables. * :ref:`partition_manager` - Added section about partition reports. * :ref:`ug_tfm` - Added references to new crypto samples that utilize TF-M and information about the TF-M minimal build. * :ref:`ug_thread` - The following sections were added or changed considerably: diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-1.7.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-1.7.0.rst index 14cabbf9f923..a43dc7c3845c 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-1.7.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-1.7.0.rst @@ -515,7 +515,7 @@ In addition to documentation related to the changes listed above, the following * :ref:`ug_app_dev` section pages: - * :ref:`ug_multi_image` - Updated with the section about Child image devicetree overlays. + * Multi-image builds - Updated with the section about Child image devicetree overlays. * :ref:`ug_radio_fem` - Updated for the nRF21540 release. * :ref:`ug_nrf91` user guide - Restructured into several subpages. diff --git a/doc/nrf/releases_and_maturity/releases/release-notes-2.7.0.rst b/doc/nrf/releases_and_maturity/releases/release-notes-2.7.0.rst index 6b31492d4541..130a972210a3 100644 --- a/doc/nrf/releases_and_maturity/releases/release-notes-2.7.0.rst +++ b/doc/nrf/releases_and_maturity/releases/release-notes-2.7.0.rst @@ -19,7 +19,7 @@ Highlights This release introduces significant, potentially breaking, changes to the SDK: * The `previous method to define a board (hardware model)`_ is deprecated and being replaced by :ref:`a new method (hardware model v2) `. -* The previous method to define :ref:`multi-image builds (parent-child images) ` is deprecated and being replaced by :ref:`zephyr:sysbuild`. +* The previous method to define multi-image builds (parent-child images) is deprecated and being replaced by :ref:`zephyr:sysbuild`. All samples and applications in the SDK have been migrated. Consult respective documentation as additional or changed parameters might be needed to build them successfully. @@ -56,7 +56,7 @@ Added the following features as supported: * Hardware model v2 (HWMv2), an improved extensible system for defining boards. This is the default boards definition system from this |NCS| release and onwards. See `Migrating to the current hardware model`_. - * :ref:`zephyr:sysbuild`, an improved and extensible system for multi-image build, replacing :ref:`ug_multi_image` (parent/child images). + * :ref:`zephyr:sysbuild`, an improved and extensible system for multi-image build, replacing (parent/child images). See `Migrating from multi-image builds to sysbuild`_. * Samples and applications that use short-range radio and run on multi-core SoCs were migrated to use the :ref:`ipc_radio` as the default image for the network/radio core. Samples previously used for the network/radio core are no longer used in the default builds: :zephyr:code-sample:`bluetooth_hci_ipc`, :zephyr:code-sample:`nrf_ieee802154_rpmsg`, ``nRF5340: Multiprotocol RPMsg``, and :ref:`ble_rpc_host`. diff --git a/doc/nrf/security/tfm.rst b/doc/nrf/security/tfm.rst index 48d3f3b30722..77493b3c42f3 100644 --- a/doc/nrf/security/tfm.rst +++ b/doc/nrf/security/tfm.rst @@ -35,7 +35,6 @@ Building ******** TF-M is one of the images that are built as part of a multi-image application. -For more information about multi-image builds, see :ref:`ug_multi_image`. To add TF-M to your build, enable the :kconfig:option:`CONFIG_BUILD_WITH_TFM` configuration option by adding it to your :file:`prj.conf` file. @@ -159,7 +158,7 @@ There are several options to get UART output from the secure TF-M: * Disable the output for the network core and change the pins used by TF-M. The network core will usually have an |NCS| child image. - To configure a child image, see Configuration of the child image section described in :ref:`ug_nrf5340_multi_image`. + To configure an image, see the Configuration namespacing section in :ref:`sysbuild`. To configure logging in an |NCS| image, see :ref:`ug_logging`. To change the pins used by TF-M, the RXD (:kconfig:option:`CONFIG_TFM_UART1_RXD_PIN`) and TXD (:kconfig:option:`CONFIG_TFM_UART1_TXD_PIN`) Kconfig options in the application image can be set to **P1.00** (32) and **P1.01** (33). diff --git a/doc/nrf/shortcuts.txt b/doc/nrf/shortcuts.txt index 2a8bd9da8fd1..352e69137e2e 100644 --- a/doc/nrf/shortcuts.txt +++ b/doc/nrf/shortcuts.txt @@ -246,8 +246,6 @@ .. |parameters_override_west_config| replace:: The parameters and options passed in the command line always take precedence over ``west config`` settings. -.. |multi_image| replace:: These samples are built for the application core and, by default, include the network core application as child image in a multi-image build (see :ref:`ug_nrf5340_multi_image`). - .. |migration_contact_devzone| replace:: While we strive to document all breaking changes, the migration guides might not include the detailed migration steps for your use case. If you need assistance, contact Nordic Semiconductor's technical support on `DevZone`_. diff --git a/doc/nrf/test_and_optimize/optimizing/power_general.rst b/doc/nrf/test_and_optimize/optimizing/power_general.rst index ca5b786f41a6..5a2b01af247b 100644 --- a/doc/nrf/test_and_optimize/optimizing/power_general.rst +++ b/doc/nrf/test_and_optimize/optimizing/power_general.rst @@ -58,7 +58,7 @@ To disable serial output, you must change the project configuration associated w .. note:: If the application consists of multiple images, like applications built for the nRF53 Series, logging must be disabled on both images. - See :ref:`ug_nrf5340` and :ref:`ug_multi_image`. + See :ref:`ug_nrf5340`. 1. Set the project configuration :kconfig:option:`CONFIG_SERIAL` to ``n`` irrespective of whether you are building the sample for the :ref:`SPE-only ` board targets or board targets with :ref:`NSPE `. #. For the board target with NSPE (for example, ``nrf9160dk/nrf9160/ns``), ensure that serial logging is also disabled in Trusted Firmware-M by setting :kconfig:option:`CONFIG_TFM_LOG_LEVEL_SILENCE` to ``y``. diff --git a/samples/bluetooth/central_hr_coded/README.rst b/samples/bluetooth/central_hr_coded/README.rst index b6f45a0013a6..823344c9a918 100644 --- a/samples/bluetooth/central_hr_coded/README.rst +++ b/samples/bluetooth/central_hr_coded/README.rst @@ -17,8 +17,6 @@ The sample supports the following development kits: .. table-from-sample-yaml:: -.. include:: /includes/hci_ipc_overlay.txt - The sample also requires a device running a Heart Rate Server with LE Coded PHY support to connect to. For example, another development kit running the :ref:`peripheral_hr_coded` sample. diff --git a/samples/bluetooth/fast_pair/input_device/README.rst b/samples/bluetooth/fast_pair/input_device/README.rst index df174fc022f9..c84dd9ca6fb6 100644 --- a/samples/bluetooth/fast_pair/input_device/README.rst +++ b/samples/bluetooth/fast_pair/input_device/README.rst @@ -27,8 +27,6 @@ The sample supports the following development kits: .. include:: /includes/tfm.txt -.. include:: /includes/hci_ipc_overlay.txt - Overview ******** diff --git a/samples/bluetooth/iso_combined_bis_and_cis/README.rst b/samples/bluetooth/iso_combined_bis_and_cis/README.rst index 226d1d5a32bc..ad598eb2b510 100644 --- a/samples/bluetooth/iso_combined_bis_and_cis/README.rst +++ b/samples/bluetooth/iso_combined_bis_and_cis/README.rst @@ -26,9 +26,6 @@ The sample supports the following development kits: To test the sample, you need two additional devices. You can use any of the development kits listed above and mix different development kits. - -.. include:: /includes/hci_ipc_overlay.txt - The sample also requires a connection to a computer with a serial terminal |ANSI| for each of the development kits. Overview diff --git a/samples/bluetooth/peripheral_hids_keyboard/README.rst b/samples/bluetooth/peripheral_hids_keyboard/README.rst index 501f067d4160..57c743773f9f 100644 --- a/samples/bluetooth/peripheral_hids_keyboard/README.rst +++ b/samples/bluetooth/peripheral_hids_keyboard/README.rst @@ -23,8 +23,6 @@ The sample supports the following development kits: .. include:: /includes/tfm.txt -.. include:: /includes/hci_ipc_overlay.txt - If the NFC_OOB_PAIRING feature is enabled, the sample requires a smartphone or a tablet with Android v8.0.0 or newer. Overview diff --git a/samples/bluetooth/peripheral_hids_mouse/README.rst b/samples/bluetooth/peripheral_hids_mouse/README.rst index 939575fcfcf9..88b6c5848dfd 100644 --- a/samples/bluetooth/peripheral_hids_mouse/README.rst +++ b/samples/bluetooth/peripheral_hids_mouse/README.rst @@ -22,8 +22,6 @@ The sample supports the following development kits: .. include:: /includes/tfm.txt -.. include:: /includes/hci_ipc_overlay.txt - Overview ******** diff --git a/samples/bluetooth/peripheral_hr_coded/README.rst b/samples/bluetooth/peripheral_hr_coded/README.rst index 4c42d4cec48b..26e262f43bd7 100644 --- a/samples/bluetooth/peripheral_hr_coded/README.rst +++ b/samples/bluetooth/peripheral_hr_coded/README.rst @@ -17,8 +17,6 @@ The sample supports the following development kits: .. table-from-sample-yaml:: -.. include:: /includes/hci_ipc_overlay.txt - The sample also requires a device running a Heart Rate Server with LE Coded PHY support to connect to. For example, another development kit running the :ref:`bluetooth_central_hr_coded` sample. diff --git a/samples/bluetooth/peripheral_mds/README.rst b/samples/bluetooth/peripheral_mds/README.rst index 08f51e13d256..afc898f3f9bd 100644 --- a/samples/bluetooth/peripheral_mds/README.rst +++ b/samples/bluetooth/peripheral_mds/README.rst @@ -21,8 +21,6 @@ The sample supports the following development kits: .. include:: /includes/tfm.txt -.. include:: /includes/hci_ipc_overlay.txt - Overview ******** diff --git a/samples/bluetooth/peripheral_power_profiling/README.rst b/samples/bluetooth/peripheral_power_profiling/README.rst index 6700b200d990..2706db3bd8d2 100644 --- a/samples/bluetooth/peripheral_power_profiling/README.rst +++ b/samples/bluetooth/peripheral_power_profiling/README.rst @@ -18,8 +18,6 @@ The sample supports the following development kits: .. table-from-sample-yaml:: -.. include:: /includes/hci_ipc_overlay.txt - Optionally, you can use the `Power Profiler Kit II (PPK2)`_ for power profiling and optimizing your configuration. You can use also your proprietary solution for measuring the power consumption. diff --git a/samples/bluetooth/throughput/README.rst b/samples/bluetooth/throughput/README.rst index b632eedf4c2f..756ddce389d5 100644 --- a/samples/bluetooth/throughput/README.rst +++ b/samples/bluetooth/throughput/README.rst @@ -21,8 +21,6 @@ The sample supports the following development kits: You can use any two of the development kits listed above and mix different development kits. -.. include:: /includes/hci_ipc_overlay.txt - The sample also requires a connection to a computer with a serial terminal |ANSI| for each of the development kits. Overview diff --git a/samples/bootloader/README.rst b/samples/bootloader/README.rst index 8563afb1450b..0f0fee7c916f 100644 --- a/samples/bootloader/README.rst +++ b/samples/bootloader/README.rst @@ -16,7 +16,7 @@ See :ref:`ug_bootloader` for more information about the full bootloader chain. .. note:: Currently, the NSIB does not support performing firmware updates over the SMP transport. - If the application using the NSIB requires SMP-based firmware updates, such as Bluetooth® LE DFU, :ref:`include MCUboot as a second-stage bootloader `. + If the application using the NSIB requires SMP-based firmware updates, such as Bluetooth® LE DFU, :ref:`include MCUboot as a second-stage bootloader `. .. _bootloader_rot: @@ -175,7 +175,7 @@ Building and running The NSIB is automatically added as a child image when the :kconfig:option:`CONFIG_SECURE_BOOT` Kconfig option is set in the application. -For building and running the NSIB with an application, see :ref:`ug_bootloader_adding_immutable`. +For building and running the NSIB with an application, see :ref:`ug_bootloader_adding_sysbuild_immutable`. Building and running using |VSC| ================================ @@ -207,11 +207,6 @@ To add the NSIB as a child image to your application, complete the following ste #. Select :guilabel:`Flash` in the :guilabel:`Actions View` to program the resulting image to your device. -Testing -======= - -See :ref:`ug_bootloader_testing` for testing of the expected runtime behavior of the NSIB when built with an application. - Dependencies ************