doc: HWMv2: align board terminology

Changed `build target` to `board target` as per HWMv2 terminology. Updated leftover v1 board target names. Updated glossary. Updated board names page with some additional info and links to Zephyr. Signed-off-by: Grzegorz Ferenc <[email protected]>
nrfconnect · May 24, 2024 · de6a369 · de6a369
1 parent 397a2f8
commit de6a369
Show file tree

Hide file tree

Showing 110 changed files with 406 additions and 373 deletions.
diff --git a/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst b/applications/asset_tracker_v2/doc/asset_tracker_v2_description.rst
@@ -106,8 +106,8 @@ The application provides predefined configuration files for typical use cases.
 
 Following are the available configuration files:
 
-* :file:`prj.conf` - Configuration file for all build targets.
-* :file:`boards/<BOARD>.conf` - Configuration file specific for a build target specified with **<BOARD>**, where **<BOARD>** is the build target, for example ``nrf9161dk/nrf9161/ns``.
+* :file:`prj.conf` - Configuration file for all board targets.
+* :file:`boards/<BOARD>.conf` - Configuration file specific for a board target specified with **<BOARD>**, where **<BOARD>** is the board target, for example ``nrf9161dk/nrf9161/ns``.
   This file is automatically merged with the :file:`prj.conf` file when you build for that target.
 
 The :file:`include/<BOARD>/led_state_def.h` header file describes the LED behavior of the CAF LEDs module.
@@ -135,10 +135,10 @@ Multiple overlay files can be included to enable multiple features at the same t
 
    Generally, Kconfig overlays have an ``overlay-`` prefix and a :file:`.conf` extension.
    Board-specific configuration files are placed in the :file:`boards` folder and are named as :file:`<BOARD>.conf`.
-   DTS overlay files are named the same as the build target and use the file extension :file:`.overlay`.
-   When they are placed in the :file:`boards` folder and the DTS overlay filename matches the build target,
-   the build system automatically selects and applies the overlay.
-   You can give the custom DTS overlay files as a compiler option ``-DEXTRA_DTC_OVERLAY_FILE=<dtc_filename>.overlay``.
+
+   The devicetree overlay files use the :ref:`normalized board target name <app_boards_names>` and the file extension :file:`.overlay` (for example, ``nrf9160dk/nrf9160`` becomes :file:`nrf9160dk_nrf9160.overlay`).
+   When they are placed in the :file:`boards` folder and the DTS overlay filename matches the board target (after normalization), the build system automatically selects and applies the overlay.
+   To select them manually, see :ref:`cmake_options`.
 
 Optional library configurations
 ===============================

diff --git a/applications/asset_tracker_v2/doc/location_module.rst b/applications/asset_tracker_v2/doc/location_module.rst
@@ -72,9 +72,9 @@ The following is an example of the CLI command:
 .. parsed-literal::
    :class: highlight
 
-    west build -p -b *build_target* -- -DSHIELD=nrf7002ek -DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf
+    west build -p -b *board_target* -- -DSHIELD=nrf7002ek -DEXTRA_CONF_FILE=overlay-nrf7002ek-wifi-scan-only.conf
 
-Replace the *build_target* with the build target of the DK you are using (see :ref:`asset_tracker_v2_requirements`).
+Replace the *board_target* with the board target of the DK you are using (see :ref:`asset_tracker_v2_requirements`).
 
 Wi-Fi positioning has the following limitations:
 

diff --git a/applications/machine_learning/app_desc.rst b/applications/machine_learning/app_desc.rst
@@ -326,7 +326,7 @@ The application supports the following build types:
 
    * - Build type
      - File name
-     - Supported build target
+     - Supported board target
      - Description
    * - Debug (default)
      - :file:`prj.conf`

diff --git a/applications/matter_bridge/doc/matter_bridge_description.rst b/applications/matter_bridge/doc/matter_bridge_description.rst
@@ -87,9 +87,9 @@ When building on the command line, run the following command:
 .. parsed-literal::
    :class: highlight
 
