source: rtems/doc/porting/cpumodels.t @ 6449498

4.104.114.84.95
Last change on this file since 6449498 was 6449498, checked in by Joel Sherrill <joel.sherrill@…>, on Jan 17, 2002 at 9:47:47 PM

2001-01-17 Joel Sherrill <joel@…>

  • SUPPORT, LICENSE: New files.
  • Numerous files touched as part of merging the 4.5 branch onto the mainline development trunk and ensuring that the script that cuts snapshots and releases works on the documentation.
  • Property mode set to 100644
File size: 6.1 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-2002.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@chapter CPU Model Variations
10
11XXX enhance using portability presentation from CS595 class.  See
12general/portability.ppt.
13
14Since the text in the next section was written, RTEMS view of
15portability has grown to distinguish totally portable, CPU
16family dependent, CPU model dependent, peripheral chip dependent
17and board dependent.  This text was part of a larger paper that
18did not even cover portability completely as it existed when this
19was written and certainly is out of date now. :)
20
21
22@section Overview of RTEMS Portability
23
24RTEMS was designed to be a highly portable, reusable software component. 
25This reflects the fundamental nature of embedded systems in which hardware
26components, ranging from boards to peripherals to even the processor
27itself, are selected specifically to meet the requirements of a particular
28project.
29
30@subsection Processor Families
31
32Since there are a wide variety of embedded systems, there are a wide
33variety of processors targeting embedded systems. RTEMS alleviates some of
34the burden on the embedded systems programmer by providing a consistent,
35high-performance environment regardless of the target processor.  RTEMS
36has been ported to a variety of microprocessor families including:
37
38@itemize @bullet
39
40@item Motorola ColdFire
41
42@item Motorola MC68xxx
43
44@item Motorola MC683xx
45
46@item Intel ix86 (i386 and above)
47
48@item Intel i960
49
50@item MIPS
51
52@item PowerPC 4xx, 5xx, 6xx, 7xx, and 8xx
53
54@item SPARC
55
56@item Hewlett-Packard PA-RISC
57
58@item AMD A29K
59
60@end itemize
61
62
63In addition, there is a port of RTEMS to UNIX that uses standard UNIX
64services to simulate the embedded environment.
65
66Each RTEMS port supplies a well-defined set of services that are the
67foundation for the highly portable RTEMS and POSIX API implementations. 
68When porting to a new processor family, one must provide the processor
69dependent implementation of these services.  This set of processor
70dependent core services includes software to perform interrupt
71dispatching, context switches, and manipulate task register sets.
72
73The RTEMS approach to handling varying processor models reflects the
74approach taken by the designers of the processors themselves.  In each
75processor family, there is a core architecture that must be implemented on
76all processor models within the family to provide any level of
77compatibility.  Many of the modern RISC architectures refer to this as the
78Architectural Definition.  The Architectural Definition is intended to be
79independent of any particular implementation. Additionally, there is a
80feature set which is allowed to vary in a defined way amongst the
81processor models.  These feature sets may be defined as Optional in the
82Architectural Definition, be left as implementation defined
83characteristics, or be processor model specific extensions.  Support for
84floating point, virtual memory, and low power mode are common Optional
85features included in an Architectural Definition.
86
87The processor family dependent software in RTEMS includes a definition of
88which features are present in each supported processor model.  This often
89makes adding support for a new processor model within a supported family
90as simple as determining which features are present in the new processor
91implementation.  If the new processor model varies in a way previously
92unaccounted for, then this must be addressed.  This could be the result of
93a new Optional feature set being added to the Architectural Definition. 
94Alternatively, this particular processor model could have a new and
95different implementation of a feature left as undefined in the
96Architectural Definition.  This would require software to be written to
97utilize that feature.
98
99There is a relatively small set of features that may vary in a processor
100family.  As the number of processor models in the family grow, the
101addition of each new model only requires adding an entry for the new model
102to the single feature table.  It does not require searching for every
103conditional based on processor model and adding the new model in the
104appropriate place.  This significantly eases the burden of adding a new
105processor model as it centralizes and logically simplifies the process.
106
107@subsection Boards
108
109Being portable both between models within a processor family and across
110processor families is not enough to address the needs of embedded systems
111developers.  Custom board development is the norm for embedded systems. 
112Each of these boards is optimized for a particular project.  The processor
113and peripheral set have been chosen to meet a particular set of system
114requirements.  The tools in the embedded systems developers’ toolbox must
115support their project’s unique board.  RTEMS addresses this issue via the
116Board Support Package.
117
118RTEMS segregates board specific code to make it possible for the embedded
119systems developer to easily replace and customize this software.  A
120minimal Board Support Package includes device drivers for a clock tick,
121console I/O, and a benchmark timer (optional) as well as startup and
122miscellaneous support code.  The Board Support Package for a project may
123be extended to include the device drivers for any peripherals on the
124custom board.
125
126@subsection Applications
127
128One important design goal of RTEMS was to provide a bridge between the
129application software and the target hardware.  Most hardware dependencies
130for real-time applications can be localized to the low level device
131drivers which provide an abstracted view of the hardware.  The RTEMS I/O
132interface manager provides an efficient tool for incorporating these
133hardware dependencies into the system while simultaneously providing a
134general mechanism to the application code that accesses them.  A well
135designed real-time system can benefit from this architecture by building a
136rich library of standard application components which can be used
137repeatedly in other real-time projects. The following figure illustrates
138how RTEMS serves as a buffer between the project dependent application
139code and the target hardware.
140
141@section Coding Issues
142
143XXX deal with this as it applies to score/cpu.  Section name may
144be bad.
Note: See TracBrowser for help on using the repository browser.