Add platform and linux terms to glossary

source/getting-started/emulation-with-qemu/index.rst

@@ -5,7 +5,7 @@ Emulation With QEMU
 
 .. note::
 
-  This tutorial is designed to assist you in getting started with using QEMU to emulate devices on your desktop.
+  This tutorial is designed to assist you in getting started with using :term:`QEMU` to emulate devices on your desktop.
   Please note that we are selecting a specific machine to establish an environment for experimenting with FoundriesFactory®.
   This approach will enable you to engage with subsequent tutorials and enhance your skills.
 
@@ -122,4 +122,4 @@ Next Step
 --------------------------
 
 At this point, you have successfully set up the device.
-You are now able to :ref:`gs-register` and proceed with the following tutorials.
+You are now able to :ref:`gs-register` and proceed with the following tutorials.

source/glossary/index.rst

@@ -12,7 +12,8 @@ Terminology
 
    Foundries.io
      Provider of FoundriesFactory® DevSecOps platform and the :term:`Linux microPlatform`\™ OS.
-     `Website <https://foundries.io>`_.
+
+     * `Website <https://foundries.io>`_
 
    Factory
      An instance of :term:`FoundriesFactory` tailored to your device and needs.
@@ -78,7 +79,7 @@ Terminology
      You can view the summary with ``fioctl targets list``, or view in full with ``fioctl targets list --raw``
 
    ``MACHINE``
-     The machine name, as configured in the Yocto Project meta-layer.
+     The machine name, as configured in the :term:`Yocto Project` meta-layer.
      Officially supported in FoundriesFactory if listed in :ref:`ref-linux-supported`.
 
    CA
@@ -197,7 +198,8 @@ Terminology
    TLS
    Transport Layer Security
      Cryptographic protocol for securing communication within a network.
-     See-also: :term:`mTLS`
+
+     * See-also: :term:`mTLS`
 
    TLS Handshake
      The procedure belonging to the :term:`TLS` protocol where the client and server agree on how to exchange information.
@@ -335,3 +337,205 @@ Terminology
       TUF Targets created during the CI builds and delivered to non-production devices during an OTA update.
 
       * :ref:`Reference Manual, CI Targets <ref-ci-targets>`
