summaryrefslogtreecommitdiffstats
path: root/user/overview/index.rst
blob: f00ecdf39c454d3ebf9094564ff1de46b1cc48d8 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
.. SPDX-License-Identifier: CC-BY-SA-4.0

.. Copyright (C) 2016 Chris Johns <chrisj@rtems.org>

Introduction
************

Overview
========

You are someone looking for a real-time operating system.  This document

- presents the basic features of RTEMS, so that you can decide if it is worth to
  look at,

- gives you a :ref:`quick start <QuickStart>` to install all the tools
  necessary to work with RTEMS, and

- helps you to build an example application on top of RTEMS.

Features
========

The Real-Time Executive for Multiprocessor Systems (:ref:term:`RTEMS`) is a
multi-threaded, single address-space, real-time operating system with no
kernel-space/user-space separation.  It is capable to operate in an
:ref:term:`SMP` configuration providing a state of the art feature set.

RTEMS is licensed under a
`modified GPL 2.0 or later license with an exception for static linking <https://git.rtems.org/rtems/tree/LICENSE>`_
[#]_.  It exposes no license requirements on application code.  The third-party
software used and distributed by RTEMS which may be linked to the application
is licensed under permissive open source licenses.  Everything necessary to
build RTEMS applications is available as open source software.  This makes you
completely vendor independent.

RTEMS provides the following basic feature set:

- :ref:term:`APIs <API>`

    - :ref:term:`POSIX` with
      `pthreads <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pthread.h.html>`_
      (enables a broad range of standard software to run on RTEMS)

    - `Classic <https://docs.rtems.org/branches/master/c-user.pdf>`_

    - :ref:term:`C11` (including
      `thread <https://en.cppreference.com/w/c/thread>`_ support)

    - :ref:term:`C++11` (including
      `thread <https://en.cppreference.com/w/cpp/thread>`_ support)

    - Newlib and :ref:term:`GCC` internal

- Programming languages

    - C/C++/OpenMP (RTEMS Source Builder, RSB)

    - Ada (RSB, ``--with-ada``)

    - Erlang

    - Fortran (RSB, ``--with-fortran``)

    - Python and MicroPython

- Parallel languages

    - :ref:term:`EMBĀ²`

    - Google Go [#]_

    - :ref:term:`OpenMP` 4.5

- Thread synchronization and communication

    - Mutexes with and without locking protocols

    - Counting semaphores

    - Binary semaphores

    - Condition variables

    - Events

    - Message queues

    - Barriers

    - :ref:term:`Futex` (used by :ref:term:`OpenMP` barriers)

    - Epoch Based Reclamation (libbsd)

- Locking protocols

    - Transitive Priority Inheritance

    - :ref:term:`OMIP` (SMP feature)

    - Priority Ceiling

    - :ref:term:`MrsP` (SMP feature)

- Scalable timer and timeout support

- Lock-free timestamps (FreeBSD timecounters)

- Responsive interrupt management

- C11/C++11 :ref:term:`TLS` [#]_

- Link-time configurable schedulers

    - Fixed-priority

    - Job-level fixed-priority (:ref:term:`EDF`)

    - Constant Bandwidth Server (experimental)

- Clustered scheduling (SMP feature)

    - Flexible link-time configuration

    - Job-level fixed-priority scheduler (:ref:term:`EDF`) with support for
      one-to-one and one-to-all thread to processor affinities (default SMP
      scheduler)

    - Fixed-priority scheduler

    - Proof-of-concept strong :ref:term:`APA` scheduler

- Focus on link-time application-specific configuration

- Linker-set based initialization (similar to global C++ constructors)

- Operating system uses fine-grained locking (SMP feature)

- Dynamic memory allocators

    - First-fit (default)

    - Universal Memory Allocator
      (`UMA <https://www.freebsd.org/cgi/man.cgi?query=uma&sektion=9>`_ ,
      libbsd)

- File systems

    - :ref:term:`IMFS`

    - :ref:term:`FAT`

    - :ref:term:`RFS`

    - :ref:term:`NFSv2`

    - :ref:term:`JFFS2` (NOR flashes)

    - :ref:term:`YAFFS2` (NAND flashes, GPL or commercial license required)

- Device drivers

    - Termios (serial interfaces)

    - I2C (Linux user-space API compatible)

    - SPI (Linux user-space API compatible)

    - Network stacks (legacy, libbsd, lwIP)

    - USB stack (libbsd)

    - SD/MMC card stack (libbsd)

    - Framebuffer (Linux user-space API compatible, Qt)

    - Application runs in kernel-space and can access hardware directly

- libbsd

    - Port of FreeBSD user-space and kernel-space components to RTEMS

    - Easy access to FreeBSD software for RTEMS

    - Support to stay in synchronization with FreeBSD

.. _ecosystem:

Ecosystem
=========
.. index:: Ecosystem

The RTEMS Ecosystem is the collection of tools, packages, code, documentation
and online content provided by the RTEMS Project. The ecosystem provides a way
to develop, maintain, and use RTEMS. It's parts interact with the user, the
host environment, and each other to make RTEMS accessible, useable and
predicable.

The ecosystem is for users, developers and maintainers and it is an ongoing
effort that needs your help and support. The RTEMS project is always improving
the way it delivers the kernel to you and your feedback is important so please
join the mailing lists and contribute back comments, success stories, bugs and
patches.

What the RTEMS project describes here to develop, maintain and use RTEMS does
not dictate what you need to use in your project. You can and should select the
work-flow that best suites the demands of your project and what you are
delivering.

Rational
--------

RTEMS is complex and the focus of the RTEMS Ecosystem is to simplify the
complexity for users by providing a stable documented way to build, configure
and run RTEMS. RTEMS is more than a kernel running real-time applications on
target hardware, it is part of a project's and therefore team's workflow and
every project and team is different.

RTEMS's ecosystem does not mandate a way to work. It is a series of parts,
components, and items that are used to create a suitable development
environment to work with. The processes explained in this manual are the same
things an RTEMS maintainer does to maintain the kernel or an experienced user
does to build their production system. It is important to keep this in mind
when working through this manual. We encourage users to explore what can be
done and to discover ways to make it fit their needs. The ecosystem provided by
the RTEMS Project will not install in a single click of a mouse because we want
users to learn the parts they will come to depend on as their project's
development matures.

The RTEMS Ecosystem provides a standard interface that is the same on all
supported host systems. Standardizing how a user interacts with RTEMS is
important and making that experience portable is also important. As a result
the ecosystem is documented at the command line level and we leave GUI and IDE
integration for users and integrators.

Standardizing the parts and how to use them lets users create processes and
procedures that are stable over releases. The RTEMS Ecosystem generates data
that can be used to audit the build process so their configuration can be
documented.

The ecosystem is based around the source code used in the various parts,
components and items of the RTEMS development environment. A user can create
an archive of the complete build process including all the source code for long
term storage. This is important for projects with a long life cycle.

Open Source
-----------

RTEMS is an open source operating system and an open source project and this
extends to the ecosystem. We encourage users to integrate the processes to
build tools, the kernel and any 3rd party libraries into their project's
configuration management processes.

All the parts that make up the ecosystem are open source. The ecosystem uses a
package's source code to create an executable on a host so when an example
RTEMS executable is created and run for the first time the user will have built
every tool as well as the executable from source. The RTEMS Project believes
the freedom this gives a user is as important as the freedom of having access
to the source code for a package.

Deployment
----------

The RTEMS Project provides the ecosystem as source code that users can download
to create personalised development environments. The RTEMS Project does not
provide packaging and deployment for a specific host environment, target
architecture or BSP. The RTEMS Project encourages users and organizations to
fill this role for the community.

Building and Deploying Tool Binaries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you wish to create and distribute your build or you want to archive a build
you can create a tar file. We term this deploying a build. This is a more
advanced method for binary packaging and installing of tools.

By default the RTEMS Source Builder installs the built packages directly and
optionally it can also create a *build set tar file* or a *package tar file*
per package built. The normal and default behaviour is to let the RTEMS Source
Builder install the tools. The source will be downloaded, built, installed and
cleaned up.

The tar files are created with the full build prefix present and if you follow
the examples given in this documentation the path is absolute. This can cause
problems if you are installing on a host you do not have super user or
administrator rights on because the prefix path may references part you do not
have write access too and tar will not extract the files. You can use the
``--strip-components`` option in tar if your host tar application supports it
to remove the parts you do not have write access too or you may need to unpack
the tar file somewhere and copy the file tree from the level you have write
access from. Embedding the full prefix path in the tar files lets you know what
the prefix is and is recommended. For example if
``/home/chris/development/rtems/4.11`` is the prefix used you cannot change
directory to the root (``/``) and untar the file because the ``/home`` is root
access only. To install a tar file you have downloaded into your new machine's
``Downloads`` directory in your home directoty you would enter:

.. code-block:: shell

    $ cd /somewhere
    $ tar --strip-components=3 -xjf \
          $HOME/Downloads/rtems-4.11-sparc-rtems4.11-1.tar.bz2

A build set tar file is created by adding ``--bset-tar-file`` option to the
``sb-set-builder`` command::

    $ ../source-builder/sb-set-builder --log=l-sparc.txt \
             --prefix=$HOME/development/rtems/4.11 \
             --bset-tar-file \     <1>
             4.11/rtems-sparc
    Source Builder - Set Builder, v0.2.0
    Build Set: 4.11/rtems-sparc
    config: expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-freebsd9.1-1
    building: expat-2.1.0-x86_64-freebsd9.1-1
    config: tools/rtems-binutils-2.22-1.cfg
    package: sparc-rtems4.11-binutils-2.22-1
    building: sparc-rtems4.11-binutils-2.22-1
    config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
    package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    config: tools/rtems-gdb-7.5.1-1.cfg
    package: sparc-rtems4.11-gdb-7.5.1-1
    building: sparc-rtems4.11-gdb-7.5.1-1
    installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11 <2>
    installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
    installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
    installing: rtems-4.11-sparc-rtems4.11-1 -> /home/chris/development/rtems/4.11
    tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2      <3>
    cleaning: expat-2.1.0-x86_64-freebsd9.1-1
    cleaning: sparc-rtems4.11-binutils-2.22-1
    cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    cleaning: sparc-rtems4.11-gdb-7.5.1-1
    Build Set: Time 0:15:25.92873

.. topic:: Items

  1. The option to create a build set tar file.

  2. The installation still happens unless you specify ``--no-install``.

  3. Creating the build set tar file.

You can also suppress installing the files using the ``--no-install``
option. This is useful if your prefix is not accessiable, for example when
building Canadian cross compiled tool sets::

    $ ../source-builder/sb-set-builder --log=l-sparc.txt \
                --prefix=$HOME/development/rtems/4.11 \
                --bset-tar-file \
                --no-install \      <1>
                4.11/rtems-sparc
    Source Builder - Set Builder, v0.2.0
    Build Set: 4.11/rtems-sparc
    config: expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-freebsd9.1-1
    building: expat-2.1.0-x86_64-freebsd9.1-1
    config: tools/rtems-binutils-2.22-1.cfg
    package: sparc-rtems4.11-binutils-2.22-1
    building: sparc-rtems4.11-binutils-2.22-1
    config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
    package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    config: tools/rtems-gdb-7.5.1-1.cfg
    package: sparc-rtems4.11-gdb-7.5.1-1
    building: sparc-rtems4.11-gdb-7.5.1-1
    tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2    <2>
    cleaning: expat-2.1.0-x86_64-freebsd9.1-1
    cleaning: sparc-rtems4.11-binutils-2.22-1
    cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    cleaning: sparc-rtems4.11-gdb-7.5.1-1
    Build Set: Time 0:14:11.721274
    $ ls tar
    rtems-4.11-sparc-rtems4.11-1.tar.bz2

.. topic:: Items

  1. The option to supressing installing the packages.

  2. Create the build set tar.

A package tar file can be created by adding the ``--pkg-tar-files`` to the
``sb-set-builder`` command. This creates a tar file per package built in the
build set::

    $ ../source-builder/sb-set-builder --log=l-sparc.txt \
            --prefix=$HOME/development/rtems/4.11 \
            --bset-tar-file \
            --pkg-tar-files \        <1>
            --no-install 4.11/rtems-sparc
    Source Builder - Set Builder, v0.2.0
    Build Set: 4.11/rtems-sparc
    config: expat-2.1.0-1.cfg
    package: expat-2.1.0-x86_64-freebsd9.1-1
    building: expat-2.1.0-x86_64-freebsd9.1-1
    config: tools/rtems-binutils-2.22-1.cfg
    package: sparc-rtems4.11-binutils-2.22-1
    building: sparc-rtems4.11-binutils-2.22-1
    config: tools/rtems-gcc-4.7.2-newlib-1.20.0-1.cfg
    package: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    building: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    config: tools/rtems-gdb-7.5.1-1.cfg
    package: sparc-rtems4.11-gdb-7.5.1-1
    building: sparc-rtems4.11-gdb-7.5.1-1
    tarball: tar/rtems-4.11-sparc-rtems4.11-1.tar.bz2
    cleaning: expat-2.1.0-x86_64-freebsd9.1-1
    cleaning: sparc-rtems4.11-binutils-2.22-1
    cleaning: sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1
    cleaning: sparc-rtems4.11-gdb-7.5.1-1
    Build Set: Time 0:14:37.658460
    $ ls tar
    expat-2.1.0-x86_64-freebsd9.1-1.tar.bz2           sparc-rtems4.11-binutils-2.22-1.tar.bz2
    sparc-rtems4.11-gdb-7.5.1-1.tar.bz2 <2>           rtems-4.11-sparc-rtems4.11-1.tar.bz2 <3>
    sparc-rtems4.11-gcc-4.7.2-newlib-1.20.0-1.tar.bz2

.. topic:: Items

  1. The option to create packages tar files.

  2. The GDB package tar file.

  3. The build set tar file. All the others in a single tar file.

Support
=======
.. index:: Support

RTEMS offers a variety of support options.

This section covers all options available to both users and developers.  If you
believe this is a bug report please submit it to the bug tracker otherwise the
developers mailing list is the default location to send the report.

RTEMS Project Support
---------------------
.. index:: RTEMS Project Support

The following support channels are provided by the RTEMS Project and provide
direct access to the RTEMS community.

Bug Tracker
~~~~~~~~~~~
.. index:: Bugs
.. index:: Reporting bugs

The bug tracker can be found at the :r:url:`bugs`.

See the `Submission Guidelines <http://devel.rtems.org/wiki/NewTicket/>`_ for
details on submitting a ticket.

Be sure to do a cursory search for any tickets that may be relevant to your
problem.

If you are unsure about your issue status submit a ticket and we will help you
sort it out.

Documentation
~~~~~~~~~~~~~

The latest user documentation can always be found at the :r:url:`docs`.

.. _support-mailing-lists:

Mailing Lists
~~~~~~~~~~~~~
.. index:: Community
.. index:: Mailing lists

We have several mailing lists for RTEMS users and developers.

	* :r:list:`announce`
		* Announcements for major and other project-related issues.

	* :r:list:`bugs`
		* Bugs email from :r:url:`bugs`.

	* :r:list:`devel`
		* Developers list, this is for developers of RTEMS itself.


	* :r:list:`build`
		* Results from the testing and building of RTEMS.

	* :r:list:`users`
		* Users of RTEMS.

	* :r:list:`vc`
		* Commits to the RTEMS master repository.


IRC
~~~
.. index:: Community
.. index:: IRC

RTEMS IRC is available on the Freenode network. See the `Freenode
<http://www.freenode.net/>`_ web site for details on connecting, selecting a
nickname, and general usage tips. If you are new to IRC it is recommended
reading.

These are the current IRC channels.

  **#rtems**

This is a general channel for all things RTEMS. You can just hang out with
other RTEMS users and developers to talk about RTEMS, using RTEMS or to make
contact with other RTEMS users.

The ``#rtems`` channel is logged. You can find the logs at
http://www.rtems.org/irclogs/. You can search the logs using Google by adding:

  **site:rtems.org inurl:irclogs**

to your search terms.

Developers
~~~~~~~~~~
.. index:: Community
.. index:: Developers

Developers can find help and support on the mailing lists, see
:ref:`support-mailing-lists`.

Technical documents including design, :r:url:`gsoc`, :r:url:`socis` can be
found on the :r:url:`devel`.

Commercial Support Services
---------------------------

The wider RTEMS community has developers and organizations who can provide
commercial support services. These services range from training, implementing
new features in RTEMS, deployment of RTEMS< helping establish a new project
environment for a team, to application and system design.

The RTEMS Project does not endorse or promote any provider of these services
and we recommend you use a search engine to locate a suitable provider. If you
are unsure please contact a provider and see what is available.

If you develop a new feature or you have someone do this for you we recommend
you have the work submitted to the project and merged. Once accepted into the
project the work will be maintained as part of the development process within
the project and this is a benefit for.

Real-time Application Systems
=============================

Real-time application systems are a special class of computer applications.
They have a complex set of characteristics that distinguish them from other
software problems.  Generally, they must adhere to more rigorous requirements.
The correctness of the system depends not only on the results of computations,
but also on the time at which the results are produced.  The most important and
complex characteristic of real-time application systems is that they must
receive and respond to a set of external stimuli within rigid and critical time
constraints referred to as deadlines.  Systems can be buried by an avalanche of
interdependent, asynchronous or cyclical event streams.

Deadlines can be further characterized as either hard or soft based upon the
value of the results when produced after the deadline has passed.  A deadline
is hard if the results have no value after the deadline has passed, or a
catastrophic event results from their intended use if not completed on time.  In
contrast, results produced after a soft deadline may still have some value.

Another distinguishing requirement of real-time application systems is the
ability to coordinate or manage a large number of concurrent activities. Since
software is a synchronous entity, this presents special problems.  One
instruction follows another in a repeating synchronous cycle.  Even though
mechanisms have been developed to allow for the processing of external
asynchronous events, the software design efforts required to process and manage
these events and tasks are growing more complicated.

The design process is complicated further by spreading this activity over a set
of processors instead of a single processor. The challenges associated with
designing and building real-time application systems become very complex when
multiple processors are involved.  New requirements such as interprocessor
communication channels and global resources that must be shared between
competing processors are introduced.  The ramifications of multiple processors
complicate each and every characteristic of a real-time system.

Real-time Executive
===================

Fortunately, real-time operating systems, or real-time executives, serve as a
cornerstone on which to build the application system.  A real-time multitasking
executive allows an application to be cast into a set of logical, autonomous
processes or tasks which become quite manageable.  Each task is internally
synchronous, but different tasks execute independently, resulting in an
asynchronous processing stream.  Tasks can be dynamically paused for many
reasons resulting in a different task being allowed to execute for a period of
time.  The executive also provides an interface to other system components such
as interrupt handlers and device drivers.  System components may request the
executive to allocate and coordinate resources, and to wait for and trigger
synchronizing conditions.  The executive system calls effectively extend the
CPU instruction set to support efficient multitasking.  By causing tasks to
travel through well-defined state transitions, system calls permit an
application to demand-switch between tasks in response to real-time events.

By properly grouping stimuli responses into separate tasks a system can now
asynchronously switch between independent streams of execution. This allows the
system to directly respond to external stimuli as they occur, as well as meet
critical performance specifications that are typically measured by guaranteed
response time and transaction throughput.  The multiprocessor extensions of
RTEMS provide the features necessary to manage the extra requirements
introduced by a system distributed across several processors.  It removes the
physical barriers of processor boundaries from the world of the system
designer, enabling more critical aspects of the system to receive the required
attention. Such a system, based on an efficient real-time, multiprocessor
executive, is a more realistic model of the outside world or environment for
which it is designed.  As a result, the system will always be more logical,
efficient, and reliable.

By using the directives provided by RTEMS, the real-time applications developer
is freed from the problem of controlling and synchronizing multiple tasks and
processors.  In addition, one need not develop, test, debug, and document
routines to manage memory, pass messages, or provide mutual exclusion.  The
developer is then able to concentrate solely on the application.  By using
standard software components, the time and cost required to develop
sophisticated real-time applications are significantly reduced.

.. [#] The goal is to use the
       `BSD 2-Clause license
       <https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause>`_ for new code
       or code those copyright holder agreed to a license change, see `#3053
       <https://devel.rtems.org/ticket/3053>`_ for the details.

.. [#] See `#2832 <https://devel.rtems.org/ticket/2832>`_.

.. [#] Thread-local storage requires some support by the tool chain and the
       RTEMS architecture support, e.g. context-switch code.  It is supported
       at least on ARM, PowerPC, RISC-V, SPARC and m68k.  Check the
       `RTEMS CPU Architecture Supplement <https://docs.rtems.org/branches/master/cpu-supplement.pdf>`_
       if it is supported.