summaryrefslogtreecommitdiffstats
path: root/develenv/directory.rst
blob: 0d7b36f0fc92ad1384e8e8a711e090d62bd003cc (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
.. SPDX-License-Identifier: CC-BY-SA-4.0

.. Copyright (C) 1989, 2007 On-Line Applications Research Corporation (OAR)

Directory Structure
*******************

The RTEMS directory structure is designed to meet the following requirements:

- encourage development of modular components.

- isolate processor and target dependent code, while allowing as much common
  source code as possible to be shared across multiple processors and target
  boards.

- allow multiple RTEMS users to perform simultaneous compilation of RTEMS and
  its support facilities for different processors and targets.

The resulting directory structure has processor and board dependent source
files isolated from generic files.  When RTEMS is configured and built, object
directories and an install point will be automatically created based upon the
target CPU family and BSP selected.

The placement of object files based upon the selected BSP name ensures that
object files are not mixed across CPUs or targets.  This in combination with
the makefiles allows the specific compilation options to be tailored for a
particular target board.  For example, the efficiency of the memory subsystem
for a particular target board may be sensitive to the alignment of data
structures, while on another target board with the same processor memory may be
very limited.  For the first target, the options could specify very strict
alignment requirements, while on the second the data structures could be
*packed* to conserve memory.  It is impossible to achieve this degree of
flexibility without providing source code.

The RTEMS source tree is organized based on the following variables:

- functionality,

- target processor family,

- target processor model,

- peripherals, and

- target board.

Each of the following sections will describe the contents of the directories in
the RTEMS source tree.  The top of the tree will be referenced as
``${RTEMS_ROOT}`` in this discussion.

.. code-block:: c

    rtems-VERSION
    |
    +----+----+----+--+-----+---+-------+--------+
    |    |    |       |     |   |       |        |
    c contrib  cpukit doc make testsuites tools

``${RTEMS_ROOT}/c/``
    Historically, this directory was the root of the portions of the
    RTEMS source tree which must be built tailored for a particular CPU
    model or BSP. In the current source, only the build support files for
    the autoconf/automake based build system remain in this subdirectory.

``${RTEMS_ROOT}/cpukit/``
    This directory is the root for all of the "multilib'able" portions of
    RTEMS.  This is a GNU way of saying the contents of this directory can be
    compiled like the C Library (``libc.a``) and the functionality is neither
    CPU model nor BSP specific.  The source code for most RTEMS services reside
    under this directory.  The contents of this directory will be discussed in
    the `CPU Kit Directory`_ section.

``${RTEMS_ROOT}/bsps``
    This directory is the root for all of the BSP specific source in
    RTEMS.  The contents of this directory are discussed in the `BSPs
    Directory`_ section.

``${RTEMS_ROOT}/make/``
    This directory contains files which support RTEMS Makefile's.  From a
    user's perspective, the most important part is the BSP specific
    information found in the ``config`` subdirectory of each BSP.
    Each ".cfg" file is associated with a specific BSP
    and describes the CPU model, and compiler flags used to produce
    an executable for the target board.  These files are described in
    detail in the *RTEMS BSP and Driver Guide* and will not be discussed
    further in this document.

``${RTEMS_ROOT}/testsuites/``
    This directory contains the test suites for the various RTEMS APIs and
    support libraries.  The contents of this directory are discussed in the
    `testsuites/ Test Suites`_ section.

BSPs Directory
~~~~~~~~~~~~~~

The "bsps" directory contains a directory for each CPU family supported by
RTEMS.  Beneath each CPU directory is a directory for each BSP for that
processor family.

The "bsps" directory provides all the BSPs provided with this release
of RTEMS.  The subdirectories are divided, as discussed previously,
based on specific processor family, then further broken down into specific
target board environments.  The "no_cpu" subdirectory provides a starting
point template BSP which can be used to develop a specific BSP for an
unsupported target board.  The files in this subdirectory may aid in
preliminary testing of the RTEMS development environment that has been
built for no particular target in mind.

Below each CPU dependent directory is a directory for each target BSP supported
in this release.

Each BSP provides the modules which comprise an RTEMS BSP.  The modules are
separated into various subdirectories such as "clock", "console",
"include", "shmsupp", "startup", and "timer" as shown in the following
figure:

.. code-block:: c

    Each BSP
    |
    +-----------+----------+-----+-----+----------+----------+
    |           |          |           |          |          |
    clock      console    include     shmsupp    startup     timer

CPU Kit Directory
=================

The @code{cpukit/} directory contains many subdirectories with the
most important ones being shown in the structure below:

.. code-block:: c

    cpukit
    |
    +-----------+----------+-----------+
    |           |          |           |
    posix       rtems       sapi       score

The ``cpukit/`` directory contains a set of subdirectories which contains the
source files comprising the executive portion of the RTEMS development
environment as well as portable support libraries such as support for the C
Library and filesystems.  The API specific and "SuperCore" (e.g. ``score/``
directory) source code files are separated into distinct directory trees.

The following is a description of each of the subdirectories under ``cpukit/``:

``${RTEMS_ROOT}/cpukit/ftpd/``
    This directory contains the RTEMS ftpd server.

``${RTEMS_ROOT}/cpukit/mhttpd/``
    This directory contains the port of the Mongoose web server to RTEMS.

``${RTEMS_ROOT}/cpukit/include/``
    This directory contains header files which are private to RTEMS and not
    considered to be owned by any other component in the CPU Kit.

``${RTEMS_ROOT}/cpukit/libblock/``
    This directory contains support code for using Block Devices such as hard
    drives, floppies, and CD-ROMs.  It includes the generic IO primitives for
    block device drivers, disk caching support, and a RAM disk block device
    driver.

``${RTEMS_ROOT}/cpukit/libcsupport/``
    This directory contains the RTEMS specific support routines for the Newlib
    C Library.  This includes what are referred to as system calls and found in
    section 2 of the traditional UNIX manual.  In addition, it contains a
    thread-safe implementation of the Malloc family of routines as well as BSD
    and POSIX services not found in Newlib.

``${RTEMS_ROOT}/cpukit/libfs/``
    This directory contains the various non-networked filesystem
    implementations for RTEMS.  It includes the In-Memory FileSystem (IMFS),
    the mini-IMFS, and FAT filesystems.

``${RTEMS_ROOT}/cpukit/libi2c/``
    This directory contains the RTEMS I2C framework.

``${RTEMS_ROOT}/cpukit/libmd/``
    This directory contains a port of the standard MD5 checksum code.

``${RTEMS_ROOT}/cpukit/libmisc/``
    This directory contains support facilities which are RTEMS specific but
    otherwise unclassified.  In general, they do not adhere to a standard API.
    Among the support facilities in this directory are a ``/dev/null`` device
    driver, the Stack Overflow Checker, a mini-shell, the CPU and rate
    monotonic period usage monitoring libraries, and a utility to "dump a
    buffer" in a nicely formatted way similar to many ROM monitors.

``${RTEMS_ROOT}/cpukit/libnetworking/``
    This directory contains the port of the FreeBSD TCP/IP stack to RTEMS.

``${RTEMS_ROOT}/cpukit/librpc/``
    This directory contains the port of the FreeBSD RPC/XDR source to RTEMS.

``${RTEMS_ROOT}/cpukit/libpci/``
    This directory contains RTEMS PCI Library.

``${RTEMS_ROOT}/cpukit/posix/``
    This directory contains the RTEMS implementation of the threading portions
    of the POSIX API.

``${RTEMS_ROOT}/cpukit/pppd/``
    This directory contains a port of the free implementation of the PPPD
    network protocol.

``${RTEMS_ROOT}/cpukit/rtems/``
    This directory contains the implementation of the Classic API.

``${RTEMS_ROOT}/cpukit/sapi/``
    This directory contains the implementation of RTEMS services which are
    required but beyond the realm of any standardization efforts.  It includes
    initialization, shutdown, and IO services.

``${RTEMS_ROOT}/cpukit/score/``
    This directory contains the "SuperCore" of RTEMS.  All APIs are implemented
    in terms of SuperCore services.  For example, Classic API tasks and POSIX
    threads are all implemented in terms of SuperCore threads.  This provides a
    common infrastructure and a high degree of interoperability between the
    APIs.  For example, services from all APIs may be used by any task/thread
    independent of the API used to create it.  Within the ``score/`` directory
    the CPU dependent modules are found.  The ``score/cpu/`` subdirectory
    contains a subdirectory for each target CPU supported by this release of
    the RTEMS executive.  Each processor directory contains the CPU dependent
    code necessary to host RTEMS.  The ``no_cpu`` directory provides a starting
    point for developing a new port to an unsupported processor.  The files
    contained within the ``no_cpu`` directory may also be used as a reference
    for the other ports to specific processors.

``${RTEMS_ROOT}/cpukit/telnetd/``
    This directory contains the RTEMS telnetd server.

``${RTEMS_ROOT}/cpukit/wrapup/``
    This directory is responsible for taking the individual libraries and
    objects built in each of the components in the RTEMS CPU Kit source tree
    and bundling them together to form the single RTEMS library
    ``librtemscpu.a``.  This library contains all BSP and CPU model specific
    software.

``${RTEMS_ROOT}/cpukit/zlib/``
    This directory contains a port of the GNU Zlib compression library to
    RTEMS.

testsuites/ Test Suites
=======================

This directory provides all of the RTEMS Test Suite except those for the
Classic API Ada95 binding This includes the single processor tests,
multiprocessor tests, timing tests, library tests, and sample tests.
Additionally, subdirectories for support functions and test related header
files are provided.  The following table lists the test suites currently
included with the RTEMS and the directory in which they may be located:

``${RTEMS_ROOT}/testsuites/libtests/``
    This directory contains the test suite for the various RTEMS support
    components.

``${RTEMS_ROOT}/testsuites/mptests/``
    This directory contains the test suite for the multiprocessor support in
    the Classic API.  The tests provided address two node configurations and
    provide coverage for the multiprocessor code found in RTEMS.

``${RTEMS_ROOT}/testsuites/psxtests/``
    This directory contains the test suite for the RTEMS POSIX API.

``${RTEMS_ROOT}/testsuites/samples/``
    This directory provides sample application tests which aid in the testing a
    newly built RTEMS environment, a new BSP, or as starting points for the
    development of an application using the RTEMS executive.  They are
    discussed in ::ref::`Sample Applications`.

``${RTEMS_ROOT}/testsuites/sptests/``
    This directory contains the test suite for the RTEMS Classic API when
    executing on a single processor.  The tests were originally designed to
    provide near complete test coverage for the entire executive code.  With
    the addition of multiple APIs, this is no longer the case as some SuperCore
    functionality is not available through the Classic API.  Thus some
    functionality in the SuperCore is only covered by tests in the POSIX API
    Test Suites.

``${RTEMS_ROOT}/testsuites/support/``
    This directory contains support software and header files for the various
    test suites.

``${RTEMS_ROOT}/testsuites/tmtests/``
    This directory contains the timing test suite for the RTEMS Classic API.
    This include tests that benchmark each directive in the Classic API as well
    as a set of critical SuperCore functions.  These tests are important for
    helping to verify that RTEMS performs as expected on your target hardware.
    It is not uncommon to discover mistakes in board initialization such as
    caching being disabled as a side-effect of analyzing the results of these
    tests.

``${RTEMS_ROOT}/testsuites/tools/``
    This directory contains tools which execute on the development host and aid
    in executing and evaluating the results of the test suite.  The tools
    ``difftest`` compares the output of one or more tests with the expected
    output.  If you place the output of all the ``tmtests/`` in a single file,
    then the utility ``sorttimes`` will be able to produce a report organizing
    the execution times by manager.