+
+   Bitbake
+      Similar in purpose to Make. Part of :term:`Open Embedded`/:term:`Yocto Project`.
+      It *bakes* :term:`recipes <Recipe>` into packages/images.
+
+      * :ref:`Custom CI User Guide, Bitbake Dev Container <ug-custom-ci-for-rootfs>`
+      * :ref:`LmP Customization User Guide, Building from Source <ref-linux-building>`
+      * :ref:`LmP Customization-extending User Guide, bitbake-getvar <ref-adding-packages-image>`
+      * :ref:`Updating the LmP Core Reference Manual, Using bitbake -e <ref-linux-update>`
+
+   BSP
+   Board Support Package
+      Software/data needed for specific hardware such as firmware and device drivers.
+      May come from a vendor or the community.
+
+      Within the Yocto Project, a "meta-bsp" :term:`layer` provides a BSP.
+      These generally follow the convention of ``meta-<board-name>``.
+      You can read more about BSP layers in the Yocto Project's `BSP developer guide <https://docs.yoctoproject.org/bsp-guide/bsp.html>`_
+
+      * :ref:`FoundriesFactory Porting Guide <ref-pg>`
+      * :ref:`Linux Layers Reference Manual, LmP BSP Layers <ref-linux-layers-meta-lmp-bsp-layers>`
+
+   Distro
+   Distribution
+      A collection of tools/files/software along with a Linux Kernel,
+      which form an Operating System to meet a given use case.
+      FoundriesFactory provides the :term:`LmP` distro.
+
+      In the context of the Yocto Project,
+      it also refers to the *file* containing the description of what the Linux Distribution should be.
+      The variable for setting the distribution is ``DISTRO``, which defaults to ``lmp``.
+
+      * :ref:`Reference Manual, LmP Distros <ref-linux-distro>`
+      * :ref:`LmP Customization Reference Manual, Customizing the Distro <ref-customizing-the-distro>`
+      * :ref:`Factory Definition Reference Manual, LmP Distro variable <ref-factory-definition>`
+
+   Layer
+      Openembedded/Yocto Project Layers.
+      A layer is a collection of related recipes/files.
+      Generally layers have the prefix `meta-`, such as  `meta-lmp`
+
+      * :ref:`Linux Layers Reference Manual <ref-linux-layers>`
+      * `Yocto Project: Understanding and Creating Layers <https://docs.yoctoproject.org/dev-manual/layers.html>`_
+
+   Open Embedded
+   OpenEmbedded-core
+      Build system used by the Yocto Project.
+
+      OpenEmbedded-core —or OE-Core— is the :term:`layer` containing the core Open Embedded metadata.
+
+      * `Open Embedded Website <https://www.openembedded.org/wiki/Main_Page>`_
+
+   Poky
+      Reference distro for the Yocto Project.
+      Meant for illustrative uses, not for Production purposes.
+
+   QEMU
+      **Q**\uick **Emu**\lator.
+      Open Source emulator covering common architectures.
+      FoundriesFactory supports the QEMU machines covered in our User-Guide.
+
+      * :ref:`User-Guide, QEMU <ref-qemu>`
+      * :ref:`Getting Started, Emulation with QEMU <gs-emulation-with-qemu>`
+      * `Official QEMU Documentation <https://www.qemu.org/docs/master/>`_
+
+   Recipe
+      A central Yocto Project concept,
+      recipes are the instructions and data for a software package read by Bitbake.
+
+      You can identify recipes by the ``.bb``  filename extension.  
+      A recipe can be modified/extended by using a ``.bbappend`` file.
+
+      A collection of related recipes is a :term:`layer`.
+
+      * :ref:`Customizing the Platform Tutorial, Creating a Recipe <tutorial-customizing-the-platform>`
+      * `Yocto Project Documentation: Understanding and Creating Layers <https://docs.yoctoproject.org/dev-manual/layers.html#understanding-and-creating-layers>`_
+      * `Yocto Project Documentation: Modifiying an Existing Recipe <https://docs.yoctoproject.org/kernel-dev/common.html#modifying-an-existing-recipe>`_
+
+   SDK
+   Software Development Kit
+      The Yocto Project Standard SDK is used for cross-development toolchain/libraries.
+      Generated for a specific image.
+
+      * :ref:`Reference Manual, Building the Yocto Project Standard SDK <ref-building-sdk>`
+      * `Yocto Project Documentation: Standard SDK Manual <https://docs.yoctoproject.org/sdk-manual/index.html>`_
+
+   Wic
+      Utility for creating partitioned OpenEmbedded :term:`images <Image>` (.wic)
+
+      * :ref:`Reference Manual, Wic image Installer <ref-linux-wic-installer>`
+      * `Yocto Project Documentation: Creating Partitioned Images Using Wic <https://docs.yoctoproject.org/dev/dev-manual/wic.html#creating-partitioned-images-using-wic>`_
+
+   WireGuard
+      Open Source protocol and software for VPNs.
+
+      * :ref:`WireGuard Reference Manual, FoundriesFactory WireGuard Setup <ref-wireguard>`
+      * `Official WireGuard Quick Start <https://www.wireguard.com/quickstart/>`_
+
+   Yocto Project
+      A collection of tools and processes for Embedded Linux creation and development.
+      Familiarity with the Yocto Project will aid with customizing the LmP.
+      The official documentation provides in-depth details and guides.
+
+      * `The Yocto Project Website <https://www.yoctoproject.org/>`_
+      * :ref:`Building From Source User Guide, Using The Yocto Project locally <ref-linux-building>`
+
+   Image
+      The final artifact of an Yocto Project build and appears in several contexts.
+      It can be the artifact resultant of an CI build, or a local build.
+      It can be a bootable image or part of an update.
+
+      * :ref:`Getting started: Flashing Your Device, Downloading and Flashing Factory Image <gs-flash-device>`
+      * :ref:`Custom CI User Guide, Creating System Image without CI <ug-custom-ci-for-rootfs>`
+      * :ref:`Building Linux User Guide, Building and Installing an Image Locally <ref-linux-building>`
+
+   Rootfs
+      The root file system is the collection of all the files and directories in the image. In this context, it is created by the Yocto Project tools and can be extended during the first build. It can be read-only or not.
+
+      * `Kernel rootfs Documentation <https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt>`_
+      * :ref:`Custom CI for RootFS User Guide <ug-custom-ci-for-rootfs>`
+      * :ref:`NFS Boot Reference Manual, <howto-linux-nfs-boot>`
+
+      Also see :term:`ostree`.
+
+   WKS
+      OpenEmbdded kickstart file. Used to create the :term:`Wic` partitioned image.
+
+      * `OpenEmbdded Kickstart Reference <https://docs.yoctoproject.org/ref-manual/kickstart.html>`_
+
+   Machine
+      In the context of the Yocto Project/Open Embedded, the device target to build an image for.
+      Defined by the variable ``MACHINE`` in ``local.conf``  within a Yocto Project build directory,
+      via a script/configuration tool.
+
+      For LmP, the target device to build an image for gets defined within the Factory Definition.
+
+      * :ref:`Building From Source Reference Manual, Setup Work Environment; MACHINE target <ref-linux-building-install>`
+      * :ref:`Factory Definition Reference Manual, Machine Name <def-lmp>`
+
+   UUU
+   Universal Update Utility 
+      A manufacturing tool designed to flash i.MX boards with a given image.
+      :term:`mfgtools` uses configuration files with the ``.uuu`` extension. 
+
+      * `UUU GitHub Repository <https://github.com/nxp-imx/mfgtools>`_ 
+      * :ref:`i.MX HABv4 Secure Boot Security Reference Manual, Programming the A7 fuses with UUU <ref-secure-boot-imx-habv4>`
+      * :ref:`i.MX AHAB Secure Boot Security Reference Manual, Closing the board Using UUU <ref-secure-boot-imx-ahab>`
+
+   SE050
+      The EdgeLock SE05x Secure Element.
+
+      * :ref:`ref-secure-element`
+      * :ref:`Security Reference Manual, SE05x Enablement <ref-security_se05x_enablement>`
+
+   EVK
+      Evaluation kit.
+      A board/hardware used for evaluating and developing before production.
+
+   target
+      The name of resultant CI build.
+      The kind of artifact generated by the CI build depends on which build is it.
+      In the context of the Yocto Project, the machine/architecture artifacts to build for.
+
+   Repo
+      Tool for projects with multiple git repositories.
+
+      * :ref:`Repo Source Control Tool, Repo and the LmP <ref-linux-repo>`
+      * :ref:`Building Linux User Guide, Downloading Layers with Repo <ref-linux-building>`
+      * `Official Homepage for Repo <https://gerrit.googlesource.com/git-repo>`_
+
+      Note that "repo" is also used as shorthand for repository.
+
+   Manifest
+      A  manifest repository containing a manifest file for the :term:`Repo tool <Repo>`
+      The manifest file is ``default.xml`` and contains the other repositories used.
+      The LmP manifest repository is ``lmp-manifest.git`` which is part of all Factories.
+
+      * :ref:`Repo Source Control Tool, Repo and the LmP <ref-linux-repo>`
+
+   ``FIO``
+      Foundries.io Git development tags used for upstream patches.
+
+      * :ref:`ref-development-tags`
+
+   Fragments
+      Kernel configuration fragments are Linux kernel configuration options outside a Linux Kernel ``.config``.
+      These get applied by the OpenEmbedded build system.
+
+      * :ref:`LmP Linux Kernel Reference Manual, LmP Kernel Configuration Fragments <ref-linux-fragments>`
+
+   RPMB
+      Replay Protected Memory Block.
+      Used as secure storage.
+
+      * :ref:`Machines with Secure Aspects Enabled Reference Manual, Accessing RPMB Secure Storage <ref-secure-machines>`
+
+   mfgtools 
+      Freescale/NXP® I.MX Chip tools.
+      Also see :term:`UUU`.
+
+      * `mfgtools GitHub Repository <https://github.com/nxp-imx/mfgtools>`_
+

