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