-   west build -b *build_target* -- *dfu_build_flag*
+   west build -b *board_target* -- *dfu_build_flag*
 
-Replace *build_target* with the build target name of the hardware platform you are using (see `Requirements`_), and *dfu_build_flag* with the desired DFU build flag.
+Replace *board_target* with the board target name of the hardware platform you are using (see `Requirements`_), and *dfu_build_flag* with the desired DFU build flag.
 For example:
 
 .. code-block:: console

diff --git a/applications/matter_weather_station/README.rst b/applications/matter_weather_station/README.rst
@@ -46,8 +46,8 @@ IPv6 network support
 
 The development kits for this sample offer the following IPv6 network support for Matter:
 
-* Matter over Thread is supported for ``thingy53_nrf5340_cpuapp``.
-* Matter over Wi-Fi is supported for ``thingy53_nrf5340_cpuapp`` with the ``nrf7002`` expansion board attached, for the :file:`prj_release.conf` build type only.
+* Matter over Thread is supported for ``thingy53/nrf5340/cpuapp``.
+* Matter over Wi-Fi is supported for ``thingy53/nrf5340/cpuapp`` with the ``nrf7002`` expansion board attached, for the :file:`prj_release.conf` build type only.
   See `Building for the nRF7002 Wi-Fi expansion board`_ for more information.
 
 Overview
@@ -172,7 +172,7 @@ The application comes with the following overlays:
 
   .. code-block:: console
 
-      west build -b thingy53_nrf5340_cpuapp -- -DEXTRA_CONF_FILE=overlay-factory_data.conf -DPM_STATIC_YML_FILE=pm_static_factory_data.yml
+      west build -b thingy53/nrf5340/cpuapp -- -DEXTRA_CONF_FILE=overlay-factory_data.conf -DPM_STATIC_YML_FILE=pm_static_factory_data.yml
 
 .. note::
    Matter factory data support requires the dedicated partition layout.
@@ -212,21 +212,21 @@ To build this application to work with the nRF7002 Wi-Fi expansion board:
 
          .. code-block:: console
 
-            west build -b thingy53_nrf5340_cpuapp -- -DSHIELD=nrf7002eb -DFILE_SUFFIX=release
+            west build -b thingy53/nrf5340/cpuapp -- -DSHIELD=nrf7002eb -DFILE_SUFFIX=release
 
 Generating factory data
 =======================
 
 To enable factory data support, you need to select the ``overlay-factory_data`` configuration overlay from the available application :ref:`build configuration overlays <matter_weather_station_app_build_configuration_overlays>`.
-You can generate new factory data set when building for the target board by invoking the following command:
+You can generate new factory data set when building for the given board target by invoking the following command:
 
 .. parsed-literal::
    :class: highlight
 
-   west build -b thingy53_nrf5340_cpuapp -- -DEXTRA_CONF_FILE=overlay-factory_data.conf
+   west build -b thingy53/nrf5340/cpuapp -- -DEXTRA_CONF_FILE=overlay-factory_data.conf
 
 This command builds the application with default certificates.
-After building the target, the generated :file:`factory_data.hex` file will be merged with the application target HEX file, so you can use the :ref:`regular command to flash it to the device <programming>`.
+After building for the board target, the generated :file:`factory_data.hex` file will be merged with the application target HEX file, so you can use the :ref:`regular command to flash it to the device <programming>`.
 
 If you want to use Vendor ID, Product ID or other data that is not reserved for tests, you need custom test certificates.
 To build with custom certificates, you need to :ref:`install CHIP Certificate Tool <ug_matter_gs_tools_cert_installation>`.

diff --git a/applications/nrf_desktop/description.rst b/applications/nrf_desktop/description.rst
@@ -392,7 +392,7 @@ The application supports the following build types:
 
    * - Build type
      - File name
-     - Supported build target
+     - Supported board target
      - Description
    * - Debug (default)
      - :file:`prj.conf`
@@ -1023,7 +1023,7 @@ To build an application for evaluating HID report rate, run the following comman
    .. parsed-literal::
       :class: highlight
 