source/porting-guide/pg-distro-lmp-base.rst

@@ -3,12 +3,12 @@
 ``DISTRO lmp-base`` for Easy Kernel Image Access
 ---------------------------------------------------
 
-The default distro used by a Factory is ``lmp``.
+The default :term:`distro` used by a Factory is ``lmp``.
 It is designed to provide the secure and updatable environment needed for the operation of an end product.
 However, this distro configuration is not ideal during the porting process.
 Therefore we also support another distro configuration: ``lmp-base``.
 This provides an easier development environment,
-as it has a boot directory which includes the Linux Kernel image and the DTB file, and a read-writable rootfs.
+as it has a boot directory which includes the Linux Kernel image and the DTB file, and a read-writable :term:`rootfs`.
 See detailed information on how lmp and lmp-base differ under :ref:`ref-linux-distro`.
 
 In the following sections, the focus is on the boot flow (1) shown previous on :numref:`ref-pg-boot-flow-diagram`.

source/porting-guide/pg-reference.rst

@@ -16,4 +16,4 @@ The suggestion here is to prefer the machine from the SoC vendor.
 
 The SoC vendor is usually present on the tag ``@NAME`` in the machine configuration file.
 
-In this document, there are several examples where i.MX8M Mini EVK is used as a reference board.
+In this document, there are several examples where i.MX8M Mini :term:`EVK` is used as a reference board.

