10. 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.

Architecture Documents

For information on the MC68xxx and Coldfire architecture, refer to the following documents available from Freescale website (http//www.freescale.com/):

  • M68000 Family Reference, Motorola, FR68K/D.

  • MC68020 User’s Manual, Motorola, MC68020UM/AD.

  • MC68881/MC68882 Floating-Point Coprocessor User’s Manual, Motorola, MC68881UM/AD.

10.1. CPU Model Dependent Features

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 selected on the compilation command line.

10.1.1. BFFFO Instruction

The macro M68K_HAS_BFFFO is set to 1 to indicate that this CPU model has the bfffo instruction.

10.1.2. Vector Base Register

The macro M68K_HAS_VBR is set to 1 to indicate that this CPU model has a vector base register (vbr).

10.1.3. Separate Stacks

The macro M68K_HAS_SEPARATE_STACKS is set to 1 to indicate that this CPU model has separate interrupt, user, and supervisor mode stacks.

10.1.4. Pre-Indexing Address Mode

The macro M68K_HAS_PREINDEXING is set to 1 to indicate that this CPU model has the pre-indexing address mode.

10.1.5. Extend Byte to Long Instruction

The macro 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.

10.2. Calling Conventions

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.

10.2.1. Calling Mechanism

All RTEMS directives are invoked using either a bsr or jsr instruction and return to the user application via the rts instruction.

10.2.2. 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.

10.2.3. 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:

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 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.

10.3. 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 is byte addressable. The address may be used to reference a single byte, word (2-bytes), or long word (4 bytes). Memory accesses within this address space are performed in big endian fashion by the processors in this family.

Some of the MC68xxx family members such as the MC68020, MC68030, and MC68040 support virtual memory and segmentation. The MC68020 requires external hardware support such as the MC68851 Paged Memory Management Unit coprocessor which is typically used to perform address translations for these systems. RTEMS does not support virtual memory or segmentation on any of the MC68xxx family members.

10.4. Interrupt Processing

Discussed in this section are the MC68xxx’s interrupt response and control mechanisms as they pertain to RTEMS.

10.4.1. 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.

10.4.1.1. Models Without Separate Interrupt Stacks

Upon receipt of an interrupt the MC68xxx family members without separate interrupt stacks automatically use software to switch stacks.

10.4.1.2. Models With Separate Interrupt Stacks

Upon receipt of an interrupt the MC68xxx family members with separate interrupt stacks automatically perform the following actions:

  • saves the current status register (SR),

  • clears the master/interrupt (M) bit of the SR to indicate the switch from master state to interrupt state,

  • sets the privilege mode to supervisor,

  • suppresses tracing,

  • sets the interrupt mask level equal to the level of the interrupt being serviced,

  • pushes an interrupt stack frame (ISF), which includes the program counter (PC), the status register (SR), and the format/exception vector offset (FVO) word, onto the supervisor and interrupt stacks,

  • switches the current stack to the interrupt stack and vectors to an interrupt service routine (ISR). If the ISR was installed with the interrupt_catch directive, then the RTEMS interrupt handler will begin execution. The RTEMS interrupt handler saves all registers which are not preserved according to the calling conventions and invokes the application’s ISR.

A nested interrupt is processed similarly by these CPU models with the exception that only a single ISF is placed on the interrupt stack and the current stack need not be switched.

The FVO word in the Interrupt Stack Frame is examined by RTEMS to determine when an outer most interrupt is being exited. Since the FVO is used by RTEMS for this purpose, the user application code MUST NOT modify this field.

The following shows the Interrupt Stack Frame for MC68xxx CPU models with separate interrupt stacks:

Status Register

0x0

Program Counter High

0x2

Program Counter Low

0x4

Format/Vector Offset

0x6

10.4.2. CPU Models Without VBR and RAM at 0

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.

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:

//
//  Real vector table at 0
//
.long   initial_sp
.long   initial_pc
.long   myhandler+0x02000000
.long   myhandler+0x03000000
.long   myhandler+0x04000000
...
.long   myhandler+0xff000000
//
// This handler will jump to the interrupt routine   of which
// the address is stored at VBR[ vector_no ]
// The registers and stackframe will be intact, the interrupt
// routine will see exactly what it would see if it was called
// directly from the HW vector table at 0.
//
    .comm    VBR,4,2        // This defines the 'virtual' VBR
// From C: extern void *VBR;
myhandler:                  // At entry, PC contains the full vector
    move.l  %d0,-(%sp)      // Save d0
    move.l  %a0,-(%sp)      // Save a0
    lea     0(%pc),%a0      // Get the value of the PC
    move.l  %a0,%d0         // Copy it to a data reg, d0 is VV??????
    swap    %d0             // Now d0 is ????VV??
    and.w   #0xff00,%d0     // Now d0 is ????VV00 (1)
    lsr.w   #6,%d0          // Now d0.w contains the VBR table offset
    move.l  VBR,%a0         // Get the address from VBR to a0
    move.l  (%a0,%d0.w),%a0 // Fetch the vector
    move.l  4(%sp),%d0      // Restore d0
    move.l  %a0,4(%sp)      // Place target address to the stack
    move.l  (%sp)+,%a0      // Restore a0, target address is on TOS
    ret                     // This will jump to the handler and
// restore the stack

  1. If ‘myhandler’ is guaranteed to be in the first 64K, e.g. just after the vector table then that insn is not needed.

There are probably shorter ways to do this, but it I believe is enough to illustrate the trick. Optimisation is left as an exercise to the reader :-)

10.4.3. Interrupt Levels

Eight levels (0-7) of interrupt priorities are supported by MC68xxx family members with level seven (7) being the highest priority. Level zero (0) indicates that interrupts are fully enabled. Interrupt requests for interrupts with priorities less than or equal to the current interrupt mask level are ignored.

Although RTEMS supports 256 interrupt levels, the MC68xxx family only supports eight. RTEMS interrupt levels 0 through 7 directly correspond to MC68xxx interrupt levels. All other RTEMS interrupt levels are undefined and their behavior is unpredictable.

10.5. Default Fatal Error Processing

The default fatal error handler for this architecture disables processor interrupts to level 7, places the error code in D0, and executes a stop instruction to simulate a halt processor instruction.

10.6. Symmetric Multiprocessing

SMP is not supported.

10.7. Thread-Local Storage

Thread-local storage is supported.

10.8. Board Support Packages

10.8.1. 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:

  • The tracing bits of the status register are cleared to disable tracing.

  • The supervisor interrupt state is entered by setting the supervisor (S) bit and clearing the master/interrupt (M) bit of the status register.

  • The interrupt mask of the status register is set to level 7 to effectively disable all maskable interrupts.

  • The vector base register (VBR) is set to zero.

  • The cache control register (CACR) is set to zero to disable and freeze the processor cache.

  • The interrupt stack pointer (ISP) is set to the value stored at vector 0 (bytes 0-3) of the exception vector table (EVT).

  • The program counter (PC) is set to the value stored at vector 1 (bytes 4-7) of the EVT.

  • The processor begins execution at the address stored in the PC.

10.8.2. 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 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 Manual for the reset code which is executed before the call to initialize executive, the MC68020 version has the following specific requirements:

  • Must leave the S bit of the status register set so that the MC68020 remains in the supervisor state.

  • Must set the M bit of the status register to remove the MC68020 from the interrupt state.

  • Must set the master stack pointer (MSP) such that a minimum stack size of MINIMUM_STACK_SIZE bytes is provided for the initialize executive directive.

  • Must initialize the MC68020’s vector table.