source: rtems-docs/cpu-supplement/port.rst @ 3fdea2d

5
Last change on this file since 3fdea2d was 97e1553, checked in by Sebastian Huber <sebastian.huber@…>, on 01/17/17 at 09:39:08

c-user: Add support for references via bibtex

https://sphinxcontrib-bibtex.readthedocs.io/en/latest/index.html

Update #2871.

  • Property mode set to 100644
File size: 19.4 KB
Line 
1.. comment SPDX-License-Identifier: CC-BY-SA-4.0
2
3.. COMMENT: COPYRIGHT (c) 1988-2002.
4.. COMMENT: On-Line Applications Research Corporation (OAR).
5.. COMMENT: All rights reserved.
6
7Port Specific Information
8*************************
9
10This chaper provides a general description of the type of architecture specific
11information which is in each of the architecture specific chapters that follow.
12The outline of this chapter is identical to that of the architecture specific
13chapters.
14
15In each of the architecture specific chapters, this introductory section will
16provide an overview of the architecture:
17
18**Architecture Documents**
19
20In each of the architecture specific chapters, this section will provide
21pointers on where to obtain documentation.
22
23CPU Model Dependent Features
24============================
25
26Microprocessors are generally classified into families with a variety of CPU
27models or implementations within that family.  Within a processor family, there
28is a high level of binary compatibility.  This family may be based on either an
29architectural specification or on maintaining compatibility with a popular
30processor.  Recent microprocessor families such as the SPARC or PowerPC are
31based on an architectural specification which is independent or any particular
32CPU model or implementation.  Older families such as the Motorola 68000 and the
33Intel x86 evolved as the manufacturer strived to produce higher performance
34processor models which maintained binary compatibility with older models.
35
36RTEMS takes advantage of the similarity of the various models within a CPU
37family.  Although the models do vary in significant ways, the high level of
38compatibility makes it possible to share the bulk of the CPU dependent
39executive code across the entire family.  Each processor family supported by
40RTEMS has a list of features which vary between CPU models within a family.
41For example, the most common model dependent feature regardless of CPU family
42is the presence or absence of a floating point unit or coprocessor.  When
43defining the list of features present on a particular CPU model, one simply
44notes that floating point hardware is or is not present and defines a single
45constant appropriately.  Conditional compilation is utilized to include the
46appropriate source code for this CPU model's feature set.  It is important to
47note that this means that RTEMS is thus compiled using the appropriate feature
48set and compilation flags optimal for this CPU model used.  The alternative
49would be to generate a binary which would execute on all family members using
50only the features which were always present.
51
52The set of CPU model feature macros are defined in the
53:file:`cpukit/score/cpu/CPU/rtems/score/cpu.h` based upon the GNU tools
54multilib variant that is appropriate for the particular CPU model defined on
55the compilation command line.
56
57In each of the architecture specific chapters, this section presents the set of
58features which vary across various implementations of the architecture that may
59be of importance to RTEMS application developers.
60
61The subsections will vary amongst the target architecture chapters as the
62specific features may vary.  However, each port will include a few common
63features such as the CPU Model Name and presence of a hardware Floating Point
64Unit.  The common features are described here.
65
66CPU Model Name
67--------------
68
69The macro ``CPU_MODEL_NAME`` is a string which designates the name of this CPU
70model.  For example, for the MC68020 processor model from the m68k
71architecture, this macro is set to the string "mc68020".
72
73Floating Point Unit
74-------------------
75
76In most architectures, the presence of a floating point unit is an option.  It
77does not matter whether the hardware floating point support is incorporated
78on-chip or is an external coprocessor as long as it appears an FPU per the ISA.
79However, if a hardware FPU is not present, it is possible that the floating
80point emulation library for this CPU is not reentrant and thus context switched
81by RTEMS.
82
83RTEMS provides two feature macros to indicate the FPU configuration:
84
85- CPU_HARDWARE_FP
86  is set to TRUE to indicate that a hardware FPU is present.
87
88- CPU_SOFTWARE_FP
89  is set to TRUE to indicate that a hardware FPU is not present and that the FP
90  software emulation will be context switched.
91
92Multilibs
93=========
94
95Newlib and GCC provide several target libraries like the :file:`libc.a`,
96:file:`libm.a` and :file:`libgcc.a`.  These libraries are artifacts of the GCC
97build process.  Newlib is built together with GCC.  To provide optimal support
98for various chip derivatives and instruction set revisions multiple variants of
99these libraries are available for each architecture.  For example one set may
100use software floating point support and another set may use hardware floating
101point instructions.  These sets of libraries are called *multilibs*.  Each
102library set corresponds to an application binary interface (ABI) and
103instruction set.
104
105A multilib variant can be usually detected via built-in compiler defines at
106compile-time.  This mechanism is used by RTEMS to select for example the
107context switch support for a particular BSP.  The built-in compiler defines
108corresponding to multilibs are the only architecture specific defines allowed
109in the ``cpukit`` area of the RTEMS sources.
110
111Invoking the GCC with the ``-print-multi-lib`` option lists the available
112multilibs.  Each line of the output describes one multilib variant.  The
113default variant is denoted by ``.`` which is selected when no or contradicting
114GCC machine options are selected.  The multilib selection for a target is
115specified by target makefile fragments (see file :file:`t-rtems` in the GCC
116sources and section *The Target Makefile Fragment*
117(https://gcc.gnu.org/onlinedocs/gccint/Target-Fragment.html#Target-Fragment)
118in the *GCC Internals Manual* (https://gcc.gnu.org/onlinedocs/gccint/).
119
120Calling Conventions
121===================
122
123Each high-level language compiler generates subroutine entry and exit code
124based upon a set of rules known as the compiler's calling convention.  These
125rules address the following issues:
126
127- register preservation and usage
128
129- parameter passing
130
131- call and return mechanism
132
133A compiler's calling convention is of importance when interfacing to
134subroutines written in another language either assembly or high-level.  Even
135when the high-level language and target processor are the same, different
136compilers may use different calling conventions.  As a result, calling
137conventions are both processor and compiler dependent.
138
139Calling Mechanism
140-----------------
141
142In each of the architecture specific chapters, this subsection will describe
143the instruction(s) used to perform a *normal* subroutine invocation.  All RTEMS
144directives are invoked as *normal* C language functions so it is important to
145the user application to understand the call and return mechanism.
146
147Register Usage
148--------------
149
150In each of the architecture specific chapters, this subsection will detail the
151set of registers which are *NOT* preserved across subroutine invocations.  The
152registers which are not preserved are assumed to be available for use as
153scratch registers.  Therefore, the contents of these registers should not be
154assumed upon return from any RTEMS directive.
155
156In some architectures, there may be a set of registers made available
157automatically as a side-effect of the subroutine invocation mechanism.
158
159Parameter Passing
160-----------------
161
162In each of the architecture specific chapters, this subsection will describe
163the mechanism by which the parameters or arguments are passed by the caller to
164a subroutine.  In some architectures, all parameters are passed on the stack
165while in others some are passed in registers.
166
167User-Provided Routines
168----------------------
169
170All user-provided routines invoked by RTEMS, such as user extensions, device
171drivers, and MPCI routines, must also adhere to these calling conventions.
172
173Memory Model
174============
175
176A processor may support any combination of memory models ranging from pure
177physical addressing to complex demand paged virtual memory systems.  RTEMS
178supports a flat memory model which ranges contiguously over the processor's
179allowable address space.  RTEMS does not support segmentation or virtual memory
180of any kind.  The appropriate memory model for RTEMS provided by the targeted
181processor and related characteristics of that model are described in this
182chapter.
183
184Flat Memory Model
185-----------------
186
187Most RTEMS target processors can be initialized to support a flat address
188space.  Although the size of addresses varies between architectures, on most
189RTEMS targets, an address is 32-bits wide which defines addresses ranging from
1900x00000000 to 0xFFFFFFFF (4 gigabytes).  Each address is represented by a
19132-bit value and is byte addressable.  The address may be used to reference a
192single byte, word (2-bytes), or long word (4 bytes).  Memory accesses within
193this address space may be performed in little or big endian fashion.
194
195On smaller CPU architectures supported by RTEMS, the address space may only be
19620 or 24 bits wide.
197
198If the CPU model has support for virtual memory or segmentation, it is the
199responsibility of the Board Support Package (BSP) to initialize the MMU
200hardware to perform address translations which correspond to flat memory model.
201
202In each of the architecture specific chapters, this subsection will describe
203any architecture characteristics that differ from this general description.
204
205Interrupt Processing
206====================
207
208Different types of processors respond to the occurrence of an interrupt in its
209own unique fashion. In addition, each processor type provides a control
210mechanism to allow for the proper handling of an interrupt.  The processor
211dependent response to the interrupt modifies the current execution state and
212results in a change in the execution stream.  Most processors require that an
213interrupt handler utilize some special control mechanisms to return to the
214normal processing stream.  Although RTEMS hides many of the processor dependent
215details of interrupt processing, it is important to understand how the RTEMS
216interrupt manager is mapped onto the processor's unique architecture.
217
218RTEMS supports a dedicated interrupt stack for all architectures.  On
219architectures with hardware support for a dedicated interrupt stack, it will be
220initialized such that when an interrupt occurs, the processor automatically
221switches to this dedicated stack.  On architectures without hardware support
222for a dedicated interrupt stack which is separate from those of the tasks,
223RTEMS will support switching to a dedicated stack for interrupt processing.
224
225Without a dedicated interrupt stack, every task in the system MUST have enough
226stack space to accommodate the worst case stack usage of that particular task
227and the interrupt service routines COMBINED.  By supporting a dedicated
228interrupt stack, RTEMS significantly lowers the stack requirements for each
229task.
230
231A nested interrupt is processed similarly with the exception that since the CPU
232is already executing on the interrupt stack, there is no need to switch to the
233interrupt stack.
234
235In some configurations, RTEMS allocates the interrupt stack from the Workspace
236Area.  The amount of memory allocated for the interrupt stack is user
237configured and based upon the ``confdefs.h`` parameter
238``CONFIGURE_INTERRUPT_STACK_SIZE``.  This parameter is described in detail in
239the Configuring a System chapter of the User's Guide.  On configurations in
240which RTEMS allocates the interrupt stack, during the initialization process,
241RTEMS will also install its interrupt stack.  In other configurations, the
242interrupt stack is allocated and installed by the Board Support Package (BSP).
243
244In each of the architecture specific chapters, this section discesses the
245interrupt response and control mechanisms of the architecture as they pertain
246to RTEMS.
247
248Vectoring of an Interrupt Handler
249---------------------------------
250
251In each of the architecture specific chapters, this subsection will describe
252the architecture specific details of the interrupt vectoring process.  In
253particular, it should include a description of the Interrupt Stack Frame (ISF).
254
255Interrupt Levels
256----------------
257
258In each of the architecture specific chapters, this subsection will describe
259how the interrupt levels available on this particular architecture are mapped
260onto the 255 reserved in the task mode.  The interrupt level value of zero (0)
261should always mean that interrupts are enabled.
262
263Any use of an interrupt level that is is not undefined on a particular
264architecture may result in behavior that is unpredictable.
265
266Disabling of Interrupts by RTEMS
267--------------------------------
268
269During the execution of directive calls, critical sections of code may be
270executed.  When these sections are encountered, RTEMS disables all external
271interrupts before the execution of this section and restores them to the
272previous level upon completion of the section.  RTEMS has been optimized to
273ensure that interrupts are disabled for the shortest number of instructions
274possible.  Since the precise number of instructions and their execution time
275varies based upon target CPU family, CPU model, board memory speed, compiler
276version, and optimization level, it is not practical to provide the precise
277number for all possible RTEMS configurations.
278
279Historically, the measurements were made by hand analyzing and counting the
280execution time of instruction sequences during interrupt disable critical
281sections.  For reference purposes, on a 16 Mhz Motorola MC68020, the maximum
282interrupt disable period was typically approximately ten (10) to thirteen (13)
283microseconds.  This architecture was memory bound and had a slow bit scan
284instruction.  In contrast, during the same period a 14 Mhz SPARC would have a
285worst case disable time of approximately two (2) to three (3) microseconds
286because it had a single cycle bit scan instruction and used fewer cycles for
287memory accesses.
288
289If you are interested in knowing the worst case execution time for a particular
290version of RTEMS, please contact OAR Corporation and we will be happy to
291product the results as a consulting service.
292
293Non-maskable interrupts (NMI) cannot be disabled, and ISRs which execute at
294this level MUST NEVER issue RTEMS system calls.  If a directive is invoked,
295unpredictable results may occur due to the inability of RTEMS to protect its
296critical sections.  However, ISRs that make no system calls may safely execute
297as non-maskable interrupts.
298
299Default Fatal Error Processing
300==============================
301
302Upon detection of a fatal error by either the application or RTEMS during
303initialization the ``rtems_fatal_error_occurred`` directive supplied by the
304Fatal Error Manager is invoked.  The Fatal Error Manager will invoke the
305user-supplied fatal error handlers.  If no user-supplied handlers are
306configured or all of them return without taking action to shutdown the
307processor or reset, a default fatal error handler is invoked.
308
309Most of the action performed as part of processing the fatal error are
310described in detail in the Fatal Error Manager chapter in the User's Guide.
311However, the if no user provided extension or BSP specific fatal error handler
312takes action, the final default action is to invoke a CPU architecture specific
313function.  Typically this function disables interrupts and halts the processor.
314
315In each of the architecture specific chapters, this describes the precise
316operations of the default CPU specific fatal error handler.
317
318Symmetric Multiprocessing
319=========================
320
321This section contains information about the Symmetric Multiprocessing (SMP)
322status of a particular architecture.
323
324Thread-Local Storage
325====================
326
327In order to support thread-local storage (TLS) the CPU port must implement the
328facilities mandated by the application binary interface (ABI) of the CPU
329architecture.  The CPU port must initialize the TLS area in the
330``_CPU_Context_Initialize()`` function.  There are support functions available
331via ``#include <rtems/score/tls.h>`` which implement Variants I and II
332according to :cite:`Drepper:2013:TLS`.
333
334``_TLS_TCB_at_area_begin_initialize()``
335    Uses Variant I, TLS offsets emitted by linker takes the TCB into account.
336    For a reference implementation see :file:`cpukit/score/cpu/arm/cpu.c`.
337
338``_TLS_TCB_before_TLS_block_initialize()``
339    Uses Variant I, TLS offsets emitted by linker neglects the TCB.  For a
340    reference implementation see
341    :file:`c/src/lib/libcpu/powerpc/new-exceptions/cpu.c`.
342
343``_TLS_TCB_after_TLS_block_initialize()``
344    Uses Variant II.  For a reference implementation see
345    :file:`cpukit/score/cpu/sparc/cpu.c`.
346
347The board support package (BSP) must provide the following sections and symbols
348in its linker command file:
349
350.. code-block:: c
351
352    .tdata : {
353      _TLS_Data_begin = .;
354      *(.tdata .tdata.* .gnu.linkonce.td.*)
355      _TLS_Data_end = .;
356    }
357    .tbss : {
358      _TLS_BSS_begin = .;
359      *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon)
360      _TLS_BSS_end = .;
361    }
362    _TLS_Data_size = _TLS_Data_end - _TLS_Data_begin;
363    _TLS_Data_begin = _TLS_Data_size != 0 ? _TLS_Data_begin : _TLS_BSS_begin;
364    _TLS_Data_end = _TLS_Data_size != 0 ? _TLS_Data_end : _TLS_BSS_begin;
365    _TLS_BSS_size = _TLS_BSS_end - _TLS_BSS_begin;
366    _TLS_Size = _TLS_BSS_end - _TLS_Data_begin;
367    _TLS_Alignment = MAX (ALIGNOF (.tdata), ALIGNOF (.tbss));
368
369CPU counter
370===========
371
372The CPU support must implement the CPU counter interface.  A CPU counter is
373some free-running counter.  It ticks usually with a frequency close to the CPU
374or system bus clock.  On some architectures the actual implementation is board
375support package dependent.  The CPU counter is used for profiling of low-level
376functions.  It is also used to implement two busy wait functions
377``rtems_counter_delay_ticks()`` and ``rtems_counter_delay_nanoseconds()`` which
378may be used in device drivers.  It may be also used as an entropy source for
379random number generators.
380
381The CPU counter interface uses a CPU port specific unsigned integer type
382``CPU_Counter_ticks`` to represent CPU counter values.  The CPU port must
383provide the following two functions
384
385- ``_CPU_Counter_read()`` to read the current CPU counter value, and
386
387- ``_CPU_Counter_difference()`` to get the difference between two CPU
388  counter values.
389
390Interrupt Profiling
391===================
392
393The RTEMS profiling needs support by the CPU port for the interrupt entry and
394exit times.  In case profiling is enabled via the RTEMS build configuration
395option ``--enable-profiling`` (in this case the pre-processor symbol
396``RTEMS_PROFILING`` is defined) the CPU port may provide data for the interrupt
397entry and exit times of the outer-most interrupt.  The CPU port can feed
398interrupt entry and exit times with the
399``_Profiling_Outer_most_interrupt_entry_and_exit()`` function (``#include
400<rtems/score/profiling.h>``).  For an example please have a look at
401:file:`cpukit/score/cpu/arm/arm_exc_interrupt.S`.
402
403Board Support Packages
404======================
405
406An RTEMS Board Support Package (BSP) must be designed to support a particular
407processor model and target board combination.
408
409In each of the architecture specific chapters, this section will present a
410discussion of architecture specific BSP issues.  For more information on
411developing a BSP, refer to BSP and Device Driver Development Guide and the
412chapter titled Board Support Packages in the RTEMS Applications User's Guide.
413
414System Reset
415------------
416
417An RTEMS based application is initiated or re-initiated when the processor is
418reset or transfer is passed to it from a boot monitor or ROM monitor.
419
420In each of the architecture specific chapters, this subsection describes the
421actions that the BSP must tak assuming the application gets control when the
422microprocessor is reset.
Note: See TracBrowser for help on using the repository browser.