-      west build -p -b *build_target* -- \
+      west build -p -b *board_target* -- \
       -DFILE_SUFFIX=release \
       -DCONFIG_DESKTOP_MOTION_SIMULATED_ENABLE=y \
 

diff --git a/applications/nrf_desktop/doc/config_channel.rst b/applications/nrf_desktop/doc/config_channel.rst
@@ -193,8 +193,9 @@ Module discovery operations
   * ``CONFIG_STATUS_GET_HWID`` - Obtain a unique Hardware ID of the device.
     The Hardware ID is represented as 8 bytes.
   * ``CONFIG_STATUS_GET_BOARD_NAME`` - Obtain the device's board name.
-    The board name is part of the Zephyr board name (:kconfig:option:`CONFIG_BOARD`) from a beginning to the first underscore (``_``) character.
-    For example, the ``nrf52840gmouse/nrf52840`` build target would return ``nrf52840gmouse`` as the board name.
+    The board name is part of the Zephyr board target name (:kconfig:option:`CONFIG_BOARD`) from a beginning to the first underscore (``/``) character.
+    For example, the ``nrf52840gmouse/nrf52840`` board target would return ``nrf52840gmouse`` as the board name.
+    See :ref:`app_boards_names` for more information.
 
   .. note::
      You must use :ref:`nrf_desktop_info` for every device that is configurable with the configuration channel.

