diff options
Diffstat (limited to 'doc/cpu_supplement/m68k.t')
| -rw-r--r-- | doc/cpu_supplement/m68k.t | 404 |
1 files changed, 87 insertions, 317 deletions
diff --git a/doc/cpu_supplement/m68k.t b/doc/cpu_supplement/m68k.t index b39c3236b3..037a3e6596 100644 --- a/doc/cpu_supplement/m68k.t +++ b/doc/cpu_supplement/m68k.t @@ -8,212 +8,105 @@ @ifinfo @end ifinfo -@chapter Motorola M68xxx and Coldfire Specific Information - -The Real Time Executive for Multiprocessor Systems (RTEMS) -is designed to be portable across multiple processor -architectures. However, the nature of real-time systems makes -it essential that the application designer understand certain -processor dependent implementation details. These processor -dependencies include calling convention, board support package -issues, interrupt processing, exact RTEMS memory requirements, -performance data, header files, and the assembly language -interface to the executive. - -This document discusses the Motorola MC68xxx -architecture dependencies in this port of RTEMS. The MC68xxx -family has a wide variety of CPU models within it. The part -numbers for these models are generally divided into MC680xx and -MC683xx. The MC680xx models are more general purpose processors -with no integrated peripherals. The MC683xx models, on the -other hand, are more specialized and have a variety of -peripherals on chip including sophisticated timers and serial +@chapter M68xxx and Coldfire Specific Information + +This chapter discusses the Freescale (formerly Motorola) MC68xxx +and Coldfire architectural dependencies. The MC68xxx family has a +wide variety of CPU models within it based upon different CPU core +implementations. Ignoring the Coldfire parts, the part numbers for +these models are generally divided into MC680xx and MC683xx. The MC680xx +models are more general purpose processors with no integrated peripherals. +The MC683xx models, on the other hand, are more specialized and have a +variety of peripherals on chip including sophisticated timers and serial communications controllers. -It is highly recommended that the Motorola MC68xxx -RTEMS application developer obtain and become familiar with the -documentation for the processor being used as well as the -documentation for the family as a whole. - @subheading Architecture Documents -For information on the Motorola MC68xxx architecture, -refer to the following documents available from Motorola -(@file{http//www.moto.com/}): +For information on the MC68xxx and Coldfire architecture, refer to the following documents available from Freescale website (@file{http//www.freescale.com/}): @itemize @bullet @item @cite{M68000 Family Reference, Motorola, FR68K/D}. -@end itemize - -@subheading MODEL SPECIFIC DOCUMENTS - -For information on specific processor models and -their associated coprocessors, refer to the following documents: - -@itemize @bullet @item @cite{MC68020 User's Manual, Motorola, MC68020UM/AD}. - -@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's -Manual, Motorola, MC68881UM/AD}. +@item @cite{MC68881/MC68882 Floating-Point Coprocessor User's Manual, +Motorola, MC68881UM/AD}. @end itemize @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ @c - @section CPU Model Dependent Features -Microprocessors are generally classified into -families with a variety of CPU models or implementations within -that family. Within a processor family, there is a high level -of binary compatibility. This family may be based on either an -architectural specification or on maintaining compatibility with -a popular processor. Recent microprocessor families such as the -SPARC or PowerPC are based on an architectural specification -which is independent or any particular CPU model or -implementation. Older families such as the M68xxx and the iX86 -evolved as the manufacturer strived to produce higher -performance processor models which maintained binary -compatibility with older models. - -RTEMS takes advantage of the similarity of the -various models within a CPU family. Although the models do vary -in significant ways, the high level of compatibility makes it -possible to share the bulk of the CPU dependent executive code -across the entire family. Each processor family supported by -RTEMS has a list of features which vary between CPU models -within a family. For example, the most common model dependent -feature regardless of CPU family is the presence or absence of a -floating point unit or coprocessor. When defining the list of -features present on a particular CPU model, one simply notes -that floating point hardware is or is not present and defines a -single constant appropriately. Conditional compilation is -utilized to include the appropriate source code for this CPU -model's feature set. It is important to note that this means -that RTEMS is thus compiled using the appropriate feature set -and compilation flags optimal for this CPU model used. The -alternative would be to generate a binary which would execute on -all family members using only the features which were always -present. - -This chapter presents the set of features which vary -across SPARC implementations and are of importance to RTEMS. +This section presents the set of features which vary +across m68k/Coldfire implementations that are of importance to RTEMS. The set of CPU model feature macros are defined in the file -cpukit/score/cpu/m68k/m68k.h based upon the particular CPU -model defined on the compilation command line. - -@subsection CPU Model Name - -The macro CPU_MODEL_NAME is a string which designates -the name of this CPU model. For example, for the MC68020 -processor, this macro is set to the string "mc68020". - -@subsection Floating Point Unit - -The macro M68K_HAS_FPU is set to 1 to indicate that -this CPU model has a hardware floating point unit and 0 -otherwise. It does not matter whether the hardware floating -point support is incorporated on-chip or is an external -coprocessor. +@code{cpukit/score/cpu/m68k/m68k.h} based upon the particular CPU +model selected on the compilation command line. @subsection BFFFO Instruction -The macro M68K_HAS_BFFFO is set to 1 to indicate that +The macro @code{M68K_HAS_BFFFO} is set to 1 to indicate that this CPU model has the bfffo instruction. @subsection Vector Base Register -The macro M68K_HAS_VBR is set to 1 to indicate that +The macro @code{M68K_HAS_VBR} is set to 1 to indicate that this CPU model has a vector base register (vbr). @subsection Separate Stacks -The macro M68K_HAS_SEPARATE_STACKS is set to 1 to +The macro @code{M68K_HAS_SEPARATE_STACKS} is set to 1 to indicate that this CPU model has separate interrupt, user, and supervisor mode stacks. @subsection Pre-Indexing Address Mode -The macro M68K_HAS_PREINDEXING is set to 1 to indicate that +The macro @code{M68K_HAS_PREINDEXING} is set to 1 to indicate that this CPU model has the pre-indexing address mode. @subsection Extend Byte to Long Instruction -The macro M68K_HAS_EXTB_L is set to 1 to indicate that this CPU model +The macro @code{M68K_HAS_EXTB_L} is set to 1 to indicate that this CPU model has the extb.l instruction. This instruction is supposed to be available in all models based on the cpu32 core as well as mc68020 and up models. + @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ @c - @section Calling Conventions - -Each high-level language compiler generates -subroutine entry and exit code based upon a set of rules known -as the compiler's calling convention. These rules address the -following issues: - -@itemize @bullet -@item register preservation and usage -@item parameter passing -@item call and return mechanism -@end itemize - -A compiler's calling convention is of importance when -interfacing to subroutines written in another language either -assembly or high-level. Even when the high-level language and -target processor are the same, different compilers may use -different calling conventions. As a result, calling conventions -are both processor and compiler dependent. - -@subsection Processor Background - -The MC68xxx architecture supports a simple yet -effective call and return mechanism. A subroutine is invoked -via the branch to subroutine (bsr) or the jump to subroutine -(jsr) instructions. These instructions push the return address -on the current stack. The return from subroutine (rts) -instruction pops the return address off the current stack and -transfers control to that instruction. It is is important to -note that the MC68xxx 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. +The MC68xxx architecture supports a simple yet effective call and +return mechanism. A subroutine is invoked via the branch to subroutine +(@code{bsr}) or the jump to subroutine (@code{jsr}) instructions. +These instructions push the return address on the current stack. +The return from subroutine (@code{rts}) instruction pops the return +address off the current stack and transfers control to that instruction. +It is is important to note that the MC68xxx 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. @subsection Calling Mechanism -All RTEMS directives are invoked using either a bsr -or jsr instruction and return to the user application via the -rts instruction. +All RTEMS directives are invoked using either a @code{bsr} or @code{jsr} +instruction and return to the user application via the rts instruction. @subsection Register Usage -As discussed above, the bsr and jsr instructions do -not automatically save any registers. RTEMS uses the registers -D0, D1, A0, and A1 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. +As discussed above, the @code{bsr} and @code{jsr} instructions do not +automatically save any registers. RTEMS uses the registers D0, D1, +A0, and A1 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. @subsection Parameter Passing -RTEMS assumes that arguments are placed on the -current stack before the directive is invoked via the bsr or jsr -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: +RTEMS assumes that arguments are placed on the current stack before +the directive is invoked via the bsr or jsr 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: @example @group @@ -225,41 +118,17 @@ remove arguments from the stack @end group @end example -The arguments to RTEMS are typically pushed onto the -stack using a move instruction with a pre-decremented stack -pointer as the destination. 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 current stack pointer. - -@subsection User-Provided Routines - -All user-provided routines invoked by RTEMS, such as -user extensions, device drivers, and MPCI routines, must also -adhere to these calling conventions. +The arguments to RTEMS are typically pushed onto the stack using a move +instruction with a pre-decremented stack pointer as the destination. +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 current stack pointer. @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ @c - @section Memory Model - -A processor may support any combination of memory -models ranging from pure physical addressing to complex demand -paged virtual memory systems. RTEMS supports a flat memory -model which ranges contiguously over the processor's allowable -address space. RTEMS does not support segmentation or virtual -memory of any kind. The appropriate memory model for RTEMS -provided by the targeted processor and related characteristics -of that model are described in this chapter. - -@subsection Flat Memory Model - The MC68xxx family 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 @@ -277,44 +146,23 @@ these systems. RTEMS does not support virtual memory or segmentation on any of the MC68xxx family members. @c -@c Interrupt Stack Frame Picture @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ -@c - @section Interrupt Processing - -Different types of processors respond to the -occurrence of an interrupt in its own unique fashion. In -addition, each processor type provides a control mechanism to -allow for the proper handling of an interrupt. The processor -dependent response to the interrupt modifies the current -execution state and results in a change in the execution stream. -Most processors require that an interrupt handler utilize some -special control mechanisms to return to the normal processing -stream. 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 MC68xxx's -interrupt response and control mechanisms as they pertain to -RTEMS. +Discussed in this section are the MC68xxx's interrupt response and +control mechanisms as they pertain to RTEMS. @subsection Vectoring of an Interrupt Handler -Depending on whether or not the particular CPU -supports a separate interrupt stack, the MC68xxx family has two -different interrupt handling models. +Depending on whether or not the particular CPU supports a separate +interrupt stack, the MC68xxx family has two different interrupt handling +models. @subsubsection Models Without Separate Interrupt Stacks -Upon receipt of an interrupt the MC68xxx family -members without separate interrupt stacks automatically perform -the following actions: +Upon receipt of an interrupt the MC68xxx family members without separate +interrupt stacks automatically perform the following actions: @itemize @bullet @item To Be Written @@ -322,9 +170,8 @@ the following actions: @subsubsection Models With Separate Interrupt Stacks -Upon receipt of an interrupt the MC68xxx family -members with separate interrupt stacks automatically perform the -following actions: +Upon receipt of an interrupt the MC68xxx family members with separate +interrupt stacks automatically perform the following actions: @itemize @bullet @item saves the current status register (SR), @@ -425,19 +272,18 @@ MC68xxx CPU models with separate interrupt stacks: This is from a post by Zoltan Kocsi <zoltan@@bendor.com.au> and is a nice trick in certain situations. In his words: -I think somebody on this list asked about the interupt vector -handling w/o VBR and RAM at 0. The usual trick is -to initialise the vector table (except the first 2 two entries, of -course) to point to the same location BUT you also add the vector -number times 0x1000000 to them. That is, bits 31-24 contain the vector -number and 23-0 the address of the common handler. -Since the PC is 32 bit wide but the actual address bus is only 24, -the top byte will be in the PC but will be ignored when jumping -onto your routine. +I think somebody on this list asked about the interupt vector handling +w/o VBR and RAM at 0. The usual trick is to initialise the vector table +(except the first 2 two entries, of course) to point to the same location +BUT you also add the vector number times 0x1000000 to them. That is, +bits 31-24 contain the vector number and 23-0 the address of the common +handler. Since the PC is 32 bit wide but the actual address bus is only +24, the top byte will be in the PC but will be ignored when jumping onto +your routine. -Then your common interrupt routine gets this info by loading the PC -into some register and based on that info, you can jump to a vector -in a vector table pointed by a virtual VBR: +Then your common interrupt routine gets this info by loading the PC +into some register and based on that info, you can jump to a vector in +a vector table pointed by a virtual VBR: @example // @@ -505,95 +351,26 @@ through 7 directly correspond to MC68xxx interrupt levels. All other RTEMS interrupt levels are undefined and their behavior is unpredictable. -@subsection Disabling of Interrupts by RTEMS - -During the execution of directive calls, critical -sections of code may be executed. When these sections are -encountered, RTEMS disables interrupts to level seven (7) before -the execution of this section and restores them to the previous -level upon completion of the section. RTEMS has been optimized -to insure that interrupts are disabled for less than -RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a -RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz MC68020 with -zero wait states. These numbers will vary based the -number of wait states and processor speed present on the target board. -[NOTE: The maximum period with interrupts disabled is hand calculated. This -calculation was last performed for Release -RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.] - -Non-maskable interrupts (NMI) cannot be disabled, and -ISRs which execute at this level MUST NEVER issue RTEMS system -calls. If a directive is invoked, unpredictable results may -occur due to the inability of RTEMS to protect its critical -sections. However, ISRs that make no system calls may safely -execute as non-maskable interrupts. - -@subsection Interrupt Stack - -RTEMS allocates the interrupt stack from the -Workspace Area. The amount of memory allocated for the -interrupt stack is determined by the interrupt_stack_size field -in the CPU Configuration Table. During the initialization -process, RTEMS will install its interrupt stack. - -The MC68xxx port of RTEMS supports a software managed -dedicated interrupt stack on those CPU models which do not -support a separate interrupt stack in hardware. - - @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ @c - @section Default Fatal Error Processing - -Upon detection of a fatal error by either the -application or RTEMS the fatal error manager is invoked. The -fatal error manager will invoke the user-supplied fatal error -handlers. If no user-supplied handlers are configured, the -RTEMS provided default fatal error handler is invoked. If the -user-supplied fatal error handlers return to the executive the -default fatal error handler is then invoked. This chapter -describes the precise operations of the default fatal error -handler. - -@subsection Default Fatal Error Handler Operations - -The default fatal error handler which is invoked by -the fatal_error_occurred directive when there is no user handler -configured or the user handler returns control to RTEMS. The -default fatal error handler disables processor interrupts to -level 7, places the error code in D0, and executes a stop -instruction to simulate a halt processor instruction. +The default fatal error handler for this architecture disables processor +interrupts to level 7, places the error code in D0, and executes a +@code{stop} instruction to simulate a halt processor instruction. @c -@c COPYRIGHT (c) 1988-2002. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. @c -@c $Id$ @c @section Board Support Packages - -An RTEMS Board Support Package (BSP) must be designed -to support a particular processor and target board combination. -This chapter presents a discussion of MC68020 specific BSP -issues. For more information on developing a BSP, refer to the -chapter titled Board Support Packages in the RTEMS -Applications User's Guide. - @subsection System Reset -An RTEMS based application is initiated or -re-initiated when the MC68020 processor is reset. When the -MC68020 is reset, the processor performs the following actions: +An RTEMS based application is initiated or re-initiated when the MC68020 +processor is reset. When the MC68020 is reset, the processor performs +the following actions: @itemize @bullet @item The tracing bits of the status register are cleared to @@ -624,17 +401,16 @@ the PC. @subsection Processor Initialization -The address of the application's initialization code -should be stored in the first vector of the EVT which will allow -the immediate vectoring to the application code. If the -application requires that the VBR be some value besides zero, -then it should be set to the required value at this point. All -tasks share the same MC68020's VBR value. Because interrupts -are enabled automatically by RTEMS as part of the initialize -executive directive, the VBR MUST be set 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 address of the application's initialization code should be stored in +the first vector of the EVT which will allow the immediate vectoring to +the application code. If the application requires that the VBR be some +value besides zero, then it should be set to the required value at this +point. All tasks share the same MC68020's VBR value. Because interrupts +are enabled automatically by RTEMS as part of the context switch to the +first task, the VBR MUST be set by either RTEMS of the BSP before this +occurs ensure correct interrupt vectoring. If processor caching is +to be utilized, then it should be enabled during the reset application +initialization code. In addition to the requirements described in the Board Support Packages chapter of the Applications User's @@ -656,9 +432,3 @@ the initialize executive directive. @item Must initialize the MC68020's vector table. @end itemize -Note that the BSP is not responsible for allocating -or installing the interrupt stack. RTEMS does this -automatically as part of initialization. If the BSP does not -install an interrupt stack and -- for whatever reason -- an -interrupt occurs before initialize_executive is invoked, then -the results are unpredictable. |