source/reference-manual/factory/factory-definition.rst

@@ -72,7 +72,7 @@ tuf:
 lmp
 ---
 
-Configures the LmP aspects of the Factory, including images, distro, and machine names.
+Configures the LmP aspects of the Factory, including images, distro, and :term:`machine` names.
 Variables to be used with metadata and artifacts.
 
 .. sidebar:: ``lmp:`` Section Example

source/reference-manual/linux/building-sdk.rst

@@ -3,7 +3,7 @@
 Building The Yocto Project Standard SDK
 =======================================
 
-The Yocto Project Standard SDK is a development environment composed by:
+The Yocto Project Standard :term:`SDK` is a development environment composed by:
 
 * toolchain
 * debug tools
@@ -12,7 +12,7 @@ The Yocto Project Standard SDK is a development environment composed by:
 The SDK is used to replicate the tools and files from the target image,
 but without depending on BitBake.
 For details on what the SDK is, and a complete description of how to work with it,
-visit `Yocto Project Application Development and the Extensible Software Development Kit <https://docs.yoctoproject.org/kirkstone/sdk-manual/index.html>`_.
+visit `Yocto Project Application Development and the Extensible Software Development Kit <https://docs.yoctoproject.org/sdk-manual/index.html>`_.
 
 The LmP can be configured to create an SDK install script of the same rootfs image built by the CI.
 The SDK install script is created by ``bitbake <image> -c populate_sdk``.

source/reference-manual/linux/factory-device-reset.rst

@@ -51,4 +51,4 @@
 RPMB
 ~~~~
 
-Currently, ``RPMB`` is not cleared in either reset procedures.
+Currently, :term:`RPMB` is not cleared in either reset procedures.

source/reference-manual/linux/linux-disk-encryption.rst

@@ -23,7 +23,7 @@
 By enrolling the KEK this way, the system gains the capability of
 unlocking the volume seamlessly, without requiring any user involvement.
 
-Once the KEK has been enrolled, LmP marks the rootfs volume for disk
+Once the KEK has been enrolled, LmP marks the :term:`rootfs` volume for disk
 `re-encryption`_, mounts it and allows the system to continue with the
 boot sequence. This is know in LUKS terminology as ``online
 re-encryption``.

source/reference-manual/linux/linux-kernel.rst

@@ -13,10 +13,10 @@ The kernel recipe can be found within the :ref:`meta-lmp layer <ref-linux-layers
 LmP Kernel Configuration Fragments
 ----------------------------------
 
-Together with the unified Linux Kernel tree, the LmP provides an additional repository for kernel configuration fragments.
+Together with the unified Linux Kernel tree, the LmP provides an additional repository for :term:`kernel configuration fragments <Fragments>`.
 The latest continuous release of the kernel configuration fragments is available at `lmp-kernel-cache <https://github.com/foundriesio/lmp-kernel-cache>`_.
 
-You can find the list of supported BSP definitions and the configuration fragments used under ``lmp-kernel-cache/bsp``.
+You can find the list of supported :term:`BSP` definitions and the configuration fragments used under ``lmp-kernel-cache/bsp``.
 
 The fragments repository works similarly to the upstream ``yocto-kernel-cache`` repository.
 As such, the same development workflow and documentation applies.

source/reference-manual/linux/linux-layers.rst