diff --git a/applications/serial_lte_modem/doc/slm_description.rst b/applications/serial_lte_modem/doc/slm_description.rst
@@ -288,7 +288,7 @@ You can find the configuration files in the :file:`applications/serial_lte_modem
 
 In general, they have an ``overlay-`` prefix, and a :file:`.conf` or :file:`.overlay` extension for Kconfig or devicetree overlays, respectively.
 Board-specific configuration files are named :file:`<BOARD>` with a :file:`.conf` or :file:`.overlay` extension and are located in the :file:`boards` directory.
-When the name of the board-specific configuration file matches the build target, the overlay is automatically included by the build system.
+When the name of the board-specific configuration file matches the board target, the overlay is automatically included by the build system.
 
 See :ref:`app_build_system`: for more information on the |NCS| configuration system.
 
@@ -330,13 +330,13 @@ The following configuration files are provided:
   See :ref:`slm_as_zephyr_modem` for more information.
 
 * :file:`boards/nrf9160dk_nrf9160_ns.conf` - Configuration file specific for the nRF9160 DK.
-  This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9160dk/nrf9160/ns`` build target.
+  This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9160dk/nrf9160/ns`` board target.
 
 * :file:`boards/nrf9161dk_nrf9161_ns.conf` - Configuration file specific for the nRF9161 DK.
-  This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9161dk/nrf9161/ns`` build target.
+  This file is automatically merged with the :file:`prj.conf` file when you build for the ``nrf9161dk/nrf9161/ns`` board target.
 
 * :file:`boards/thingy91_nrf9160_ns.conf` - Configuration file specific for Thingy:91.
-  This file is automatically merged with the :file:`prj.conf` file when you build for the ``thingy91/nrf9160/ns`` build target.
+  This file is automatically merged with the :file:`prj.conf` file when you build for the ``thingy91/nrf9160/ns`` board target.
 
 .. _slm_native_tls:
 

diff --git a/boards/shields/pca63565/doc/index.rst b/boards/shields/pca63565/doc/index.rst
@@ -29,7 +29,7 @@ I2C interface:
 Requirements
 ************
 
-This shield is pin compatible with nrf54l15pdk (tested with PCA10156 rev.0.2.1).
+This shield is pin compatible with the nRF54L15 PDK (tested with PCA10156 rev.0.2.1).
 
 Usage
 *****

diff --git a/doc/nrf/config_and_build/board_support/board_names.rst b/doc/nrf/config_and_build/board_support/board_names.rst
@@ -8,23 +8,40 @@ Board names
    :local:
    :depth: 2
 
-The following tables list all boards and build targets for Nordic Semiconductor's hardware platforms.
+The following tables list all boards and corresponding board targets for Nordic Semiconductor's hardware platforms.
 
-The build target column uses several entries for multi-core hardware platforms:
+The board targets follow Zephyr's :ref:`zephyr:board_terminology` scheme and are used mostly when :ref:`building`.
+For example, the board target ``[email protected]/nrf54l15/cpuapp`` can be read as made of the following elements:
 
-* For core type:
++-------------+----------------+-------------------------+---------------------------------+--------------------------------------------------+
+| nrf54l15pdk |     @0.3.0     |        /nrf54l15        |             /cpuapp             |                                                  |
++=============+================+=========================+=================================+==================================================+
+| Board name  | Board revision | Board qualifier for SoC | Board qualifier for CPU cluster | Board qualifier for variant (empty in this case) |
++-------------+----------------+-------------------------+---------------------------------+--------------------------------------------------+
 
-  * ``cpuapp`` - When you choose this target, you build the application core firmware.
-  * ``cpunet`` - When you choose this target, you build the network core firmware.
+While the board name is always present, other elements, such as the board revision or the board qualifiers, are optional:
 
-* For usage of Cortex-M Security Extensions (CMSE):
+* :ref:`Board revision <zephyr:glossary>` - You can use the *board_name@board_revision* board target to get extra devicetree overlays with new features available for a specific board version.
+  The board version is printed on the label of your DK, just below the PCA number.
+  For example, :ref:`building <building>` for the ``[email protected]/nrf9160`` board target adds the external flash on the nRF9160 DK that was available since :ref:`board version v0.14.0 <nrf9160_board_revisions>`.
 
-  * Entries without ``*/ns`` (``cpuapp``) - When you choose this target, you build the application core firmware as a single execution environment that does not use CMSE (:ref:`Trusted Firmware-M (TF-M) <ug_tfm>`).
+* :term:`System on Chip (SoC)` - When you choose a board target with this qualifier, you build for this specific SoC on this board.
+  For example, :ref:`building <building>` for the ``thingy53/nrf5340/cpuapp`` board target builds the application core firmware for the nRF5340 SoC on the Nordic Thingy:53 prototyping platform.
+
+* :ref:`CPU cluster <zephyr:glossary>` - You can use this board qualifier to build for a group of one or more CPU cores, all executing the same image within the same address space and in a symmetrical (SMP) configuration.
+  The CPU cluster board qualifier varies depending on the SoC and SoC Series.
+  For example, :ref:`building <building>` for the ``thingy53/nrf5340/cpunet`` board target builds the network core firmware for Nordic Thingy:53, building for ``nrf54h20dk/nrf54h20/cpuapp`` builds the application core firmware for the nRF54H20 DK, building for ``nrf54h20dk/nrf54h20/cpurad`` builds the radio core firmware for the nRF54H20 DK, and so on.
+  Check the Product Specification of the given SoC for more information about the available CPU clusters.
+
+* :ref:`Variant <zephyr:glossary>` - You can use this board qualifier to build for a particular type or configuration of a build for a combination of SoC and CPU cluster.
+  In the |NCS|, variants are used for indicating the usage of Cortex-M Security Extensions (CMSE):
+
+  * Entries without ``*/ns`` - When you choose this target, you build the application core firmware as a single execution environment that does not use CMSE (:ref:`Trusted Firmware-M (TF-M) <ug_tfm>`).
   * Entries with ``*/ns`` (for example, ``cpuapp/ns``) - When you choose this target, you build the application with CMSE.
     The application core firmware is placed in Non-Secure Processing Environment (NSPE) and uses Secure Processing Environment (SPE) for security features.
     By default, the build system automatically includes :ref:`Trusted Firmware-M (TF-M) <ug_tfm>` in SPE and merges it with NSPE.
 
-Read more about separation of processing environments on the :ref:`app_boards_spe_nspe` page.
+  Read more about separation of processing environments on the :ref:`app_boards_spe_nspe` page.
 
 .. _app_boards_names_zephyr:
 
@@ -40,7 +57,7 @@ Also see the :ref:`zephyr:boards` section in the Zephyr documentation.
 .. _table:
 
 +-------------------+------------+-------------------------------------------------------------------+---------------------------------------+
-| Hardware platform | PCA number | Board name                                                        | Build target                          |
+| Hardware platform | PCA number | Board name                                                        | Board targets                         |
 +===================+============+===================================================================+=======================================+
 | nRF9161 DK        | PCA10153   | :ref:`nrf9161dk <zephyr:nrf9161dk_nrf9161>`                       | ``nrf9161dk/nrf9161``                 |
 |                   |            |                                                                   |                                       |
@@ -108,8 +125,8 @@ Also see the :ref:`zephyr:boards` section in the Zephyr documentation.
 .. note::
    In |NCS| releases before v1.6.1:
 
-   * The build target ``nrf9160dk/nrf9160/ns`` was named ``nrf9160dk_nrf9160ns``.
-   * The build target ``nrf5340dk/nrf5340/cpuapp/ns`` was named ``nrf5340dk_nrf5340_cpuappns``.
+   * The board target ``nrf9160dk/nrf9160/ns`` was named ``nrf9160dk_nrf9160ns``.
+   * The board target ``nrf5340dk/nrf5340/cpuapp/ns`` was named ``nrf5340dk_nrf5340_cpuappns``.
 
 .. _app_boards_names_nrf:
 
@@ -119,7 +136,7 @@ Boards included in sdk-nrf
 The following boards are defined in the :file:`nrf/boards/nordic/` folder.
 
 +-------------------+------------+----------------------------------------------------------+---------------------------------------+
-| Hardware platform | PCA number | Board name                                               | Build target                          |
+| Hardware platform | PCA number | Board name                                               | Board targets                         |
 +===================+============+==========================================================+=======================================+
 | nRF Desktop       | PCA20041   | :ref:`nrf52840gmouse <nrf_desktop>`                      | ``nrf52840gmouse/nrf52840``           |
 | Gaming Mouse      |            |                                                          |                                       |
@@ -160,7 +177,7 @@ Shields included in sdk-nrf
 The following shields are defined in the :file:`nrf/boards/shields` folder.
 
 +----------------------------------------------------------+------------+--------------------------------------------------------------------------+---------------------------------------+
-| Hardware platform                                        | PCA number | Board name                                                               | Build target                          |
+| Hardware platform                                        | PCA number | Board name                                                               | Board targets                         |
 +==========================================================+============+==========================================================================+=======================================+
 | nRF7002 :term:`Evaluation Kit (EK)`                      | PCA63556   | :ref:`nrf7002ek <ug_nrf7002ek_gs>`                                       | ``nrf7002ek``                         |
 +----------------------------------------------------------+------------+--------------------------------------------------------------------------+---------------------------------------+

diff --git a/doc/nrf/config_and_build/board_support/index.rst b/doc/nrf/config_and_build/board_support/index.rst
@@ -3,10 +3,12 @@
 Board support
 #############
 
-The |NCS| provides board definitions for all Nordic Semiconductor devices.
-These are in tables on the :ref:`app_boards_names` page, listed by :ref:`app_boards_names_zephyr`, :ref:`app_boards_names_nrf`, and :ref:`shield_names_nrf`.
+The |NCS| provides board definitions for all Nordic Semiconductor devices and follows Zephyr's :ref:`zephyr:hw_support_hierarchy`.
 
-Some boards can support Cortex-M Security Extensions (CMSE), which results in separation of :ref:`app_boards_spe_nspe`.
+For the complete list, see the tables on the :ref:`app_boards_names` page, listed by :ref:`app_boards_names_zephyr`, :ref:`app_boards_names_nrf`, and :ref:`shield_names_nrf`.
+You can select the board targets for these boards when :ref:`building`.
+
+Some boards can support Cortex-M Security Extensions (CMSE), with their board targets separated for different :ref:`app_boards_spe_nspe`.
 
 In addition, you can :ref:`define custom boards <defining_custom_board>`.