diff --git a/source/getting-started/emulation-with-qemu/index.rst b/source/getting-started/emulation-with-qemu/index.rst index f6b49c7ed..94c73da56 100644 --- a/source/getting-started/emulation-with-qemu/index.rst +++ b/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. \ No newline at end of file +You are now able to :ref:`gs-register` and proceed with the following tutorials. diff --git a/source/glossary/index.rst b/source/glossary/index.rst index 9a46a92c5..c70e9dbb1 100644 --- a/source/glossary/index.rst +++ b/source/glossary/index.rst @@ -12,7 +12,8 @@ Terminology Foundries.io Provider of FoundriesFactory® DevSecOps platform and the :term:`Linux microPlatform`\™ OS. - `Website `_. + + * `Website `_ 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 ` + + Bitbake + Similar in purpose to Make. Part of :term:`Open Embedded`/:term:`Yocto Project`. + It *bakes* :term:`recipes ` into packages/images. + + * :ref:`Custom CI User Guide, Bitbake Dev Container ` + * :ref:`LmP Customization User Guide, Building from Source ` + * :ref:`LmP Customization-extending User Guide, bitbake-getvar ` + * :ref:`Updating the LmP Core Reference Manual, Using bitbake -e ` + + 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-``. + You can read more about BSP layers in the Yocto Project's `BSP developer guide `_ + + * :ref:`FoundriesFactory Porting Guide ` + * :ref:`Linux Layers Reference Manual, 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:`LmP Customization Reference Manual, Customizing the Distro ` + * :ref:`Factory Definition Reference Manual, LmP Distro variable ` + + Layer + Openembedded/Yocto Project Layers. + A layer is collection of related recipes/files. + Generally layers have the prefix `meta-`, such as `meta-lmp` + + * :ref:`Linux Layers Reference Manual ` + * `Yocto Project: Understanding and Creating Layers `_ + + 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 `_ + + 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:`Getting Started, Emulation with QEMU ` + * `Official QEMU Documentation `_ + + 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 ` + * `Yocto Project Documentation: Understanding and Creating Layers `_ + * `Yocto Project Documentation: Modifiying 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 ` + * `Yocto Project Documentation: Standard SDK Manual `_ + + Wic + Utility for creating partitioned OpenEmbedded :term:`images ` (.wic) + + * :ref:`Reference Manual, Wic image Installer ` + * `Yocto Project Documentation: Creating Partitioned Images Using Wic `_ + + WireGuard + Open Source protocol and software for VPNs. + + * :ref:`WireGuard Reference Manual, FoundriesFactory WireGuard Setup ` + * `Official WireGuard Quick Start `_ + + 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 `_ + * :ref:`Building From Source User Guide, Using The Yocto Project locally ` + + 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 ` + * :ref:`Custom CI User Guide, Creating System Image without CI ` + * :ref:`Building Linux User Guide, Building and Installing an Image Locally ` + + Rootfs + Rootfs belongs to the init system. + + * `Kernel rootfs Documentation `_ + * :ref:`Custom CI for RootFS User Guide ` + * :ref:`NFS Boot Reference Manual, ` + + Also see :term:`ostree`. + + WKS + OpenEmbdded kickstart file. Used to create the :term:`Wic` partitioned image. + + * `OpenEmbdded Kickstart Reference `_ + + 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 machine to build an image for gets defined within the Factory Definition. + + * :ref:`Building From Source Reference Manual, Setup Work Environment; MACHINE target ` + * :ref:`Factory Definition Reference Manual, Machine Name ` + + 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 `_ + * :ref:`i.MX HABv4 Secure Boot Security Reference Manual, Programming the A7 fuses with UUU ` + * :ref:`i.MX AHAB Secure Boot Security Reference Manual, Closing the board Using UUU ` + + SE050 + The EdgeLock SE05x Secure Element. + + * :ref:`ref-secure-element` + * :ref:`Security Reference Manual, 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:`Building Linux User Guide, Downloading Layers with Repo ` + * `Official Homepage for Repo `_ + + Note that "repo" is also used as shorthand for repository. + + Manifest + A manifest repository containing a manifest file for the :term:`Repo tool ` + 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 ` + + ``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 ` + + RPMB + Replay Protected Memory Block. + Used as secure storage. + + * :ref:`Machines with Secure Aspects Enabled Reference Manual, Accessing RPMB Secure Storage ` + + mfgtools + Freescale/NXP® I.MX Chip tools. + Also see :term:`UUU`. + + * `mfgtools GitHub Repository `_ + diff --git a/source/porting-guide/pg-distro-lmp-base.rst b/source/porting-guide/pg-distro-lmp-base.rst index 90e934157..b305c92c6 100644 --- a/source/porting-guide/pg-distro-lmp-base.rst +++ b/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`. diff --git a/source/porting-guide/pg-reference.rst b/source/porting-guide/pg-reference.rst index 71d781f31..bac4133fb 100644 --- a/source/porting-guide/pg-reference.rst +++ b/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. diff --git a/source/reference-manual/factory/factory-definition.rst b/source/reference-manual/factory/factory-definition.rst index 8bdc968a0..6cac88e0e 100644 --- a/source/reference-manual/factory/factory-definition.rst +++ b/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 diff --git a/source/reference-manual/linux/building-sdk.rst b/source/reference-manual/linux/building-sdk.rst index f756564ed..6b82ceefb 100644 --- a/source/reference-manual/linux/building-sdk.rst +++ b/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 `_. +visit `Yocto Project Application Development and the Extensible Software Development Kit `_. 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 -c populate_sdk``. diff --git a/source/reference-manual/linux/factory-device-reset.rst b/source/reference-manual/linux/factory-device-reset.rst index e4d8883b2..6e1fd0a8a 100644 --- a/source/reference-manual/linux/factory-device-reset.rst +++ b/source/reference-manual/linux/factory-device-reset.rst @@ -51,4 +51,4 @@ compose-apps to be preserved. RPMB ~~~~ -Currently, ``RPMB`` is not cleared in either reset procedures. +Currently, :term:`RPMB` is not cleared in either reset procedures. diff --git a/source/reference-manual/linux/linux-disk-encryption.rst b/source/reference-manual/linux/linux-disk-encryption.rst index c17ed402f..e24d27568 100644 --- a/source/reference-manual/linux/linux-disk-encryption.rst +++ b/source/reference-manual/linux/linux-disk-encryption.rst @@ -23,7 +23,7 @@ storage of the key information. 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``. diff --git a/source/reference-manual/linux/linux-kernel.rst b/source/reference-manual/linux/linux-kernel.rst index df783463a..ff52126e2 100644 --- a/source/reference-manual/linux/linux-kernel.rst +++ b/source/reference-manual/linux/linux-kernel.rst @@ -13,10 +13,10 @@ The kernel recipe can be found within the :ref:`meta-lmp layer `. The latest continuous release of the kernel configuration fragments is available at `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. diff --git a/source/reference-manual/linux/linux-layers.rst b/source/reference-manual/linux/linux-layers.rst index bb9eba985..49aba9cf0 100644 --- a/source/reference-manual/linux/linux-layers.rst +++ b/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 ` (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 `. 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). diff --git a/source/reference-manual/linux/linux-repo.rst b/source/reference-manual/linux/linux-repo.rst index 50b520b18..a4219ca25 100644 --- a/source/reference-manual/linux/linux-repo.rst +++ b/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``. diff --git a/source/reference-manual/linux/linux-wic-installer.rst b/source/reference-manual/linux/linux-wic-installer.rst index 3ec841c9d..d73873fa1 100644 --- a/source/reference-manual/linux/linux-wic-installer.rst +++ b/source/reference-manual/linux/linux-wic-installer.rst @@ -18,7 +18,7 @@ To generate a WIC based image installer, switch the default ``WKS_FILE:sota`` de # 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. diff --git a/source/reference-manual/security/boot-software-updates-imx.rst b/source/reference-manual/security/boot-software-updates-imx.rst index a4eaad463..1c9b72e62 100644 --- a/source/reference-manual/security/boot-software-updates-imx.rst +++ b/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: :: diff --git a/source/reference-manual/security/imx-generic-custom-keys.rst b/source/reference-manual/security/imx-generic-custom-keys.rst index 817879126..53dfec096 100644 --- a/source/reference-manual/security/imx-generic-custom-keys.rst +++ b/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//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:: diff --git a/source/reference-manual/security/secure-boot-imx-habv4.rst b/source/reference-manual/security/secure-boot-imx-habv4.rst index 9edd21c7c..39f7a5248 100644 --- a/source/reference-manual/security/secure-boot-imx-habv4.rst +++ b/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 diff --git a/source/tutorials/customizing-the-platform/customizing-the-platform.rst b/source/tutorials/customizing-the-platform/customizing-the-platform.rst index 53a1c4c6e..2e866280d 100644 --- a/source/tutorials/customizing-the-platform/customizing-the-platform.rst +++ b/source/tutorials/customizing-the-platform/customizing-the-platform.rst @@ -20,7 +20,7 @@ and ``meta-subscriber-overrides.git``. This is the repository you should change to update your platform to newer Linux microPlatform versions. For more information, read :ref:`ref-linux-update`. -``meta-subscriber-overrides`` is the supported meta-layer for customization. +``meta-subscriber-overrides`` is the supported :term:`meta-layer ` for customization. This is a high-priority layer with the power to change anything on the platform. This tutorial guides you through a ``meta-subscriber-overrides`` customization. diff --git a/source/user-guide/custom-ci/custom-ci-for-rootfs.rst b/source/user-guide/custom-ci/custom-ci-for-rootfs.rst index c348935ce..949bd6f7d 100644 --- a/source/user-guide/custom-ci/custom-ci-for-rootfs.rst +++ b/source/user-guide/custom-ci/custom-ci-for-rootfs.rst @@ -4,7 +4,7 @@ Custom CI for RootFS ==================== FoundriesFactory® includes all you need to build a Linux®-based operating system and securely deploy it. -In particular, it provides you with a git repo and a CI service that handles building the kernel and rootfs, and delivering them to devices. +In particular, it provides you with a git repo and a CI service that handles building the kernel and :term:`rootfs`, and delivering them to devices. This is done while leveraging the TUF compliant OTA service. You can learn more in the :ref:`reference ` section. @@ -19,7 +19,7 @@ Prerequisites Bitbake ------- -Use the :ref:`lmp-sdk container` (aka dev container) to bitbake a system image or an ostree repo that contains an OTA-updatable part for rootfs. +Use the :ref:`lmp-sdk container` (aka dev container) to :term:`bitbake` a system image or an ostree repo that contains an OTA-updatable part for rootfs. 1. Disable FoundriesFactory CI specific steps. Add the following to ``conf/local.conf``: diff --git a/source/user-guide/lmp-customization/linux-building.rst b/source/user-guide/lmp-customization/linux-building.rst index 422edbb40..5929ce668 100644 --- a/source/user-guide/lmp-customization/linux-building.rst +++ b/source/user-guide/lmp-customization/linux-building.rst @@ -8,8 +8,8 @@ Building From Source This is a guide for building the base Linux® microPlatform (LmP) from source for QEMU AARCH64 (Arm® 64). Information specific to other targets is provided in :ref:`ref-linux-supported`. -This guide assumes familiarity with OpenEmbedded concepts. -If you are just getting started with OpenEmbedded/the Yocto Project, it is strongly recommended to begin with the documentation provided under :ref:`ref-linux-building-ref`. +This guide assumes familiarity with :term:`Open Embedded` concepts. +If you are just getting started with OpenEmbedded/the :term:`Yocto Project`, it is strongly recommended to begin with the documentation provided under :ref:`ref-linux-building-ref`. .. important:: @@ -68,7 +68,7 @@ The `Google Repo`_ tool is used to fetch Git repos at known-good revisions, and You can also reuse an existing installation directory, or ``/build/lmp`` if building inside the ``lmp-sdk`` container, as described at :ref:`ref-linux-dev-container`. -#. Install update |version| using repo: +#. Install update |version| using :term:`Repo`: .. parsed-literal:: @@ -136,7 +136,7 @@ If you are already working with a Factory, you can instead download the source c The manifest ``.xml`` refers to all the LmP meta-layers and also to the ```` specific repositories as described :ref:`ref-factory-sources`. -3. Build the image for ````: +3. Build the image for ```` with :term:`bitbake`: .. parsed-literal::