From d755cbd36f5b4410994bcd468aee983471ab7167 Mon Sep 17 00:00:00 2001 From: Amar Takhar Date: Sat, 16 Jan 2016 20:13:02 -0500 Subject: Split document into seperate files by section. --- cpu_supplement/intel_amd_x86.rst | 320 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 320 insertions(+) create mode 100644 cpu_supplement/intel_amd_x86.rst (limited to 'cpu_supplement/intel_amd_x86.rst') diff --git a/cpu_supplement/intel_amd_x86.rst b/cpu_supplement/intel_amd_x86.rst new file mode 100644 index 0000000..59db1cd --- /dev/null +++ b/cpu_supplement/intel_amd_x86.rst @@ -0,0 +1,320 @@ +Intel/AMD x86 Specific Information +################################## + +This chapter discusses the Intel x86 architecture dependencies +in this port of RTEMS. This family has multiple implementations +from multiple vendors and suffers more from having evolved rather +than being designed for growth. + +For information on the i386 processor, refer to the +following documents: + +- *386 Programmer’s Reference Manual, Intel, Order No. 230985-002*. + +- *386 Microprocessor Hardware Reference Manual, Intel, + Order No. 231732-003*. + +- *80386 System Software Writer’s Guide, Intel, Order No. 231499-001*. + +- *80387 Programmer’s Reference Manual, Intel, Order No. 231917-001*. + +CPU Model Dependent Features +============================ + +This section presents the set of features which vary +across i386 implementations and are of importance to RTEMS. +The set of CPU model feature macros are defined in the file``cpukit/score/cpu/i386/i386.h`` based upon the particular CPU +model specified on the compilation command line. + +bswap Instruction +----------------- + +The macro ``I386_HAS_BSWAP`` is set to 1 to indicate that +this CPU model has the ``bswap`` instruction which +endian swaps a thirty-two bit quantity. This instruction +appears to be present in all CPU models +i486’s and above. + +Calling Conventions +=================== + +Processor Background +-------------------- + +The i386 architecture supports a simple yet effective +call and return mechanism. A subroutine is invoked via the call +(``call``) instruction. This instruction pushes the return address +on the stack. The return from subroutine (``ret``) instruction pops +the return address off the current stack and transfers control +to that instruction. It is is important to note that the i386 +call and return mechanism does not automatically save or restore +any registers. It is the responsibility of the high-level +language compiler to define the register preservation and usage +convention. + +Calling Mechanism +----------------- + +All RTEMS directives are invoked using a call instruction and return to +the user application via the ret instruction. + +Register Usage +-------------- + +As discussed above, the call instruction does not automatically save +any registers. RTEMS uses the registers EAX, ECX, and EDX as scratch +registers. These registers are not preserved by RTEMS directives +therefore, the contents of these registers should not be assumed upon +return from any RTEMS directive. + +Parameter Passing +----------------- + +RTEMS assumes that arguments are placed on the +current stack before the directive is invoked via the call +instruction. The first argument is assumed to be closest to the +return address on the stack. This means that the first argument +of the C calling sequence is pushed last. The following +pseudo-code illustrates the typical sequence used to call a +RTEMS directive with three (3) arguments: +.. code:: c + + push third argument + push second argument + push first argument + invoke directive + remove arguments from the stack + +The arguments to RTEMS are typically pushed onto the +stack using a push instruction. These arguments must be removed +from the stack after control is returned to the caller. This +removal is typically accomplished by adding the size of the +argument list in bytes to the stack pointer. + +Memory Model +============ + +Flat Memory Model +----------------- + +RTEMS supports the i386 protected mode, flat memory +model with paging disabled. In this mode, the i386 +automatically converts every address from a logical to a +physical address each time it is used. The i386 uses +information provided in the segment registers and the Global +Descriptor Table to convert these addresses. RTEMS assumes the +existence of the following segments: + +- a single code segment at protection level (0) which + contains all application and executive code. + +- a single data segment at protection level zero (0) which + contains all application and executive data. + +The i386 segment registers and associated selectors +must be initialized when the initialize_executive directive is +invoked. RTEMS treats the segment registers as system registers +and does not modify or context switch them. + +This i386 memory model supports a flat 32-bit address +space with addresses ranging from 0x00000000 to 0xFFFFFFFF (4 +gigabytes). Each address is represented by a 32-bit value and +is byte addressable. The address may be used to reference a +single byte, half-word (2-bytes), or word (4 bytes). + +Interrupt Processing +==================== + +Although RTEMS hides many of the processor +dependent details of interrupt processing, it is important to +understand how the RTEMS interrupt manager is mapped onto the +processor’s unique architecture. Discussed in this chapter are +the the processor’s response and control mechanisms as they +pertain to RTEMS. + +Vectoring of Interrupt Handler +------------------------------ + +Although the i386 supports multiple privilege levels, +RTEMS and all user software executes at privilege level 0. This +decision was made by the RTEMS designers to enhance +compatibility with processors which do not provide sophisticated +protection facilities like those of the i386. This decision +greatly simplifies the discussion of i386 processing, as one +need only consider interrupts without privilege transitions. + +Upon receipt of an interrupt the i386 automatically +performs the following actions: + +- pushes the EFLAGS register + +- pushes the far address of the interrupted instruction + +- vectors to the interrupt service routine (ISR). + +A nested interrupt is processed similarly by the +i386. + +Interrupt Stack Frame +--------------------- + +The structure of the Interrupt Stack Frame for the +i386 which is placed on the interrupt stack by the processor in +response to an interrupt is as follows: + ++----------------------+-------+ +| Old EFLAGS Register | ESP+8 | ++----------+-----------+-------+ +| UNUSED | Old CS | ESP+4 | ++----------+-----------+-------+ +| Old EIP | ESP | ++----------------------+-------+ + + +Interrupt Levels +---------------- + +Although RTEMS supports 256 interrupt levels, the +i386 only supports two – enabled and disabled. Interrupts are +enabled when the interrupt-enable flag (IF) in the extended +flags (EFLAGS) is set. Conversely, interrupt processing is +inhibited when the IF is cleared. During a non-maskable +interrupt, all other interrupts, including other non-maskable +ones, are inhibited. + +RTEMS interrupt levels 0 and 1 such that level zero +(0) indicates that interrupts are fully enabled and level one +that interrupts are disabled. All other RTEMS interrupt levels +are undefined and their behavior is unpredictable. + +Interrupt Stack +--------------- + +The i386 family does not support a dedicated hardware +interrupt stack. On this processor, RTEMS allocates and manages +a dedicated interrupt stack. As part of vectoring a non-nested +interrupt service routine, RTEMS switches from the stack of the +interrupted task to a dedicated interrupt stack. When a +non-nested interrupt returns, RTEMS switches back to the stack +of the interrupted stack. The current stack pointer is not +altered by RTEMS on nested interrupt. + +Default Fatal Error Processing +============================== + +The default fatal error handler for this architecture disables processor +interrupts, places the error code in EAX, and executes a HLT instruction +to halt the processor. + +Symmetric Multiprocessing +========================= + +SMP is not supported. + +Thread-Local Storage +==================== + +Thread-local storage is not implemented. + +Board Support Packages +====================== + +System Reset +------------ + +An RTEMS based application is initiated when the i386 processor is reset. +When the i386 is reset, + +- The EAX register is set to indicate the results of the processor’s + power-up self test. If the self-test was not executed, the contents of + this register are undefined. Otherwise, a non-zero value indicates the + processor is faulty and a zero value indicates a successful self-test. + +- The DX register holds a component identifier and revision level. DH + contains 3 to indicate an i386 component and DL contains a unique revision + level indicator. + +- Control register zero (CR0) is set such that the processor is in real + mode with paging disabled. Other portions of CR0 are used to indicate the + presence of a numeric coprocessor. + +- All bits in the extended flags register (EFLAG) which are not + permanently set are cleared. This inhibits all maskable interrupts. + +- The Interrupt Descriptor Register (IDTR) is set to point at address + zero. + +- All segment registers are set to zero. + +- The instruction pointer is set to 0x0000FFF0. The first instruction + executed after a reset is actually at 0xFFFFFFF0 because the i386 asserts + the upper twelve address until the first intersegment (FAR) JMP or CALL + instruction. When a JMP or CALL is executed, the upper twelve address + lines are lowered and the processor begins executing in the first megabyte + of memory. + +Typically, an intersegment JMP to the application’s initialization code is +placed at address 0xFFFFFFF0. + +Processor Initialization +------------------------ + +This initialization code is responsible for initializing all data +structures required by the i386 in protected mode and for actually entering +protected mode. The i386 must be placed in protected mode and the segment +registers and associated selectors must be initialized before the +initialize_executive directive is invoked. + +The initialization code is responsible for initializing the Global +Descriptor Table such that the i386 is in the thirty-two bit flat memory +model with paging disabled. In this mode, the i386 automatically converts +every address from a logical to a physical address each time it is used. +For more information on the memory model used by RTEMS, please refer to the +Memory Model chapter in this document. + +Since the processor is in real mode upon reset, the processor must be +switched to protected mode before RTEMS can execute. Before switching to +protected mode, at least one descriptor table and two descriptors must be +created. Descriptors are needed for a code segment and a data segment. ( +This will give you the flat memory model.) The stack can be placed in a +normal read/write data segment, so no descriptor for the stack is needed. +Before the GDT can be used, the base address and limit must be loaded into +the GDTR register using an LGDT instruction. + +If the hardware allows an NMI to be generated, you need to create the IDT +and a gate for the NMI interrupt handler. Before the IDT can be used, the +base address and limit for the idt must be loaded into the IDTR register +using an LIDT instruction. + +Protected mode is entered by setting thye PE bit in the CR0 register. +Either a LMSW or MOV CR0 instruction may be used to set this bit. Because +the processor overlaps the interpretation of several instructions, it is +necessary to discard the instructions from the read-ahead cache. A JMP +instruction immediately after the LMSW changes the flow and empties the +processor if intructions which have been pre-fetched and/or decoded. At +this point, the processor is in protected mode and begins to perform +protected mode application initialization. + +If the application requires that the IDTR be some value besides zero, then +it should set it to the required value at this point. All tasks share the +same i386 IDTR value. Because interrupts are enabled automatically by +RTEMS as part of the initialize_executive directive, the IDTR MUST be set +properly before this directive is invoked to insure correct interrupt +vectoring. If processor caching is to be utilized, then it should be +enabled during the reset application initialization code. The reset code +which is executed before the call to initialize_executive has the following +requirements: + +For more information regarding the i386 data structures and their +contents, refer to Intel’s 386 Programmer’s Reference Manual. + +.. COMMENT: COPYRIGHT (c) 1988-2002. + +.. COMMENT: On-Line Applications Research Corporation (OAR). + +.. COMMENT: All rights reserved. + +.. COMMENT: Jukka Pietarinen , 2008, + +.. COMMENT: Micro-Research Finland Oy + -- cgit v1.2.3