1:orphan:
2
3.. _glossary:
4
5Glossary of Terms
6#################
7
8.. glossary::
9   :sorted:
10
11   API
12      (Application Program Interface) A defined set of routines and protocols for
13      building application software.
14
15   application
16      The set of user-supplied files that the Zephyr build system uses
17      to build an application image for a specified board configuration.
18      It can contain application-specific code, kernel configuration settings,
19      and at least one CMakeLists.txt file.
20      The application's kernel configuration settings direct the build system
21      to create a custom kernel that makes efficient use of the board's
22      resources.
23      An application can sometimes be built for more than one type of board
24      configuration (including boards with different CPU architectures),
25      if it does not require any board-specific capabilities.
26
27   application image
28      A binary file that is loaded and executed by the board for which
29      it was built.
30      Each application image contains both the application's code and the
31      Zephyr kernel code needed to support it. They are compiled as a single,
32      fully-linked binary.
33      Once an application image is loaded onto a board, the image takes control
34      of the system, initializes it, and runs as the system's sole application.
35      Both application code and kernel code execute as privileged code
36      within a single shared address space.
37
38   architecture
39      An instruction set architecture (ISA) along with a programming model.
40
41   board
42      A target system with a defined set of devices and capabilities,
43      which can load and execute an application image. It may be an actual
44      hardware system or a simulated system running under QEMU. A board can
45      contain one or more :term:`SoCs <SoC>`.
46      The Zephyr kernel supports a :ref:`variety of boards <boards>`.
47
48   board configuration
49      A set of kernel configuration options that specify how the devices
50      present on a board are used by the kernel.
51      The Zephyr build system defines one or more board configurations
52      for each board it supports. The kernel configuration settings that are
53      specified by the build system can be over-ridden by the application,
54      if desired.
55
56   board name
57      The human-readable name of a :term:`board`. Uniquely and descriptively
58      identifies a particular system, but does not include additional
59      information that may be required to actually build a Zephyr image for it.
60      See :ref:`board_terminology` for additional details.
61
62   board qualifiers
63      The set of additional tokens, separated by a forward slash (`/`) that
64      follow the :term:`board name` (and optionally :term:`board revision`) to
65      form the :term:`board target`. The currently accepted qualifiers are
66      :term:`SoC`, :term:`CPU cluster` and :term:`variant`.
67      See :ref:`board_terminology` for additional details.
68
69   board revision
70      An optional version string that identifies a particular revision of a
71      hardware system. This is useful to avoid duplication of board files
72      whenever small changes are introduced to a hardware system.
73      See :ref:`porting_board_revisions` and :ref:`application_board_version`
74      for more information.
75
76   board target
77     The full string that can be provided to any of the Zephyr build tools to
78     compile and link an image for a particular hardware system. This string
79     uniquely identifies the combination of :term:`board name`, :term:`board
80     revision` and :term:`board qualifiers`.
81     See :ref:`board_terminology` for additional details.
82
83   CPU cluster
84     A group of one or more :term:`CPU cores <CPU core>`, all executing the same image
85     within the same address space and in a symmetrical (SMP) configuration.
86     Only :term:`CPU cores <CPU core>` of the same :term:`architecture` can be in a single
87     cluster. Multiple CPU clusters (each of one or more cores) can coexist in
88     the same :term:`SoC`.
89
90   CPU core
91     A single processing unit, with its own Program Counter, executing program
92     instructions sequentially. CPU cores are part of a :term:`CPU cluster`,
93     which can contain one or more cores.
94
95   device runtime power management
96      Device Runtime Power Management (PM) refers the capability of devices to
97      save energy independently of the system power state. Devices will keep
98      reference of their usage and will automatically be suspended or resumed.
99      This feature is enabled via the :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`
100      Kconfig option.
101
102   idle thread
103      A system thread that runs when there are no other threads ready to run.
104
105   IDT
106      (Interrupt Descriptor Table) a data structure used by the x86
107      architecture to implement an interrupt vector table. The IDT is used
108      to determine the correct response to interrupts and exceptions.
109
110   ISR
111      (Interrupt Service Routine) Also known as an interrupt handler, an ISR
112      is a callback function whose execution is triggered by a hardware
113      interrupt (or software interrupt instructions) and is used to handle
114      high-priority conditions that require interrupting the current code
115      executing on the processor.
116
117   kernel
118      The set of Zephyr-supplied files that implement the Zephyr kernel,
119      including its core services, device drivers, network stack, and so on.
120
121   power domain
122      A power domain is a collection of devices for which power is
123      applied and removed collectively in a single action. Power
124      domains are represented by :c:struct:`device`.
125
126   power gating
127      Power gating reduces power consumption by shutting off areas of an
128      integrated circuit that are not in use.
129
130   SoC
131      A `System on a chip`_, that is, an integrated circuit that contains at
132      least one :term:`CPU cluster` (in turn with at least one :term:`CPU core`),
133      as well as peripherals and memory.
134
135   SoC family
136      One or more :term:`SoCs <SoC>` or :term:`SoC series` that share enough
137      in common to consider them related and under a single family denomination.
138
139   SoC series
140      A number of different :term:`SoCs <SoC>` that share similar characteristics and
141      features, and that the vendor typically names and markets together.
142
143   subsystem
144       A subsystem refers to a logically distinct part of the operating system
145       that handles specific functionality or provides certain services.
146
147   system power state
148      System power states describe the power consumption of the system as a
149      whole. System power states are represented by :c:enum:`pm_state`.
150
151   variant
152      In the context of :term:`board qualifiers`, a variant designates a
153      particular type or configuration of a build for a combination of :term:`SoC`
154      and :term:`CPU cluster`. Common uses of the variant concept include
155      introducing both secure and non-secure builds for platforms with Trusted
156      Execution Environment support, or selecting the type of RAM used in a
157      build.
158
159   west
160      A multi-repo meta-tool developed for the Zephyr project. See :ref:`west`.
161
162   west installation
163      An obsolete term for a :term:`west workspace` used prior to west 0.7.
164
165   west manifest
166      A YAML file, usually named :file:`west.yml`, which describes projects, or
167      the Git repositories which make up a :term:`west workspace`, along with
168      additional metadata. See :ref:`west-basics` for general information
169      and :ref:`west-manifests` for details.
170
171   west manifest repository
172      The Git repository in a :term:`west workspace` which contains the
173      :term:`west manifest`. Its location is given by the :ref:`manifest.path
174      configuration option <west-config-index>`. See :ref:`west-basics`.
175
176   west project
177      Each of the entries in a :term:`west manifest`, which describe a Git
178      repository that will be cloned and managed by west when working with the
179      corresponding :term:`west manifest repository`. Note that a west project
180      is different from a :term:`zephyr module`, although many projects are also
181      modules. See :ref:`west-manifests-projects` for additional information.
182
183   west workspace
184      A folder on your system with a :file:`.west` subdirectory and a
185      :term:`west manifest repository` in it. You clone the Zephyr source code,
186      as well as that of its :term:`west projects <west project>` onto your
187      system by creating a west workspace using the ``west init`` command. See
188      :ref:`west-basics`.
189
190   XIP
191      (eXecute In Place) a method of executing programs directly from long
192      term storage rather than copying it into RAM, saving writable memory for
193      dynamic data and not the static program code.
194
195   zephyr module
196      A Git repository containing a :file:`zephyr/module.yml` file, used by the
197      Zephyr build system to integrate the source code and configuration files
198      of the module into a regular Zephyr build. Zephyr modules may be west
199      projects, but they do not have to. See :ref:`modules` for additional
200      details.
201
202.. _System on a chip: https://en.wikipedia.org/wiki/System_on_a_chip
203