@@ -4,7 +4,7 @@ OpenEmbedded / Yocto Project Layers
 ===================================
 
 The Linux® microPlatform (LmP) is composed of several OpenEmbedded and Yocto Project layers,
-including the core build system, distribution, images, and Board Support Packages (BSPs).
+including the core build system, distribution, images, and :term:`Board Support Packages <Board Support Package>` (BSPs).
 
 .. _ref-linux-layers-meta-lmp-base-layers:
 
@@ -84,7 +84,7 @@ You can find the default set of packages used by the image via the ``CORE_IMAGE_
 The meta-lmp-bsp Layer
 --------------------------------------
 
-``meta-lmp-bsp`` provides the kernel recipes, u-boot configuration fragments, WIC files, and so on for supported targets.
+``meta-lmp-bsp`` provides the kernel recipes, u-boot configuration fragments, :term:`WIC` files, and so on for supported :term:`targets <target>`.
 
 While primarily used as an extension of the vendor BSP layers (e.g. meta-freescale),
 it can also handle board configuration for cases where the vendor layer is not easily compatible with LmP (e.g. a layer based on an older Yocto Project release).

source/reference-manual/linux/linux-repo.rst

@@ -8,7 +8,7 @@ This section describes `Repo`_ and how the Linux® microPlatform uses it.
 A Linux microPlatform (LmP) build tree installation contains multiple Git repositories.
 These are managed by a *manifest file* in a *Repo manifest repository*.
 
-Your Factory's  manifest repository's name is ``lmp-manifest``.
+Your Factory's manifest repository's name is ``lmp-manifest``.
 In :ref:`ref-linux-building`, `repo init`_ is given the URL for the manifest repository.
 
 The manifest repository contains a manifest file, named ``default.xml``.

source/reference-manual/linux/linux-wic-installer.rst

@@ -18,7 +18,7 @@
   # WIC-based installer for the generic-arm64 target
   WKS_FILE:generic-arm64:sota = "image-efi-installer.wks.in"
 
-WIC is only capable of consuming a single WKS file (even if multiple are defined via ``WKS_FILES``).
+WIC is only capable of consuming a single :term:`WKS` file (even if multiple are defined via ``WKS_FILES``).
 Doing this forces the build system to only generate installer images.
 
 Remove the custom ``WKS_FILE:sota`` override to restore the default behavior and generate normal bootable WIC images.

source/reference-manual/security/boot-software-updates-imx.rst

@@ -216,9 +216,9 @@ This is done by adding the following config options to ``lmp.cfg``:
 MfgTool Scripts
 ^^^^^^^^^^^^^^^
 
-To deploy boot images to the destination board, the mfgtools package is used.
+To deploy boot images to the destination board, the :term:`mfgtools` package is used.
 It uses a special configuration file with ``uuu`` extensions, which contains all instructions needed for the deployment of boot images.
-Default uuu files do not support flashing images for secondary boot path.
+Default :term:`uuu` files do not support flashing images for secondary boot path.
 Doing so requires the following adjustments: adding SIT image, secondary SPL, and U-Boot FIT deployment steps:
 
 ::

source/reference-manual/security/imx-generic-custom-keys.rst

@@ -92,7 +92,7 @@ The result of ``git status`` should look like::
           new file:   recipes-support/mfgtool-files/mfgtool-files/<machine>/fuse.uuu
           new file:   recipes-support/mfgtool-files/mfgtool-files_%.bbappend
 
-The changes add the UUU scripts to the ``mfgtool-files`` artifacts of next targets.
+The changes add the :term:`UUU` scripts to the ``mfgtool-files`` artifacts of next targets.
 Run the ``fuse.uuu`` and ``close.uuu`` to fuse the custom keys and close the board, respectively.
 
 .. warning::

source/reference-manual/security/secure-boot-imx-habv4.rst

@@ -124,7 +124,7 @@ For the M4 fuses it would look like this::
 	=> fuse prog 6 6 0xA71BBE78
 	=> fuse prog 6 7 0xA3AD024A
 
-Alternatively, you can use the kernel to program the A7 fuses via SDP by using NXP's Universal Update Utility.
+Alternatively, you can use the kernel to program the A7 fuses via SDP by using NXP's :term:`Universal Update Utility`.
 This is shown in the following script (replace ``@@MACHINE@@`` with your machine name)::
 
 	uuu_version 1.0.1