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 | @ifinfo |
---|
10 | @end ifinfo |
---|
11 | @chapter Intel/AMD x86 Specific Information |
---|
12 | |
---|
13 | The Real Time Executive for Multiprocessor Systems |
---|
14 | (RTEMS) is designed to be portable across multiple processor |
---|
15 | architectures. However, the nature of real-time systems makes |
---|
16 | it essential that the application designer understand certain |
---|
17 | processor dependent implementation details. These processor |
---|
18 | dependencies include calling convention, board support package |
---|
19 | issues, interrupt processing, exact RTEMS memory requirements, |
---|
20 | performance data, header files, and the assembly language |
---|
21 | interface to the executive. |
---|
22 | |
---|
23 | For information on the i386 processor, refer to the |
---|
24 | following documents: |
---|
25 | |
---|
26 | @itemize @bullet |
---|
27 | @item @cite{386 Programmer's Reference Manual, Intel, Order No. 230985-002}. |
---|
28 | |
---|
29 | @item @cite{386 Microprocessor Hardware Reference Manual, Intel, |
---|
30 | Order No. 231732-003}. |
---|
31 | |
---|
32 | @item @cite{80386 System Software Writer's Guide, Intel, Order No. 231499-001}. |
---|
33 | |
---|
34 | @item @cite{80387 Programmer's Reference Manual, Intel, Order No. 231917-001}. |
---|
35 | @end itemize |
---|
36 | |
---|
37 | It is highly recommended that the i386 RTEMS |
---|
38 | application developer obtain and become familiar with Intel's |
---|
39 | 386 Programmer's Reference Manual. |
---|
40 | |
---|
41 | @c |
---|
42 | @c COPYRIGHT (c) 1988-2002. |
---|
43 | @c On-Line Applications Research Corporation (OAR). |
---|
44 | @c All rights reserved. |
---|
45 | @c |
---|
46 | @c $Id$ |
---|
47 | @c |
---|
48 | |
---|
49 | @section CPU Model Dependent Features |
---|
50 | |
---|
51 | |
---|
52 | Microprocessors are generally classified into |
---|
53 | families with a variety of CPU models or implementations within |
---|
54 | that family. Within a processor family, there is a high level |
---|
55 | of binary compatibility. This family may be based on either an |
---|
56 | architectural specification or on maintaining compatibility with |
---|
57 | a popular processor. Recent microprocessor families such as the |
---|
58 | SPARC or PowerPC are based on an architectural specification |
---|
59 | which is independent or any particular CPU model or |
---|
60 | implementation. Older families such as the M68xxx and the iX86 |
---|
61 | evolved as the manufacturer strived to produce higher |
---|
62 | performance processor models which maintained binary |
---|
63 | compatibility with older models. |
---|
64 | |
---|
65 | RTEMS takes advantage of the similarity of the |
---|
66 | various models within a CPU family. Although the models do vary |
---|
67 | in significant ways, the high level of compatibility makes it |
---|
68 | possible to share the bulk of the CPU dependent executive code |
---|
69 | across the entire family. Each processor family supported by |
---|
70 | RTEMS has a list of features which vary between CPU models |
---|
71 | within a family. For example, the most common model dependent |
---|
72 | feature regardless of CPU family is the presence or absence of a |
---|
73 | floating point unit or coprocessor. When defining the list of |
---|
74 | features present on a particular CPU model, one simply notes |
---|
75 | that floating point hardware is or is not present and defines a |
---|
76 | single constant appropriately. Conditional compilation is |
---|
77 | utilized to include the appropriate source code for this CPU |
---|
78 | model's feature set. It is important to note that this means |
---|
79 | that RTEMS is thus compiled using the appropriate feature set |
---|
80 | and compilation flags optimal for this CPU model used. The |
---|
81 | alternative would be to generate a binary which would execute on |
---|
82 | all family members using only the features which were always |
---|
83 | present. |
---|
84 | |
---|
85 | This chapter presents the set of features which vary |
---|
86 | across i386 implementations and are of importance to RTEMS. |
---|
87 | The set of CPU model feature macros are defined in the file |
---|
88 | cpukit/score/cpu/i386/i386.h based upon the particular CPU |
---|
89 | model defined on the compilation command line. |
---|
90 | |
---|
91 | @subsection CPU Model Name |
---|
92 | |
---|
93 | The macro CPU_MODEL_NAME is a string which designates |
---|
94 | the name of this CPU model. For example, for the Intel i386 without an |
---|
95 | i387 coprocessor, this macro is set to the string "i386 with i387". |
---|
96 | |
---|
97 | @subsection bswap Instruction |
---|
98 | |
---|
99 | The macro I386_HAS_BSWAP is set to 1 to indicate that |
---|
100 | this CPU model has the @code{bswap} instruction which |
---|
101 | endian swaps a thirty-two bit quantity. This instruction |
---|
102 | appears to be present in all CPU models |
---|
103 | i486's and above. |
---|
104 | |
---|
105 | @subsection Floating Point Unit |
---|
106 | |
---|
107 | The macro I386_HAS_FPU is set to 1 to indicate that |
---|
108 | this CPU model has a hardware floating point unit and 0 |
---|
109 | otherwise. The hardware floating point may be on-chip (as in the |
---|
110 | case of an i486DX or Pentium) or as a coprocessor (as in the case of |
---|
111 | an i386/i387 combination). |
---|
112 | @c |
---|
113 | @c COPYRIGHT (c) 1988-2002. |
---|
114 | @c On-Line Applications Research Corporation (OAR). |
---|
115 | @c All rights reserved. |
---|
116 | @c |
---|
117 | @c $Id$ |
---|
118 | @c |
---|
119 | |
---|
120 | @section Calling Conventions |
---|
121 | |
---|
122 | |
---|
123 | Each high-level language compiler generates |
---|
124 | subroutine entry and exit code based upon a set of rules known |
---|
125 | as the compiler's calling convention. These rules address the |
---|
126 | following issues: |
---|
127 | |
---|
128 | @itemize @bullet |
---|
129 | @item register preservation and usage |
---|
130 | |
---|
131 | @item parameter passing |
---|
132 | |
---|
133 | @item call and return mechanism |
---|
134 | @end itemize |
---|
135 | |
---|
136 | A compiler's calling convention is of importance when |
---|
137 | interfacing to subroutines written in another language either |
---|
138 | assembly or high-level. Even when the high-level language and |
---|
139 | target processor are the same, different compilers may use |
---|
140 | different calling conventions. As a result, calling conventions |
---|
141 | are both processor and compiler dependent. |
---|
142 | |
---|
143 | @subsection Processor Background |
---|
144 | |
---|
145 | The i386 architecture supports a simple yet effective |
---|
146 | call and return mechanism. A subroutine is invoked via the call |
---|
147 | (call) instruction. This instruction pushes the return address |
---|
148 | on the stack. The return from subroutine (ret) instruction pops |
---|
149 | the return address off the current stack and transfers control |
---|
150 | to that instruction. It is is important to note that the i386 |
---|
151 | call and return mechanism does not automatically save or restore |
---|
152 | any registers. It is the responsibility of the high-level |
---|
153 | language compiler to define the register preservation and usage |
---|
154 | convention. |
---|
155 | |
---|
156 | @subsection Calling Mechanism |
---|
157 | |
---|
158 | All RTEMS directives are invoked using a call |
---|
159 | instruction and return to the user application via the ret |
---|
160 | instruction. |
---|
161 | |
---|
162 | @subsection Register Usage |
---|
163 | |
---|
164 | As discussed above, the call instruction does not |
---|
165 | automatically save any registers. RTEMS uses the registers EAX, |
---|
166 | ECX, and EDX as scratch registers. These registers are not |
---|
167 | preserved by RTEMS directives therefore, the contents of these |
---|
168 | registers should not be assumed upon return from any RTEMS |
---|
169 | directive. |
---|
170 | |
---|
171 | @subsection Parameter Passing |
---|
172 | |
---|
173 | RTEMS assumes that arguments are placed on the |
---|
174 | current stack before the directive is invoked via the call |
---|
175 | instruction. The first argument is assumed to be closest to the |
---|
176 | return address on the stack. This means that the first argument |
---|
177 | of the C calling sequence is pushed last. The following |
---|
178 | pseudo-code illustrates the typical sequence used to call a |
---|
179 | RTEMS directive with three (3) arguments: |
---|
180 | |
---|
181 | @example |
---|
182 | push third argument |
---|
183 | push second argument |
---|
184 | push first argument |
---|
185 | invoke directive |
---|
186 | remove arguments from the stack |
---|
187 | @end example |
---|
188 | |
---|
189 | The arguments to RTEMS are typically pushed onto the |
---|
190 | stack using a push instruction. These arguments must be removed |
---|
191 | from the stack after control is returned to the caller. This |
---|
192 | removal is typically accomplished by adding the size of the |
---|
193 | argument list in bytes to the stack pointer. |
---|
194 | |
---|
195 | @subsection User-Provided Routines |
---|
196 | |
---|
197 | All user-provided routines invoked by RTEMS, such as |
---|
198 | user extensions, device drivers, and MPCI routines, must also |
---|
199 | adhere to these calling conventions. |
---|
200 | |
---|
201 | @c |
---|
202 | @c COPYRIGHT (c) 1988-2002. |
---|
203 | @c On-Line Applications Research Corporation (OAR). |
---|
204 | @c All rights reserved. |
---|
205 | @c |
---|
206 | @c $Id$ |
---|
207 | @c |
---|
208 | |
---|
209 | @section Memory Model |
---|
210 | |
---|
211 | |
---|
212 | A processor may support any combination of memory |
---|
213 | models ranging from pure physical addressing to complex demand |
---|
214 | paged virtual memory systems. RTEMS supports a flat memory |
---|
215 | model which ranges contiguously over the processor's allowable |
---|
216 | address space. RTEMS does not support segmentation or virtual |
---|
217 | memory of any kind. The appropriate memory model for RTEMS |
---|
218 | provided by the targeted processor and related characteristics |
---|
219 | of that model are described in this chapter. |
---|
220 | |
---|
221 | @subsection Flat Memory Model |
---|
222 | |
---|
223 | RTEMS supports the i386 protected mode, flat memory |
---|
224 | model with paging disabled. In this mode, the i386 |
---|
225 | automatically converts every address from a logical to a |
---|
226 | physical address each time it is used. The i386 uses |
---|
227 | information provided in the segment registers and the Global |
---|
228 | Descriptor Table to convert these addresses. RTEMS assumes the |
---|
229 | existence of the following segments: |
---|
230 | |
---|
231 | @itemize @bullet |
---|
232 | @item a single code segment at protection level (0) which |
---|
233 | contains all application and executive code. |
---|
234 | |
---|
235 | @item a single data segment at protection level zero (0) which |
---|
236 | contains all application and executive data. |
---|
237 | @end itemize |
---|
238 | |
---|
239 | The i386 segment registers and associated selectors |
---|
240 | must be initialized when the initialize_executive directive is |
---|
241 | invoked. RTEMS treats the segment registers as system registers |
---|
242 | and does not modify or context switch them. |
---|
243 | |
---|
244 | This i386 memory model supports a flat 32-bit address |
---|
245 | space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 |
---|
246 | gigabytes). Each address is represented by a 32-bit value and |
---|
247 | is byte addressable. The address may be used to reference a |
---|
248 | single byte, half-word (2-bytes), or word (4 bytes). |
---|
249 | |
---|
250 | RTEMS does not require that logical addresses map |
---|
251 | directly to physical addresses, although it is desirable in many |
---|
252 | applications to do so. If logical and physical addresses are |
---|
253 | not the same, then an additional selector will be required so |
---|
254 | RTEMS can access the Interrupt Descriptor Table to install |
---|
255 | interrupt service routines. The selector number of this segment |
---|
256 | is provided to RTEMS in the CPU Dependent Information Table. |
---|
257 | |
---|
258 | By not requiring that logical addresses map directly |
---|
259 | to physical addresses, the memory space of an RTEMS application |
---|
260 | can be separated from that of a ROM monitor. For example, on |
---|
261 | the Force Computers CPU386, the ROM monitor loads application |
---|
262 | programs into a logical address space where logical address |
---|
263 | 0x00000000 corresponds to physical address 0x0002000. On this |
---|
264 | board, RTEMS and the application use virtual addresses which do |
---|
265 | not map to physical addresses. |
---|
266 | |
---|
267 | RTEMS assumes that the DS and ES registers contain |
---|
268 | the selector for the single data segment when a directive is |
---|
269 | invoked. This assumption is especially important when |
---|
270 | developing interrupt service routines. |
---|
271 | |
---|
272 | @c |
---|
273 | @c COPYRIGHT (c) 1988-2002. |
---|
274 | @c On-Line Applications Research Corporation (OAR). |
---|
275 | @c All rights reserved. |
---|
276 | @c |
---|
277 | @c $Id$ |
---|
278 | @c |
---|
279 | |
---|
280 | @section Interrupt Processing |
---|
281 | |
---|
282 | |
---|
283 | Different types of processors respond to the |
---|
284 | occurrence of an interrupt in their own unique fashion. In |
---|
285 | addition, each processor type provides a control mechanism to |
---|
286 | allow the proper handling of an interrupt. The processor |
---|
287 | dependent response to the interrupt modifies the execution state |
---|
288 | and results in the modification of the execution stream. This |
---|
289 | modification usually requires that an interrupt handler utilize |
---|
290 | the provided control mechanisms to return to the normal |
---|
291 | processing stream. Although RTEMS hides many of the processor |
---|
292 | dependent details of interrupt processing, it is important to |
---|
293 | understand how the RTEMS interrupt manager is mapped onto the |
---|
294 | processor's unique architecture. Discussed in this chapter are |
---|
295 | the the processor's response and control mechanisms as they |
---|
296 | pertain to RTEMS. |
---|
297 | |
---|
298 | @subsection Vectoring of Interrupt Handler |
---|
299 | |
---|
300 | Although the i386 supports multiple privilege levels, |
---|
301 | RTEMS and all user software executes at privilege level 0. This |
---|
302 | decision was made by the RTEMS designers to enhance |
---|
303 | compatibility with processors which do not provide sophisticated |
---|
304 | protection facilities like those of the i386. This decision |
---|
305 | greatly simplifies the discussion of i386 processing, as one |
---|
306 | need only consider interrupts without privilege transitions. |
---|
307 | |
---|
308 | Upon receipt of an interrupt the i386 automatically |
---|
309 | performs the following actions: |
---|
310 | |
---|
311 | @itemize @bullet |
---|
312 | @item pushes the EFLAGS register |
---|
313 | |
---|
314 | @item pushes the far address of the interrupted instruction |
---|
315 | |
---|
316 | @item vectors to the interrupt service routine (ISR). |
---|
317 | @end itemize |
---|
318 | |
---|
319 | A nested interrupt is processed similarly by the |
---|
320 | i386. |
---|
321 | |
---|
322 | @subsection Interrupt Stack Frame |
---|
323 | |
---|
324 | The structure of the Interrupt Stack Frame for the |
---|
325 | i386 which is placed on the interrupt stack by the processor in |
---|
326 | response to an interrupt is as follows: |
---|
327 | |
---|
328 | @ifset use-ascii |
---|
329 | @example |
---|
330 | @group |
---|
331 | +----------------------+ |
---|
332 | | Old EFLAGS Register | ESP+8 |
---|
333 | +----------+-----------+ |
---|
334 | | UNUSED | Old CS | ESP+4 |
---|
335 | +----------+-----------+ |
---|
336 | | Old EIP | ESP |
---|
337 | +----------------------+ |
---|
338 | @end group |
---|
339 | @end example |
---|
340 | @end ifset |
---|
341 | |
---|
342 | @ifset use-tex |
---|
343 | @sp 1 |
---|
344 | @tex |
---|
345 | \centerline{\vbox{\offinterlineskip\halign{ |
---|
346 | \strut\vrule#& |
---|
347 | \hbox to 1.00in{\enskip\hfil#\hfil}& |
---|
348 | \vrule#& |
---|
349 | \hbox to 1.00in{\enskip\hfil#\hfil}& |
---|
350 | \vrule#& |
---|
351 | \hbox to 0.75in{\enskip\hfil#\hfil} |
---|
352 | \cr |
---|
353 | \multispan{4}\hrulefill\cr |
---|
354 | & \multispan{3} Old EFLAGS Register\quad&&ESP+8\cr |
---|
355 | \multispan{4}\hrulefill\cr |
---|
356 | &UNUSED &&Old CS &&ESP+4\cr |
---|
357 | \multispan{4}\hrulefill\cr |
---|
358 | & \multispan{3} Old EIP && ESP\cr |
---|
359 | \multispan{4}\hrulefill\cr |
---|
360 | }}\hfil} |
---|
361 | @end tex |
---|
362 | @end ifset |
---|
363 | |
---|
364 | @ifset use-html |
---|
365 | @html |
---|
366 | <CENTER> |
---|
367 | <TABLE COLS=3 WIDTH="40%" BORDER=2> |
---|
368 | <TR><TD ALIGN=center COLSPAN=2><STRONG>Old EFLAGS Register</STRONG></TD> |
---|
369 | <TD ALIGN=center>0x0</TD></TR> |
---|
370 | <TR><TD ALIGN=center><STRONG>UNUSED</STRONG></TD> |
---|
371 | <TD ALIGN=center><STRONG>Old CS</STRONG></TD> |
---|
372 | <TD ALIGN=center>0x2</TD></TR> |
---|
373 | <TR><TD ALIGN=center COLSPAN=2><STRONG>Old EIP</STRONG></TD> |
---|
374 | <TD ALIGN=center>0x4</TD></TR> |
---|
375 | </TABLE> |
---|
376 | </CENTER> |
---|
377 | @end html |
---|
378 | @end ifset |
---|
379 | |
---|
380 | @subsection Interrupt Levels |
---|
381 | |
---|
382 | Although RTEMS supports 256 interrupt levels, the |
---|
383 | i386 only supports two -- enabled and disabled. Interrupts are |
---|
384 | enabled when the interrupt-enable flag (IF) in the extended |
---|
385 | flags (EFLAGS) is set. Conversely, interrupt processing is |
---|
386 | inhibited when the IF is cleared. During a non-maskable |
---|
387 | interrupt, all other interrupts, including other non-maskable |
---|
388 | ones, are inhibited. |
---|
389 | |
---|
390 | RTEMS interrupt levels 0 and 1 such that level zero |
---|
391 | (0) indicates that interrupts are fully enabled and level one |
---|
392 | that interrupts are disabled. All other RTEMS interrupt levels |
---|
393 | are undefined and their behavior is unpredictable. |
---|
394 | |
---|
395 | @subsection Disabling of Interrupts by RTEMS |
---|
396 | |
---|
397 | During the execution of directive calls, critical |
---|
398 | sections of code may be executed. When these sections are |
---|
399 | encountered, RTEMS disables interrupts before the execution of |
---|
400 | this section and restores them to the previous level upon |
---|
401 | completion of the section. RTEMS has been optimized to insure |
---|
402 | that interrupts are disabled for less than RTEMS_MAXIMUM_DISABLE_PERIOD |
---|
403 | microseconds on a RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz i386 with zero |
---|
404 | wait states. These numbers will vary based the number of wait states |
---|
405 | and processor speed present on the target board. [NOTE: The maximum |
---|
406 | period with interrupts disabled within RTEMS was last calculated for |
---|
407 | Release RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] |
---|
408 | |
---|
409 | Non-maskable interrupts (NMI) cannot be disabled, and |
---|
410 | ISRs which execute at this level MUST NEVER issue RTEMS system |
---|
411 | calls. If a directive is invoked, unpredictable results may |
---|
412 | occur due to the inability of RTEMS to protect its critical |
---|
413 | sections. However, ISRs that make no system calls may safely |
---|
414 | execute as non-maskable interrupts. |
---|
415 | |
---|
416 | @subsection Interrupt Stack |
---|
417 | |
---|
418 | The i386 family does not support a dedicated hardware |
---|
419 | interrupt stack. On this processor, RTEMS allocates and manages |
---|
420 | a dedicated interrupt stack. As part of vectoring a non-nested |
---|
421 | interrupt service routine, RTEMS switches from the stack of the |
---|
422 | interrupted task to a dedicated interrupt stack. When a |
---|
423 | non-nested interrupt returns, RTEMS switches back to the stack |
---|
424 | of the interrupted stack. The current stack pointer is not |
---|
425 | altered by RTEMS on nested interrupt. |
---|
426 | |
---|
427 | Without a dedicated interrupt stack, every task in |
---|
428 | the system MUST have enough stack space to accommodate the worst |
---|
429 | case stack usage of that particular task and the interrupt |
---|
430 | service routines COMBINED. By supporting a dedicated interrupt |
---|
431 | stack, RTEMS significantly lowers the stack requirements for |
---|
432 | each task. |
---|
433 | |
---|
434 | RTEMS allocates the dedicated interrupt stack from |
---|
435 | the Workspace Area. The amount of memory allocated for the |
---|
436 | interrupt stack is determined by the interrupt_stack_size field |
---|
437 | in the CPU Configuration Table. |
---|
438 | |
---|
439 | @c |
---|
440 | @c COPYRIGHT (c) 1988-2002. |
---|
441 | @c On-Line Applications Research Corporation (OAR). |
---|
442 | @c All rights reserved. |
---|
443 | @c |
---|
444 | @c $Id$ |
---|
445 | @c |
---|
446 | |
---|
447 | @section Default Fatal Error Processing |
---|
448 | |
---|
449 | |
---|
450 | Upon detection of a fatal error by either the |
---|
451 | application or RTEMS the fatal error manager is invoked. The |
---|
452 | fatal error manager will invoke the user-supplied fatal error |
---|
453 | handlers. If no user-supplied handlers are configured, the |
---|
454 | RTEMS provided default fatal error handler is invoked. If the |
---|
455 | user-supplied fatal error handlers return to the executive the |
---|
456 | default fatal error handler is then invoked. This chapter |
---|
457 | describes the precise operations of the default fatal error |
---|
458 | handler. |
---|
459 | |
---|
460 | @subsection Default Fatal Error Handler Operations |
---|
461 | |
---|
462 | The default fatal error handler which is invoked by |
---|
463 | the fatal_error_occurred directive when there is no user handler |
---|
464 | configured or the user handler returns control to RTEMS. The |
---|
465 | default fatal error handler disables processor interrupts, |
---|
466 | places the error code in EAX, and executes a HLT instruction to |
---|
467 | halt the processor. |
---|
468 | |
---|
469 | @c |
---|
470 | @c COPYRIGHT (c) 1988-2002. |
---|
471 | @c On-Line Applications Research Corporation (OAR). |
---|
472 | @c All rights reserved. |
---|
473 | @c |
---|
474 | @c $Id$ |
---|
475 | @c |
---|
476 | |
---|
477 | @section Board Support Packages |
---|
478 | |
---|
479 | |
---|
480 | An RTEMS Board Support Package (BSP) must be designed to support a |
---|
481 | particular processor and target board combination. This chapter presents a |
---|
482 | discussion of i386 specific BSP issues. For more information on developing |
---|
483 | a BSP, refer to the chapter titled Board Support Packages in the RTEMS |
---|
484 | Applications User's Guide. |
---|
485 | |
---|
486 | @subsection System Reset |
---|
487 | |
---|
488 | An RTEMS based application is initiated when the i386 |
---|
489 | processor is reset. When the i386 is reset, |
---|
490 | |
---|
491 | @itemize @bullet |
---|
492 | |
---|
493 | @item The EAX register is set to indicate the results of the processor's |
---|
494 | power-up self test. If the self-test was not executed, the contents of |
---|
495 | this register are undefined. Otherwise, a non-zero value indicates the |
---|
496 | processor is faulty and a zero value indicates a successful self-test. |
---|
497 | |
---|
498 | @item The DX register holds a component identifier and revision level. DH |
---|
499 | contains 3 to indicate an i386 component and DL contains a unique revision |
---|
500 | level indicator. |
---|
501 | |
---|
502 | @item Control register zero (CR0) is set such that the processor is in real |
---|
503 | mode with paging disabled. Other portions of CR0 are used to indicate the |
---|
504 | presence of a numeric coprocessor. |
---|
505 | |
---|
506 | @item All bits in the extended flags register (EFLAG) which are not |
---|
507 | permanently set are cleared. This inhibits all maskable interrupts. |
---|
508 | |
---|
509 | @item The Interrupt Descriptor Register (IDTR) is set to point at address |
---|
510 | zero. |
---|
511 | |
---|
512 | @item All segment registers are set to zero. |
---|
513 | |
---|
514 | @item The instruction pointer is set to 0x0000FFF0. The first instruction |
---|
515 | executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts |
---|
516 | the upper twelve address until the first intersegment (FAR) JMP or CALL |
---|
517 | instruction. When a JMP or CALL is executed, the upper twelve address |
---|
518 | lines are lowered and the processor begins executing in the first megabyte |
---|
519 | of memory. |
---|
520 | |
---|
521 | @end itemize |
---|
522 | |
---|
523 | Typically, an intersegment JMP to the application's initialization code is |
---|
524 | placed at address 0xFFFFFFF0. |
---|
525 | |
---|
526 | @subsection Processor Initialization |
---|
527 | |
---|
528 | This initialization code is responsible for initializing all data |
---|
529 | structures required by the i386 in protected mode and for actually entering |
---|
530 | protected mode. The i386 must be placed in protected mode and the segment |
---|
531 | registers and associated selectors must be initialized before the |
---|
532 | initialize_executive directive is invoked. |
---|
533 | |
---|
534 | The initialization code is responsible for initializing the Global |
---|
535 | Descriptor Table such that the i386 is in the thirty-two bit flat memory |
---|
536 | model with paging disabled. In this mode, the i386 automatically converts |
---|
537 | every address from a logical to a physical address each time it is used. |
---|
538 | For more information on the memory model used by RTEMS, please refer to the |
---|
539 | Memory Model chapter in this document. |
---|
540 | |
---|
541 | Since the processor is in real mode upon reset, the processor must be |
---|
542 | switched to protected mode before RTEMS can execute. Before switching to |
---|
543 | protected mode, at least one descriptor table and two descriptors must be |
---|
544 | created. Descriptors are needed for a code segment and a data segment. ( |
---|
545 | This will give you the flat memory model.) The stack can be placed in a |
---|
546 | normal read/write data segment, so no descriptor for the stack is needed. |
---|
547 | Before the GDT can be used, the base address and limit must be loaded into |
---|
548 | the GDTR register using an LGDT instruction. |
---|
549 | |
---|
550 | If the hardware allows an NMI to be generated, you need to create the IDT |
---|
551 | and a gate for the NMI interrupt handler. Before the IDT can be used, the |
---|
552 | base address and limit for the idt must be loaded into the IDTR register |
---|
553 | using an LIDT instruction. |
---|
554 | |
---|
555 | Protected mode is entered by setting thye PE bit in the CR0 register. |
---|
556 | Either a LMSW or MOV CR0 instruction may be used to set this bit. Because |
---|
557 | the processor overlaps the interpretation of several instructions, it is |
---|
558 | necessary to discard the instructions from the read-ahead cache. A JMP |
---|
559 | instruction immediately after the LMSW changes the flow and empties the |
---|
560 | processor if intructions which have been pre-fetched and/or decoded. At |
---|
561 | this point, the processor is in protected mode and begins to perform |
---|
562 | protected mode application initialization. |
---|
563 | |
---|
564 | If the application requires that the IDTR be some value besides zero, then |
---|
565 | it should set it to the required value at this point. All tasks share the |
---|
566 | same i386 IDTR value. Because interrupts are enabled automatically by |
---|
567 | RTEMS as part of the initialize_executive directive, the IDTR MUST be set |
---|
568 | properly before this directive is invoked to insure correct interrupt |
---|
569 | vectoring. If processor caching is to be utilized, then it should be |
---|
570 | enabled during the reset application initialization code. The reset code |
---|
571 | which is executed before the call to initialize_executive has the following |
---|
572 | requirements: |
---|
573 | |
---|
574 | For more information regarding the i386s data structures and their |
---|
575 | contents, refer to Intel's 386 Programmer's Reference Manual. |
---|
576 | |
---|