203 lines
9.0 KiB
ReStructuredText
203 lines
9.0 KiB
ReStructuredText
:orphan:
|
|
|
|
.. _glossary:
|
|
|
|
Glossary of Terms
|
|
#################
|
|
|
|
.. glossary::
|
|
:sorted:
|
|
|
|
API
|
|
(Application Program Interface) A defined set of routines and protocols for
|
|
building application software.
|
|
|
|
application
|
|
The set of user-supplied files that the Zephyr build system uses
|
|
to build an application image for a specified board configuration.
|
|
It can contain application-specific code, kernel configuration settings,
|
|
and at least one CMakeLists.txt file.
|
|
The application's kernel configuration settings direct the build system
|
|
to create a custom kernel that makes efficient use of the board's
|
|
resources.
|
|
An application can sometimes be built for more than one type of board
|
|
configuration (including boards with different CPU architectures),
|
|
if it does not require any board-specific capabilities.
|
|
|
|
application image
|
|
A binary file that is loaded and executed by the board for which
|
|
it was built.
|
|
Each application image contains both the application's code and the
|
|
Zephyr kernel code needed to support it. They are compiled as a single,
|
|
fully-linked binary.
|
|
Once an application image is loaded onto a board, the image takes control
|
|
of the system, initializes it, and runs as the system's sole application.
|
|
Both application code and kernel code execute as privileged code
|
|
within a single shared address space.
|
|
|
|
architecture
|
|
An instruction set architecture (ISA) along with a programming model.
|
|
|
|
board
|
|
A target system with a defined set of devices and capabilities,
|
|
which can load and execute an application image. It may be an actual
|
|
hardware system or a simulated system running under QEMU. A board can
|
|
contain one or more :term:`SoCs <SoC>`.
|
|
The Zephyr kernel supports a :ref:`variety of boards <boards>`.
|
|
|
|
board configuration
|
|
A set of kernel configuration options that specify how the devices
|
|
present on a board are used by the kernel.
|
|
The Zephyr build system defines one or more board configurations
|
|
for each board it supports. The kernel configuration settings that are
|
|
specified by the build system can be over-ridden by the application,
|
|
if desired.
|
|
|
|
board name
|
|
The human-readable name of a :term:`board`. Uniquely and descriptively
|
|
identifies a particular system, but does not include additional
|
|
information that may be required to actually build a Zephyr image for it.
|
|
See :ref:`board_terminology` for additional details.
|
|
|
|
board qualifiers
|
|
The set of additional tokens, separated by a forward slash (``/``) that
|
|
follow the :term:`board name` (and optionally :term:`board revision`) to
|
|
form the :term:`board target`. The currently accepted qualifiers are
|
|
:term:`SoC`, :term:`CPU cluster` and :term:`variant`.
|
|
See :ref:`board_terminology` for additional details.
|
|
|
|
board revision
|
|
An optional version string that identifies a particular revision of a
|
|
hardware system. This is useful to avoid duplication of board files
|
|
whenever small changes are introduced to a hardware system.
|
|
See :ref:`porting_board_revisions` and :ref:`application_board_version`
|
|
for more information.
|
|
|
|
board target
|
|
The full string that can be provided to any of the Zephyr build tools to
|
|
compile and link an image for a particular hardware system. This string
|
|
uniquely identifies the combination of :term:`board name`, :term:`board
|
|
revision` and :term:`board qualifiers`.
|
|
See :ref:`board_terminology` for additional details.
|
|
|
|
CPU cluster
|
|
A group of one or more :term:`CPU cores <CPU core>`, all executing the same image
|
|
within the same address space and in a symmetrical (SMP) configuration.
|
|
Only :term:`CPU cores <CPU core>` of the same :term:`architecture` can be in a single
|
|
cluster. Multiple CPU clusters (each of one or more cores) can coexist in
|
|
the same :term:`SoC`.
|
|
|
|
CPU core
|
|
A single processing unit, with its own Program Counter, executing program
|
|
instructions sequentially. CPU cores are part of a :term:`CPU cluster`,
|
|
which can contain one or more cores.
|
|
|
|
device runtime power management
|
|
Device Runtime Power Management (PM) refers the capability of devices to
|
|
save energy independently of the system power state. Devices will keep
|
|
reference of their usage and will automatically be suspended or resumed.
|
|
This feature is enabled via the :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`
|
|
Kconfig option.
|
|
|
|
idle thread
|
|
A system thread that runs when there are no other threads ready to run.
|
|
|
|
IDT
|
|
(Interrupt Descriptor Table) a data structure used by the x86
|
|
architecture to implement an interrupt vector table. The IDT is used
|
|
to determine the correct response to interrupts and exceptions.
|
|
|
|
ISR
|
|
(Interrupt Service Routine) Also known as an interrupt handler, an ISR
|
|
is a callback function whose execution is triggered by a hardware
|
|
interrupt (or software interrupt instructions) and is used to handle
|
|
high-priority conditions that require interrupting the current code
|
|
executing on the processor.
|
|
|
|
kernel
|
|
The set of Zephyr-supplied files that implement the Zephyr kernel,
|
|
including its core services, device drivers, network stack, and so on.
|
|
|
|
power domain
|
|
A power domain is a collection of devices for which power is
|
|
applied and removed collectively in a single action. Power
|
|
domains are represented by :c:struct:`device`.
|
|
|
|
power gating
|
|
Power gating reduces power consumption by shutting off areas of an
|
|
integrated circuit that are not in use.
|
|
|
|
SoC
|
|
A `System on a chip`_, that is, an integrated circuit that contains at
|
|
least one :term:`CPU cluster` (in turn with at least one :term:`CPU core`),
|
|
as well as peripherals and memory.
|
|
|
|
SoC family
|
|
One or more :term:`SoCs <SoC>` or :term:`SoC series` that share enough
|
|
in common to consider them related and under a single family denomination.
|
|
|
|
SoC series
|
|
A number of different :term:`SoCs <SoC>` that share similar characteristics and
|
|
features, and that the vendor typically names and markets together.
|
|
|
|
subsystem
|
|
A subsystem refers to a logically distinct part of the operating system
|
|
that handles specific functionality or provides certain services.
|
|
|
|
system power state
|
|
System power states describe the power consumption of the system as a
|
|
whole. System power states are represented by :c:enum:`pm_state`.
|
|
|
|
variant
|
|
In the context of :term:`board qualifiers`, a variant designates a
|
|
particular type or configuration of a build for a combination of :term:`SoC`
|
|
and :term:`CPU cluster`. Common uses of the variant concept include
|
|
introducing both secure and non-secure builds for platforms with Trusted
|
|
Execution Environment support, or selecting the type of RAM used in a
|
|
build.
|
|
|
|
west
|
|
A multi-repo meta-tool developed for the Zephyr project. See :ref:`west`.
|
|
|
|
west installation
|
|
An obsolete term for a :term:`west workspace` used prior to west 0.7.
|
|
|
|
west manifest
|
|
A YAML file, usually named :file:`west.yml`, which describes projects, or
|
|
the Git repositories which make up a :term:`west workspace`, along with
|
|
additional metadata. See :ref:`west-basics` for general information
|
|
and :ref:`west-manifests` for details.
|
|
|
|
west manifest repository
|
|
The Git repository in a :term:`west workspace` which contains the
|
|
:term:`west manifest`. Its location is given by the :ref:`manifest.path
|
|
configuration option <west-config-index>`. See :ref:`west-basics`.
|
|
|
|
west project
|
|
Each of the entries in a :term:`west manifest`, which describe a Git
|
|
repository that will be cloned and managed by west when working with the
|
|
corresponding :term:`west manifest repository`. Note that a west project
|
|
is different from a :term:`zephyr module`, although many projects are also
|
|
modules. See :ref:`west-manifests-projects` for additional information.
|
|
|
|
west workspace
|
|
A folder on your system with a :file:`.west` subdirectory and a
|
|
:term:`west manifest repository` in it. You clone the Zephyr source code,
|
|
as well as that of its :term:`west projects <west project>` onto your
|
|
system by creating a west workspace using the ``west init`` command. See
|
|
:ref:`west-basics`.
|
|
|
|
XIP
|
|
(eXecute In Place) a method of executing programs directly from long
|
|
term storage rather than copying it into RAM, saving writable memory for
|
|
dynamic data and not the static program code.
|
|
|
|
zephyr module
|
|
A Git repository containing a :file:`zephyr/module.yml` file, used by the
|
|
Zephyr build system to integrate the source code and configuration files
|
|
of the module into a regular Zephyr build. Zephyr modules may be west
|
|
projects, but they do not have to. See :ref:`modules` for additional
|
|
details.
|
|
|
|
.. _System on a chip: https://en.wikipedia.org/wiki/System_on_a_chip
|